Using these technologies, users can browse products and content in a fast, intuitive way via a clean interface. The URL, however, remains more or less the same. Hyperlinks, which include URL fragments, are used to load the requested product data at the time of user interaction, avoiding a page refresh.
One Solution: Fallback Pages
Fallback pages give search engines the content they need for important organic search landing pages. These pages are not intended for users unless they are using a limited or text browser. Going a step further, the Cadillac approach to the problem is often referred to as “Progressive enhancement” — a full site where users get as much functionality as their system can handle. This is also the most work, of course, as code needs to be written for each level of client functionality across the entire site.
Building progressive enhancement sites or fallback pages increases initial build time and expense and adds ongoing maintenance workload. Furthermore, users may never see the fallback pages or their URLs — they will see the URL with the hash symbol — and these URLs will not accrue inbound links or social signals at the URL level. This may or may not be a problem, depending on whether the URLs are important organic landing pages.
Implementing Fallback Pages
Several approaches exist to implementing fallback pages. They can be achieved by simply putting the important content in the <noscript> tag. This adds code bloat, can be awkward and is limited to key entry pages. If the tag is not loaded as the user progresses into the web app, content will be lost to the engines.
Another approach is to handle it on the server side. In 2011, Google introduced a standard — often referred to as “hashbang”(#!) — which translates hashtag URLs into a query string for indexing by robots. Unlike the fragment part of a URL, query strings are visible to server-side systems and therefore allow web developers to render the appropriate content on the server side exclusively for search engines. This has the benefit of creating indexable URLs.
Details of the Google hashbang specification and its implementation can be found here. While this approach allows for indexing by Google, it has proved unpopular with SEOs and developers for several reasons, mainly due to increased development workload and incomplete support by other search engines and third party web services.
Other Solutions to the URL Problem
As mentioned above, depending on the extent to which SEO has been considered, a given UX state for AJAX or SPA sites may have visible URLs that are different from or invisible to search engines. This means search engines may see one set of URLs and users another.
Creating custom “share” UX elements and functionality including sharable URLs helps mitigate the inability of users to copy and past URLs that accurately reflect the state the user is seeing:
Of course, not everyone will use these UX elements and they require developing server-side logic that can force the state via URL elements and presenting this to the user.
Using pushState to Fix the URL Problem
Implementing pushState adds development and maintenance workload. The variables and URLs referenced will need to be updated as the site evolves.
PushState also requires a modern browser, but then again, so do many modern AJAX and SPA sites, so you are most likely already going down the road of tossing obsolete browsers and their users to the side of the road.
Putting it Together
If budget and resources allow, a comprehensive approach to creating an SEO-friendly AJAX or SAP site would involve:
Author’s note: Special thanks to Thomas Prommer, vice president of technology at Huge, for helping author this post.
Image by Ognian Mladenov, Flickr