This is a sponsored post written by SEORadar. The opinions expressed in this article are the sponsor’s own.
Quality Assurance (QA) Testing for SEO is a huge challenge! Critical problems can (and do) slip through the QA process, particularly in large organizations.
In this article, I will review how you can use SEORadar to automate the process of testing a staging environment for changes that can damage SEO.
Each Website Update Brings Risk
You have product managers, engineers, designers, and content writers all making changes that can affect SEO. The number of touchpoints that can affect SEO is huge and the more hands in the mix, the greater the chance that something can go wrong.
I used to run SEO for Trulia, at the time the second largest real estate site in the U.S. and in the midst of a brutal battle with the number one! Our traffic was dominated by SEO and as a public company, the pressure to meet traffic goals was intense. All in-house SEOs face that same intense pressure.
One morning I received an email from the CEO. He was definitely SEO savvy and was checking out some HTML. Why was it that our most important phrase on the most important page template was not an H1? I assumed he was not reading the HTML correctly.
I pulled up the source code and – to my horror – the H1 had been removed. My CEO had detected a problem that had slipped by our QA process as well as me! I had some serious explaining to do! Turns out there had been a minor update to the site the day before and as result, the H1 indeed disappeared.
How did this happen? Our site was massive, with nearly 90 million indexed URLs and more than 30-page templates with many variations of each.
When it comes to testing an update, the numbers are daunting. Consider a typical large dynamic site:
- 20+ critical on page items to be reviewed.
- 30 templates.
- To be safe, at least 10 samples of each template should be tested.
- That is 12,000 things to review (not counting lower priority items that can still impact traffic).
- This is still a relatively small test, yet a huge amount of work.
Is it any wonder the industry is littered with stories of SEO initiatives getting deployed live and traffic tanking?
In our case, a quick page update was made and quickly deployed live. The H1 change was simply missed. Not good!
Google is now incredibly fast when it comes to crawling and indexing changes. Even when using a product like SEORadar to monitor production and detect issues, in a matter of days, the damage can be done.
While getting ready to prepare a fix, the issues are propagating across Google’s index. It is critical to catch problems before they go live!
SEO Staging Testing: Verifying Changes
Before giving the OK for a production update, I want to know how the key on-page elements changed!
The variety of items to review for each page include:
- Meta tags, including titles, meta description, meta robots.
- Robots.txt.
- Cross-links, particularly navigation links, footer links.
- Canonical links, hreflang, rel prev and next.
- AMP links and the reciprocal canonical links.
- Keyword usage in important places.
- Rel alternate and canonical back from the separate mobile site.
- Schemas.
- Redirects.
- Key content areas important for SEO.
If the mobile site is separate or adaptive, then all this testing must be replicated there as well. Essentially the work is double!
Back in my days at Trulia, verifying SEO elements was largely a manual task. For a fast-moving startup with multiple releases a week, the risk of missing something was always present.
Automated SEO Testing to the Rescue
An automated SEO QA testing platform is included in SEORadar.
The laborious, time-consuming, and stressful task of validating a pre-release version of website update now is simplified with a straightforward report that identifies any issues at a glance. All you need to do is pull up a report that summarizes all the changes between staging and production.
Let’s take a look at the website Ifly.com, which uses SEORadar to test staging prior to a production update. This is the result of the staging vs. production audit:
No need to parse and compare HTML elements, it’s been done automatically across a controlled set of targeted URLs.
In this case, there are several things that need to be addressed and other things that need to be reviewed before giving the OK to update production.
Let’s zoom in a bit and take a look at the critical alerts:
Everything here needs attention. For instance:
- 59 canonical tags have been removed – sounds bad, but we should look at the details.
- 6 URLs are missing Google Analytics tags – most definitely bad!
We can bring up the details of the alert for specific URLs.
For instance, let check those missing canonical tags:
In this case, there is clearly an issue as the self-referring canonical tag was deleted. If you decide you want the canonical back, you can update the status to “pending” and forward the alert to the appropriate engineer.
Detailed Source Code Diff
You may want to drill into the source code to see all the page changes. Here are some detailed alerts that showed up on a staging audit on our own site (seoradar.com):
Most of the alerts here are pretty obvious, but a couple need further explanation:
- Focus keyword usage generates alerts if pages are potentially de-optimized and we see above that the focus keyword has been changed in a title.
- There are also specific alerts for cross-links being removed, and in the case above a navigation link. Particularly important are persistent links that have been removed (links that have been present for a period of time).
We can pull up a diff on a URL with the alert and see everything that changed on the page.
There are several types of diffs you can run. Here is a section of the structured diff report for the URL that created several of those alerts:
There are definitely some things here I would not let get deployed!
- The title and H1 have been de-optimized for an important keyword, “SEO Testing” (thus the focus keyword alert we saw earlier).
- The meta description has been deleted.
- The meta robots is OK because we don’t want staging to get indexed. However, after deploying to production, we need to make the noindex tag does not get deployed.
If you want to do a full HTML diff you can see that too. Here you can see all changes! There is also a text view that shows content changes only.
SEORadar Access to Staging
If your staging or test site is not available on the Internet, there are a variety of ways to make the audit work:
- Chrome extension: As long as you can access staging then this will work. The Chrome extension fetches the staging version of the page and sends it to our servers which will run the compare vs. production.
- Login: Configure login password and ID.
- Whitelist our IP.
Post Deployment
Once staging is in a state to get deployed to production, you still need to verify the state of production.
Even if staging was perfect, things can still go wrong.
Run a SEORadar diff audit on production which should match your staging audit. However, sometimes production issues may arise so you should not skip this step.
Summary
SEO testing is a difficult and daunting task. Complexity is increasing all the time with new technologies like AMP, JS frameworks, Progressive Web Apps, and Google’s new mobile index.
With so many hands touching a website, every new update creates risk.
An SEO-specific staging testing solution like SEORadar will reduce risk and anxiety, and protect traffic and revenue. Contact us to set up a demo!
Image Credits
Featured Image: Image by SEORadar. Used with permission.
In-Post Photos: Images by SEORadar. Used with permissi
