SEO check before go-live with more than 120 checks

When do you need an SEO check before go-live?

Whenever templates, URLs or the way the website is delivered change. That covers a relaunch or a CMS switch just as much as a new product template, a frontend framework update, a new host or changed CDN rules. Many SEO errors come from perfectly normal releases. A template sets noindex, a canonical points to the staging domain, or the test environment's robots.txt ends up on the live server. Functional tests by the developers rarely catch these errors, because the page looks fine to visitors.

On staging, the fix costs a comment on a ticket. After go-live, it costs crawling, indexing and, in the worst case, clicks. And an error in a template hits every page of that type at once.

How do you prepare the sign-off?

A sign-off needs a baseline. If you check staging without one, you see what looks broken and miss what is missing. So decide up front what you compare against, what blocks the go-live and who signs off.

How do you crawl staging for the sign-off?

A sample is not enough for the sign-off. A crawl of the test environment shows whether every page type is reachable and what has changed compared with the live website.

1. Set up access. The crawler logs in via HTTP authentication, uses an access cookie or comes in through an allowlisted IP address.
2. Crawl with a smartphone user agent. Google crawls most pages with its smartphone crawler and mostly indexes the mobile version.
3. Render JavaScript. Otherwise content and links that only appear in the browser are missing.
4. Set the rules. If the staging robots.txt is not the real one yet, configure the crawler to ignore it. It still crawls noindex pages and reports them instead of skipping them.
5. Compare with the reference crawl. Missing page types, new noindex tags, changed titles and lost links show up this way.

HTTP authentication protects the test environment reliably. A robots.txt with Disallow: / or noindex on every page does not prevent access and can go live with the deployment. The details are in the guide Staging environment and SEO.

The checklist by area

The following 14 areas contain more than 120 checks in total. Each table lists the check, how you spot the error, the tool and the timing. “Staging” means before go-live, “Live” right after it and “both” twice. The basis for each area is named in the text above it, and the links are under Sources.

Crawlability and robots.txt

The basis is Google's robots.txt specification. A robots.txt only applies to the host, protocol and port it is served from. Google generally caches the file for up to 24 hours. An accidental block therefore keeps working for a while even after a quick fix. The most common error is the test environment's file on the live server. Rules for AI bots are explained in the guide AI crawlers.

Indexing signals: noindex, canonical and X-Robots-Tag

The basis is Google's documentation on noindex and on canonicalization. A noindex only works if Google is allowed to crawl the page. Combine it with a robots.txt block and Google never sees the noindex. Google only accepts the canonical in the <head> and recommends absolute URLs for it. More in the guide Canonical tag.

Status codes and redirects

The basis is Google's documentation on HTTP status codes and on site moves. Google does not index URLs that return a 4xx status and removes those already indexed. With persistent 5xx errors, URLs eventually drop out too. By default, Google's crawlers follow up to ten redirect hops in a row. For a site move, Google still recommends avoiding chains and sending old URLs straight to their target.

How to test a full redirect mapping is covered in the guide Testing redirects, and the difference between redirect types is explained in 301 vs. 302 redirect.

You can check single URLs in the terminal without any tool. On staging, add -u user:password to the command.

Internal links

The basis is Google's documentation on crawlable links. Google only follows links in <a> elements with an href attribute. Internal links help Google find new pages and understand how they relate. You check many of these points against the reference crawl, because a missing link does not show up in a single crawl.

XML sitemaps

The basis is Google's guide to building sitemaps. A single file may contain at most 50,000 URLs or 50 MB uncompressed. Larger websites split the sitemap and combine the files in a sitemap index. Google only uses lastmod if the date is consistently accurate, and it ignores priority and changefreq. More in the guide XML sitemap.

hreflang

The basis is Google's documentation on localized versions. Each language version lists itself and all the others, and the other side has to link back. Without the return link, Google ignores the annotation. More in the guides hreflang and hreflang and canonical.

Rendering and JavaScript

The basis is Google's documentation on JavaScript SEO, mobile-first indexing and lazy loading. Google mostly indexes the mobile version of a page and does not interact with it while rendering. Googlebot reads the first 2 MB of an HTML file, measured uncompressed. How far source code and rendered HTML can drift apart is shown in the JavaScript crawling study.

Structured data

The basis is Google's general structured data guidelines. The markup has to describe the visible content of the page. If it violates the guidelines, the page can lose its rich results. How AI systems handle markup is covered in the guide Schema markup and AI.

Title, meta description and headings

The basis is Google's documentation on title links. Google builds the title in search results from the title element and other information on the page, and it recommends unique, descriptive titles. Compare each URL with the reference crawl so that optimizations from earlier SEO work survive the go-live.

Images and media

The basis is Google's image best practices. Google does not index CSS background images and finds images through the src attribute of the <img> element. Alt text helps Google understand an image. Google also recommends always referencing an image with the same URL.

Performance and Core Web Vitals

The basis is Google's documentation on Core Web Vitals. Good means an LCP of 2.5 seconds at most, an INP below 200 milliseconds and a CLS below 0.1. Before go-live you measure in the lab, afterwards the field data of real users counts. PageSpeed Insights and the Chrome UX Report summarize this field data over the previous 28 days. Changes therefore only show up there gradually. More in the guide Core Web Vitals.

Tracking and consent

Without clean data you cannot evaluate the go-live. Check tracking as part of the same sign-off. The basis for consent is Google's documentation on Consent Mode. Which tags may load before consent is something you clarify with the people responsible for data protection.

Search Console

The basis is the Search Console help pages. Ownership verification only lasts as long as Google finds the token. If it sits in the old template as an HTML file or meta tag and is missing from the new one, you lose access to the property after a grace period. A domain property is verified via a DNS record and does not depend on the template.

Log files

Log files show what Googlebot actually requests, including URLs that never appear in a crawl. The Googlebot user agent is often faked. Google therefore recommends verifying requests with a reverse DNS lookup or against its published IP ranges. More in the guide Log file analysis.

Monitoring after go-live

A clean staging build can still look different live, for example because of caches, CDN rules or environment variables. Right after the deployment, check every point marked “Live” or “both” in the checklist. After that, continue at fixed intervals. For medium-sized websites, Google says it takes a few weeks or more until the new URLs replace the old ones in search. For large websites it takes even longer.

The sign-off is a snapshot. Every further release can bring the same errors back. Keep checking the critical points, above all robots.txt, robots directives, canonicals and the status codes of your most important pages.

Common mistakes

• The staging robots.txt with Disallow: / goes live.
• An X-Robots-Tag: noindex from the development server configuration stays in place.
• Canonicals, hreflang or sitemap URLs point to the staging domain.
• Unknown URLs return 200, so missing redirects go unnoticed.
• The Search Console verification lived in the old template and is gone.
• New bot protection rules lock Googlebot out.
• JavaScript changes the title or canonical after loading.
• Only staging gets checked, not the live site again.

Frequently asked questions