This week’s Ask an SEO question:
“How to test a test environment to reveal SEO risks before a large-scale launch? »
This is one of the most important questions to answer when considering deploying new websites. migrationsor significant changes to your online site.
First, let’s look at the difference between a “staging” site and the “production” site.
The staging site is often also referred to as a “development,” “pre-production” site, or whatever name is specific to your business. This is a test site intended to mirror your live site as much as possible to help developers test changes in a secure, private environment before releasing them.
The “production” site is your live site. It is the one which is accessible to the general public and which must function as perfectly as possible.
There are some cases where developers can deploy directly to the production site without first testing at a staging site. For example, when there is no test site to use, or there is no way to mimic the conditions to be tested without deploying the change to the live site. It’s risky to do. If a deployment breaks something else in the code, it could critically affect the usability of the live site.
How to test the staging environment
As SEOs, it is very important that we test deployments that may impact SEO performance before they launch. Often we discover deployments when they have already started affecting traffic and rankings. This is not ideal, as it can take some time for Googlebot to take into account the changes once a bad deployment has been fixed. It is much better test how Googlebot can process changes before you can do it.
Reflect the production site as accurately as possible
The most important aspect of the staging site is that it is as close as possible to the production environment. This is essential because it allows any tests you run to reveal the same result as if you had run the test on the production environment.
Any discrepancy between the two environments must be cataloged. These deviations should be communicated so that testers know to pay special attention to areas of the production site that differ from the staging. Once the deployment goes live, testers can quickly ensure that these areas of the production site are behaving as expected.
Explore the site at scale with multiple user agents
An often overlooked area when stress testing the test environment is the use of 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 detect technical problems with the site that are not obvious when first crawled. For example, crawling as a desktop Googlebot and mobile Googlebot could reveal issues with rendering that only happens on mobile devices.
Be sure to explore the site with important user agents for your specific industry. If you are targeting Google News as a channel, make sure to crawl the site as a Google-News crawler. If images or videos are important to your SEO, crawl as Google-Image and Google-Video bots.
To put your staging site to the test, make sure to crawl it with a mobile user agent, a desktop user agent, and spoof two search engine bots, for example Google and Bing. This way you get good coverage of the experiences of different important robots. If possible, try to explore as LLM bot Also.
Check the rendering
A good starting point for testing a test environment before rendering a large-scale deployment. Modern websites often use a lot of JavaScript, which, while not bad in itself, can cause processing problems for some search bots. For more information on how search bots process JavaScript, see this guide.
Configure your exploration tool to include JavaScript renderingand see what items he can recover. For example, can you see the header tags, meta title, schema markup? Then crawl the site again without JavaScript rendering enabled. Make sure these same items are always available to bots.
If in doubt, do a few spot checks on the intermediary site pages. Inspect the Document Object Model (DOM) to see if critical code elements are visible when the page first loads.
It is important that what you see on the page matches what the search robots are capable of analyzing and restoring.
Test SEO elements in bulk and on all page types
Conducting mass testing is important when testing a site before a large-scale launch. When you do your testing, make sure it covers different page types and, if applicable, multiple languages.
If your site uses templates, be sure to test each of the templates essential to your SEO success. For example, on an e-commerce site, this means checking category and product pages first.
For multilingual sitesmake sure your tests are run in different languages and configure a VPN to target countries where those languages are important. Spoof these countries when running your analytics to ensure users will see the correct language and content for their region. Although Googlebot frequently crawls from US-based IP addresses, it also uses geo-distributed configurations, especially for multilingual or locale-responsive sites.
On your test site, you may find that not all languages are represented, or perhaps there is a different localization process than exists in production. This brings us back to the first point: the preparation site should be as comparable as possible to the production site.
If not, especially for localization items, these should be at the top of your post-deployment controls.
Reference current production performance
A good thing to remember is that your test site may very well be on a less efficient server. This means that when performing speed tests in pre-production, the results may be worse than if the tests were run in production. This can limit your ability to run meaningful checks before deployment.
To work around this problem, be sure to compare performance in production so you can re-run tests quickly after deployment. This will require waiting for changes to be implemented, but it may be the only way to have an accurate understanding of areas like page load speed in situations where the staging server is simply not as good as the production one.
Test for extreme cases
Developers will try to break their code when testing it; we should too. When testing your staging site before deployment, run it in some edge cases. In practice, this means thinking about scenarios that, while unlikely, are possible. For example,
- I am visiting the website from the United States, but my language is French. What language are meta tags in?
- I’m viewing the website on a mobile device but the viewport is set to desktop. What content can I access that I couldn’t otherwise access on mobile?
- If I disable JavaScript, can I still use drop-down menus?
Test previously known issues
Make sure that previous issues have not been reintroduced into the code during the most recent work. Even if the massive rollout is in a small area, like rolling out a new meta title template, that doesn’t mean the issues aren’t reintroduced elsewhere.
Don’t just test the element being edited, but check critical SEO areas. In particular, if work has been done recently to improve the site pages, check that they will still be in place with this latest deployment.
Likewise, if there are known bugs that have affected your SEO performance in the past, check them even if the deployment is not related to them. It’s easy for bugs to reappear in code, especially if they’ve been there before.
More resources:
Featured image: Paul Poetry/Search Engine Journal
