So a few years ago, a bunch of sites started implementing AJAX navigation. It allowed smooth transitions from one page to the other. Load times increased, and overall, the UX was great.

But there were some issues with it. Your sites looked incomplete to search engines, trashing all the effort you’d put into your SEO rankings.

After avoiding this approach for a while — because we care a lot about SEO (and you should too) — we decided to research how could we do this within our sites (mostly built with WordPress).

The important thing to know is that search engines don’t execute JS, so the direct links to each URL of the site need to look nice SEO-wise (with meta tags, H1 tags and all). All good — we’ll make no changes to the templates — just navigate through the site doing AJAX requests to bring up the complete HTML of the page we need to load, and replace the content container with the new one.

That doesn’t sound right. It would allow us to do smooth transitions, but load times would still be the same (or slightly smaller).

We then realized that we didn’t need the header to load for all pages. We just needed it to load the first time the user arrived directly at our site (or if the page didn’t get loaded through AJAX). And there you go! We improved the UX with smooth transitions, improved load times, and kept all the SEO juice.

So, to answer the question in the title, it turns out that with a little extra work you can have both AJAX and SEO!

If you need to do something like this, our IgniteWP framework has a module you can use to avoid doing this work yourself. Sounds good, right?

Have you ever worked with the History API to build your apps? No? Well you should try it – it’s awesome!

You don’t believe me? You think it sucks? Well, that’s probably because you’ve encountered some of the many problems with it:

• In some cases, a popstate event is triggered at pageload for no apparent reason. This happens when you refresh a page that previously had a state set. Most of the time you don’t need this, as you can check the window.history.state from JS on page load if you need to do anything with it.It feels more natural that a popstate event is only triggered when the user hits the back/forward buttons, right?
• Why include the title parameter in the pushState and replaceState methods, if the browsers are not implementing it at all? It’s not rocket science to change the document.title parameter.Come on, Mozilla and Google! Microsoft, we know you try so hard  – just kill IE already!
• Google Analytics doesn’t play well with the History API yet, but in this case it’s understandable. Not every pushState or popState event is meant to trigger an Analytics response.

After struggling with these issues for a while, I put together a small JS library that provides almost the same interface as the native history object, but fills the gaps mentioned above.

It’s included in our open source framework, Ignite WP. Check out the source here and documentation here.