I’d like to explain why I always prefer to start theme development from the ground up (or using a theme framework like our very own IgniteWP) instead of buying a theme that aligns with the design the client wants.

There are a few reasons:

1. Theme updates break your implementation. Besides security updates, you normally don’t want to change your layout unless the client requests it, or you want to offer something different. You know not to update the theme, but  the client might log into wp-admin and say, “Hey, there’s an update – I better do that!” Before you know it, you’ve got a bunch of emails saying that the site has stopped working.
2. Only a few people work with base themes nicely. To work properly with themes, you need to use child themes – a cool feature from WP, but I rarely see implementations using these. If you don’t use child themes, the well-intentioned update problem mentioned above can completely erase your work from the server. If you don’t have a backup available, well, good luck!
3. Option screens get out of control fast. Normally, themes bought in stores are generic and made to target a specific type of website. You normally don’t need so many settings. It can also be confusing if you have a web marketing company and have to remember where the settings are for each theme, and how to work with each of them.

None of these things happen when building a layout with IgniteWP. We can match any design from the ground up, and deploy themes fast with the help of Bootstrap and ACF.

Of course, the upside of using a generic theme is cheap theme development, but eventually coding time will catch up with you. Trust me – we see this all the time at Saucal!

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.