As Mark Twain once said "There are only 2 certainties in life. Death and taxes".
Testing A SPA Site On A Staging Environment.
Yes, like any major project it won't just be a case of flicking a switch, and away we go. Nah, there'll be sprints, scrums, kanban boards and testing.
Plenty of testing.
The basic answer is the way the site is built.
You see, when it comes to Googlebot, HTML is a bit of a straight shooter - you get exactly what you see.
Whereas, frameworks like React, Angular and other SPAs are like shells where it assembles the code in the browser as it goes along.
Think of it a bit like flatpack furniture that you're assembling as you need it.
Which means that the way you test it is entirely different to testing a normal site. One you're testing a site where it's obvious, and nothing is going on in the background. The other where there's more going on than you can see.
Google's advice is pretty simple when it comes to testing Single Page Applications.
And it goes something like the below:
1) Use the mobile-friendly testing tool to see how Googlebot's rendered version differs from the version that is rendered in the browser.
2) Use a tunnel with something like Ngrok to access your local files
But the problem with that is they're both not that practical in the real world for the two reasons below:
When you work for any decent-sized organisation, they're not going to let any old IP address access your site. They're only going to let people in the business access it.
That means the mobile testing tool is a no-go. Especially when ten's of thousands of sites use the same IP address as it.
The workaround that the GOOG suggests is to use something like NGROK to let the mobile-friendly testing tool access the local files on your computer.
The problem with that is that code on your computer behaves wildly different to code that's hosted on a staging environment for a number of reasons. The biggest one is that it is like doing tests in a laboratory environment. There's limited outside factors impacting it. That why there are testing sites. So you come closer to replicating how it will behave in the field.
So essentially Google's advice just isn't going to cut it, and you'll need to do something a bit different.
Good of you to ask.
There's essentially a 3 step process that you should take.
As soon as you get access to the test site, you need to run a crawl on it.
However, it's not as simple as just setting it up and letting the little spiders scuttle away.
First, you need to know how the developers have implemented the Single Page Application.
-Are they dynamically rendering it?
- Or are they client-side rendering?
It's important to understand the difference so I will cover them briefly below, but if you need more details, this article covers it in much more detail.
This is basically letting the browser assemble the page. Or essentially doing nothing with the code and letting Googlebot crawl the page, submit it to its rendering services and then let it assemble it like it's fresh off the IKEA shelf.
Whereas dynamic rendering is sort of like getting someone to assemble it in a van as it's being delivered to.
Which one you choose drastically changes how you test it.
This is a lot simpler than the other option. All you need to do is:
The only other thing to watch out for is if you are using a web-based crawler like Deepcrawl. If that's the case, you need to make sure you whitelist the IP address for the crawler. There's documentation for how to do that with Deepcrawl here.
If you use Screaming Frog, it's machine-based, so you're good to go.
Once you've crawled the site, it's just about comparing what you see in the crawler to what you see on the staging site as well as auditing it for any other issue.
You need to be vigilant of:
Remember that Dynamic Rendering is basically like someone assembling your site in a van. However, there's another layer to it. It only does it for some people. So basically it detects when Googlebot or other Search Engines are crawling, and it serves them a preassembled version.
So when you test the site if the crawler doesn't have Googlebot or Bingbot as the user agent, it won't replicate the behaviour of it in the wild.
Deepcrawl uses Googlebot as a crawler, but Screaming Frog uses its own user agent.
And voila, you should be Dynamically served up a nice rendered slice of your site.
You've done your big crawl and logged a load of issues you've spotted, so now it is time to get an idea around sites behaviour as you interact with it.
To do that I like to test the site by spoofing Googlebot Smartphone in Chrome Dev Tools and interacting with the site.
To spoof Googlebot using Chrome Dev Tools. You just need to follow the below steps:
Now there are a few things that you need to factor in:
But what it can do is give you a general feel for how the content will display. What elements will and won't be visible. And what on-page elements you need to inspect in more detail in your next crawl.
It's the same process as the first step. Except that now you're checking up on the fixes you identified in the first crawl as well as things you want to look at in more detail from spot testing in the browser.
Usually, after you've done the final crawl and everything passes, you'll push it live.
But that's a big mistake.
Remember how the local files aren't a reflection of how it will behave on the live site. The exact same can be said of the staging site and the live site.
Live sites are usually a lot more complex, a lot more buggy and a lot, lot slower.
This final step is a test to see how the new framework behaves on a template by template basis.
We found out that this step was crucial the hard way.
We had a site that because of tight timelines decided to push live after Step 3.
Everything looked great.
It rendered fine. Load times were good. No obvious content was missing.
When it went live, the system that pulled in the pricing slowed the load so much that only the boilerplate content was getting indexed. And as a result, all of those pages were removed from the index as duplicates of the homepage.
A week of figuring out a workaround to make the selling system quicker and warming up the cache, so it didn't behave like a Sunday league footballer who's had seven pints the night before.
By pushing a couple of pages live before the proper release date, you can test how it behaves in search before you fully commit.
The big day has come, and it's just about pushing it live then kicking back.
Except that you can't.
You're an SEO, you need to be more paranoid than Claire Danes in Homeland. You need to keep your beady little eyes on it constantly to see how it behaves. Because you never know, a pesky little bug can come crawling out the gutter.