This week’s Ask SEO Question:
“How do you stress test a staging area to reveal SEO risks before a large-scale launch?”
It’s 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 a “production” site.
A staging site is also often referred to as a “development” site, “pre-production,” or another name specific to your company. It’s a test site intended to show your live site as much as possible to help developers test changes in a safe, private environment before rolling them out.
The “production” site is your live site. It is the one that is accessible to the general public and should work as closely as possible.
There are some cases where developers may deploy directly to the production site without testing on the staging site first. For example, if there is no test site to use, or there is no way to simulate test conditions without making changes to the live site. This is dangerous to do. If the deployment breaks something else in the code, it may negatively affect the usability of the live site.
How to Emphasize-Test The Staging Environment
As SEOs, it’s very important that we test a post that could impact SEO performance before it’s launched. Often times, we find ourselves receiving submissions after they have started to affect traffic and rankings. This is less than ideal, as it can take a while for Googlebot to pick up the changes once a bad submission has been fixed. It’s best to test how Googlebot can process changes before it can do so.
Mirror the Production Area As Closely as Possible
The most important aspect of the staging area is that it is as close to the production area as possible. This is important because it allows any testing you do to produce the same result as if you ran the test in a production environment.
Any deviation between the two conditions must be cataloged. These differences must be addressed so that inspectors know to pay particular attention to areas of the production site that are unique to the stage. When the deployment goes live, testers can quickly verify that 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 is the staging area using different user agents when crawling the site.
By using different agents, for example, imitating Googlebot Smartphone and Googlebot Desktop, there is a high chance that you will encounter technical problems with the site that are not visible when you first crawl. For example, renderings like Googlebot for desktop and Googlebot for mobile can show issues with rendering that only happens on mobile devices.
Be sure to crawl the site with user agents that are relevant to your specific industry. If you target Google News as a channel, be sure to specify the site as a Google News bot. If images or videos are important to your SEO, crawl them as Google-Image and Google-Video bots.
To put your staging site through its paces, make sure you crawl it with a mobile user agent, a desktop user agent, and spoof two search engines, eg, Google and Bing. This way you get a good coverage of the experience of different, important bots. If possible, try crawling as an LLM bot again.
Check the Offer
It’s a good starting point when checking out the staging area before the big feed. Modern websites will often use a lot of JavaScript, which, while not inherently bad, can cause problems for some search bots when processing. For more information about how search bots process JavaScript, see this guide.
Set your browser to include JavaScript rendering, and see what features it can pick up. For example, do you see title tags, meta title, schema tag? Then crawl the site again without JavaScript rendering enabled. Make sure those same elements are still available for bots.
If in doubt, check the spots on the pages on the stage site. Check the Document Object Model (DOM) to see if important code elements are visible on the first page load.
It is important that what you see on the page is what the search bots are able to analyze and provide.
Explore SEO Elements in Bulk with All Page Types
Batch testing is important when testing a site before a big launch. When creating your tests, make sure they are available on different types of pages and, if applicable, in all languages.
If your site uses templates, be sure to check each template is important to your SEO success. For example, on an ecommerce site, this means evaluating category and product pages as the most important.
For multilingual sites, make sure your tests are done in different languages, and set up a VPN to target countries where those languages are important. Filter those countries when using your transparency to make sure users will see the correct language and content for their region. Although Googlebot usually runs from a US-based IP address, it also uses a geo-distributed configuration, especially for dynamic or multilingual sites.
On your staging site, you may find that not all languages are represented, or perhaps there is a different localization process than there is in production. This brings us back to the starting point of needing the staging environment to be as comparable to the production environment as possible.
Otherwise, especially for localization items, these need to be at the top of your post-deployment assessment.
Current Manufacturing Benchmark
A good thing to keep in mind is that your staging site might be on a server that isn’t working properly. This means that when speed tests are done on stage, the results can be worse than if the tests were done in production. This can limit your ability to perform meaningful testing prior to deployment.
To work around this, make sure you benchmark the performance on the product so you can run tests again soon after deployment. This will mean waiting until the changes are live, but it may be the only way to get an accurate understanding of areas like page load speed in cases where the staging server isn’t as good as the production one.
Test For Edge Cases
Developers will try to break their code when testing it; so should we. When testing your staging site before you deploy it, use it in other scenarios. Basically, this means thinking about situations that, although unlikely, are possible. For example,
- I am visiting the website from the US, but my language is set to French. What language are meta tags in?
- I am viewing the website on a mobile device but the viewport is set to desktop. What content can I access that I wouldn’t be able to on mobile?
- If I turn off JavaScript, can I still use the dropdown menu?
Check for Previously Known Issues
Make sure that the previous problems were not recoded during the latest operation. Even if the bulk deployment is for a small area, such as a new meta template being released, that doesn’t mean the issues aren’t reproducing elsewhere.
Don’t just check for conversions, but check for SEO sensitive areas. In particular, if work has recently been done to improve the pages on the site, check that those will still be there with this latest deployment.
Equally, if there are known bugs that have affected your SEO performance in the past, check these even if the posting is not related to them. It’s easy for bugs to creep back into code, especially if they’ve been there before.
Additional resources:
Featured image: Paulo Bobita/Search Engine Journal
