This week’s Ask An SEO question:
“How do you stress-test a staging environment to surface SEO risks before a large-scale launch?”
It is one of the most important questions to answer when considering rolling out new websites, migrations, or significant changes to your live site.
First, let’s look at the difference between a “staging” site and the “production” site.
The staging site is often also called the “development” site, “pre-production,” or another name that is specific to your company. It is a test site that is meant to mirror your live site as much as possible to help developers test changes in a safe, private environment before launching them.
The “production” site is your live site. It’s the one that is accessible to the general public and should be operating as close to perfectly as possible.
There are some instances where developers might deploy straight to the production site without testing on a staging site first. For example, when there is no testing site to use, or there is no way of mimicking the conditions to test without deploying the change to the live site. This is risky to do. If a deployment breaks something else in the code, it could critically affect the usability of the live site.
How To Stress-Test The Staging Environment
As SEOs, it is very important that we test deployments that could potentially impact SEO performance before they launch. Oftentimes, we find ourselves discovering deployments after they have already started to affect traffic and rankings. This is less than ideal, as it can take a while for Googlebot to pick up changes once a bad deployment has been fixed. It is far better to test how Googlebot might process changes before it is able to do so.
Mirror The Production Site As Closely As Possible
The most important aspect of the staging site is that it is as close to the production environment as possible. This is critical because it enables any testing that you do to reveal the same outcome as if you had run the test on the production environment.
Any deviations between the two environments need to be cataloged. These discrepancies need to be communicated so that testers know to pay special attention to the areas of the production site that differ from staging. Once the deployment goes live, testers can quickly ensure these areas of the production site are behaving as expected.
Crawl The Site At Scale With Multiple User-Agents
One area that is often overlooked when stress-testing the staging environment is using several different user agents when crawling the site.
By using different agents, for example, mimicking Googlebot Smartphone and Googlebot Desktop, you are more likely to pick up technical issues with the site that aren’t obvious on first crawl. For instance, crawling as both desktop Googlebot and mobile Googlebot could show issues with rendering that are only occurring on mobile devices.
Make sure to crawl the site with user agents that are important for your specific industry. If you are targeting Google News as a channel, make sure to crawl the site as the Google-News bot. If images or videos are important to your SEO, crawl as Google-Image and Google-Video bots.
To put your staging site through its paces, make sure to crawl it with a mobile user agent, a desktop user agent, and spoof two search engine bots, e.g., Google and Bing. This way you are getting good coverage of the experiences of different, important bots. If possible, try to crawl as an LLM bot also.
Check The Rendering
A good starting point when testing a staging environment before a large-scale deployment is rendering. Modern websites will often use a lot of JavaScript, which, not inherently bad, can pose issues for some search bots in processing. For more information on how search bots process JavaScript, see this guide.
Set your crawling tool to include JavaScript rendering, and see what elements it can pick up. For example, can you see the header tags, meta title, schema markup? Then crawl the site again without JavaScript rendering enabled. Make sure those same elements are still available to the bots.
If in doubt, carry out some spot-checks on pages on the staging site. Inspect the Document Object Model (DOM) to see if the critical code elements are visible on first load of the page.
It is important that what you are seeing on the page is what the search bots are able to parse and render.
Test SEO Elements In Bulk And Across Page Types
Carrying out tests in bulk is important when testing a site before a large launch. When carrying out your tests, make sure they are across different page types and, if applicable, across languages.
If your site uses templates, make sure to test each of the templates that are critical to your SEO success. For example, on an ecommerce site, this means checking the category and product pages as a high priority.
For multilingual sites, ensure your tests are being run across different languages, and set a VPN to target the countries those languages are important for. Spoof those countries when running your crawls to make sure users will be seeing the correct language and content for their region. Although Googlebot frequently crawls from U.S.-based IP addresses, it also uses geo-distributed configurations, particularly for locale-adaptive or multilingual sites.
On your staging site, you may find that not all of the languages are represented, or perhaps there is a different localization process than what exists on production. This brings us back to the first point of needing the staging site to be as comparable to the production site as possible.
If it isn’t, in particular for localization elements, these need to be at the top of your post-deployment checks.
Benchmark Current Production Performance
A good aspect to remember is that your staging site may well be on a less performant server. This means that when conducting speed tests on staging, the results might be worse than if the tests were run on production. This can limit your ability to run meaningful checks before deployment.
To work around this, make sure to benchmark performance on production so that you can run the tests again quickly after deployment. This will mean waiting until the changes have gone live, but may be the only way to get an accurate understanding of areas like page load speed in situations where the staging server just isn’t as good as the production one.
Test For Edge Cases
Developers will try to break their code when testing it; we should too. When testing your staging site before deployment, run it through some edge cases. In practice, this means thinking of scenarios that, although unlikely, are possible. For example,
- I am visiting the website from the U.S., but my language is set to French. What language are the meta tags in?
- I am viewing the website on a mobile device but have the viewport set to desktop. What content am I able to access that I couldn’t on mobile otherwise?
- If I turn JavaScript off, can I still use the menu drop-downs?
Test For Previously Known Issues
Make sure previous issues haven’t been reintroduced into the code during the most recent work. Even if the mass deployment is for a small area, such as a new meta title template being rolled out, that’s not to say issues aren’t being reintroduced elsewhere.
Don’t test only for the item being changed, but check across critical SEO areas. In particular, if work has been done recently to improve pages on the site, check those will still be in place with this latest deployment.
Equally, if there are known bugs that have affected your SEO performance in the past, check for these even if the deployment isn’t related to them. It’s easy for bugs to sneak back into code, especially if they have been there before.
More Resources:
Featured Image: Paulo Bobita/Search Engine Journal
