Check out this tweet from Google Webmaster Trends Analyst John Mueller:
John Mueller is correct. It’s not going away.
A quick search on Google Trends for “Single Page Application” reveals the sharp rise in popularity and awareness of SPAs over time:
Take Angular (also known as AngularJS and Angular.js), for example.
In my role as a professional SEO, I can’t say that Single Page Applications are the rule and not the exception when it comes to how businesses choose to develop websites these days, but I am running across more and more SPAs, and so are my colleagues.
- Yes, it’s true that SPAs to date have not been great for SEO.
- Yes, it’s true that many developers who had fun quickly creating websites using SPAs had to later spend more time fixing SEO problems than the time they would have spent if they just coded the site to deliver content via HTML5 in the first place.
But, none of that matters, my SEO friends.
Like it or not, SPAs look like they’re here to stay.
It’s time to stop thinking bad thoughts about SPAs and trying to wish them into the cornfield.
Single-Page Applications: Resistance is futile
I admit it – for a while there I was hoping I could ignore Single Page Applications, and maybe eventually SPAs would end up in the trash heap of obsolete website trends such as the <blink> tag, and web page content that’s free of annoying and intrusive advertising interruptions.
Programming and coding languages live and die by developer adoption. For example, if, by some weird turn of events, developers across the world suddenly decided they hated PHP and fell in love with some super-cool new server-side scripting language, then PHP withers, maybe even dies.
It’s just that simple.
That’s why, for example, Google has been pushing Accelerated Mobile Pages (AMP) super hard – because they need major and widespread developer adoption for AMP to succeed and not wind up as the <blink> tags’ roommate.
SPAs are popular with developers, and that popularity is not showing any sign of slowing down.
Dipping a toe into the SPA
Looking “under the hood” of SPAs, a distinguishing characteristic is that there’s a lot less back and forth between the server and the browser making requests to the server.
And this means a very good user experience because no extra page load means no extra wait time. And, as we all know, everyone prefers fast-loading pages.
The main aspect to remember here is that with an SPA there is far less back and forth between the browser and the server.
I only bring this up because in retrospect, and hindsight is always 20/20, we SEOs all should have seen the rise of Single Page Applications looming on the horizon.
But viewed glass-half-full, the rise of SPAs presents an opportunity for technically-minded SEOs to gain experience and become even more valuable now and in the future.
If SPAs can cause SEO issues, then why do developers create SPA websites?
If you’ve never done any coding, then you might not realize what it’s like to be in a developer’s mindset.
Think about it this way: if you were going to have to sit down and write code to create a certain web page functionality and you could either write 10 lines of code to achieve that, or write 1,000 lines of code, which would you choose? You’d opt for the expedience of 10 lines of code, right?
Developers are not lazy; they simply prefer efficiency and elegance when it comes to writing code. I’ve seen developers frame code and hang it on their office wall. Ever heard the saying “code is poetry?”
If you’re trying to get somewhere the fastest way possible, you take the shortest route, correct?
Single Page Application frameworks and libraries, in crude summary, provide building blocks that allow developers to create a website quickly and efficiently.
SPAs present a fast-loading user experience because they don’t need to reload most resources such as HTML, CSS, and scripts with each user interaction like a “traditional” website does. These files only require initial loading and then after that only new data is retrieved and downloaded from the server.
SPAs reduce response times primarily by moving the heavy-lifting of data processing from the server to the browser.
SEO may be a lesser consideration given the SPA developments upsides, an afterthought, or perhaps not a consideration at all during the website development process. Any SEO pro who has been in digital marketing for very long has seen the all-too-common situation where a company develops a website, only later to ask the question “how do we SEO this thing?”
Not everyone realizes that SEO should be baked-in at the beginning and not sprinkled-on at the end, or that their website development choices can have definite downstream negative impacts with respect to SEO.
Ask a developer “what’s the difference between a library and a framework” and you’ll get a lot of interesting answers.
One overriding distinction you hear repeatedly goes something like this:
The code you write calls a library, whereas a framework calls the code you write.
Frameworks can be thought of as a structure, like a pre-fab home which comes with the framing, drywall, plumbing, and electrical wiring and all you have to do is add the appliances, windows and coverings, flooring, paint, etc.
A library can be thought of as a place that contains a set of ready to use pre-built tools and functionalities. You’d call a library in your code for a specific function.
You can see that starting a web development project using frameworks and/or libraries can streamline the process, as opposed to writing from scratch all the necessary code to create a website.
Common SEO problems of Single Page Applications
Crawling and indexing is critical to ranking.
Google discovers web pages using software called Googlebot during a very fast process often called “crawling” or “spidering”, during which it downloads an HTML file it finds, extracts the links and visits them simultaneously, and then sends the downloaded resources to the indexer.
SEO is more than just having “great content” and earning high-quality links; it’s also about making your web pages easy to discover by search engines like Google and making it simple for them to know which pages are more important than other pages via internal linking.
A “traditional” HTML-based site is far easier to crawl and index, and by extension, rank. Google can get all the links easily and see what the importance of pages are via internal linking.
Another potential SEO problem related to the extra work to discover links is that Google may have issues with evaluating the link equity of those pages.
It’s likely that in time, at least some of the SPA frameworks in popular use will evolve the rendering process to make it easier for Google to crawl and index, perhaps even making it on par with “traditional” HTML-based websites.
Headless Chrome is another option recently proposed as an easy solution by a Google engineer, who also mentions another solution called Preact, which ships with server-side rendering.
It’s also a good idea to create a properly formatted XML Sitemap and submit that to Google Search Console.
Right now, there doesn’t appear to be any single solution or a paint-by-numbers approach to handing the problems you may encounter if you’re an SEO assisting a client with launching or redeveloping a website using an SPA.
It boils down to effectively communicating the correct end result that’s needed, and dealing with issues as they’re presented based on the library or framework being deployed.
Some important Single Page Application resources
Some super-sharp SEOs and developers have written helpful articles about Single Page Applications, and here are a few resources I have enjoyed that I think you will find helpful:
Single Page Applications are evolving rapidly, as is the web technology landscape in general. It’s worth the effort for professional SEOs to be as conversant as possible with not only Single Page Applications, but also Accelerated Mobile Pages, Progressive Web Apps, Content Management Systems in general, and of course the tech behind how websites are coded from scratch.