Website Release SEO Gate Template

Release Gate Sheet (fill-in)

When to use: One sheet per release: a critical URL sample with status, robots, canonical and analytics, plus the rollback owner and sign-off.

Release SEO gate sheet

Fill one sheet per release. Check the same sample on staging before the deploy and on production right after it.

• Release: [version or ticket] · Deploy window: [date, time, time zone]
• What changed: [templates, routes, config, CMS, CDN, robots.txt]
• Production host: [https://www.example.com] · Staging host: [staging URL]

Critical URL sample

Pick one URL per template the release touched, plus your top pages and the files every release can break.

Rollback owner and sign-off

• Rollback owner: [name, phone or chat handle] · Can roll back without approval: [yes / no]
• SEO check by: [name] · Engineering check by: [name]
• Rollback trigger: [any critical URL fails status, robots or canonical]
• Gate result: [go / go with follow-up ticket / no-go] · Signed: [name, time]

Completion check: every row filled on staging and on production, no fail left open without a ticket, rollback owner named and the sheet saved with the release notes.

Staging-to-Production Go-Live Checklist

When to use: The first launch from staging: remove access blocks, set the canonical host, check redirects, sitemap and tracking, and sign off.

Before you switch DNS or promote the build

Staging is usually hidden in three ways. Every one has to come off production, and only production.

1. HTTP auth or login wall: removed on production. Keep it on staging.
2. robots.txt: production file is not the staging Disallow: /. Build a clean one with the robots.txt generator if you need a fresh start.
3. noindex: no <meta name="robots" content="noindex"> in the HTML and no X-Robots-Tag: noindex header from the server, CDN or platform setting.

Canonical host

• One host wins: [https://www.example.com]. The other versions (http, non-www) 301 to it in one hop.
• Canonical tags are absolute and point at the production host, never the staging host.
• Internal links, hreflang and Open Graph URLs use the production host. Search the HTML for [staging hostname].

Redirects

• Any URL that existed before go-live returns 200 or one 301 to its new home.
• Trace a few with the Redirect Checker: one hop, final status 200, no loop.
• Changing many URLs? Use the full migration checklist and redirect map instead of this page.

Sitemap and Search Console

• The sitemap lists production URLs that return 200 and are indexable.
• The sitemap is referenced in robots.txt and submitted in Search Console for the production property.

Tracking

• Production analytics ID is live, not the staging or test ID.
• Key events fire once: [form submit, purchase, signup].
• Consent banner behaves as on staging.

Launch sign-off

• Go-live approved by: [name] · Time: [time]
• Staging still locked after launch: [yes, checked from a logged-out browser]

Pre-Release Checks

When to use: What to test on the staging or preview build before the deploy so production config is right on day one.

Run these on staging before the deploy

Staging is locked, so test it with auth on. You are checking that production config will be right, not that staging is indexable.

• Diff the SEO config: robots.txt, meta robots defaults, canonical base URL and analytics ID come from environment variables, not hard-coded values.
• Template check: each changed template still outputs one title, one meta description, one canonical and an H1.
• Raw HTML: view the server HTML and headers before JavaScript runs. The Source Code Viewer shows raw source, meta tags and HTTP headers for a public URL.
• Rendering: content and links that matter are present after render, not only after a click.
• Routes: renamed or removed routes have redirects in the same release.
• Status codes: missing pages return 404, not 200 with an error message.

Gate rule

If any pre-release check fails on a critical template, the release waits or ships with that template unchanged.

Post-Release Smoke Test

When to use: A timed check for the first 15 minutes, first hour and first week after the deploy.

First 15 minutes

Run the full critical URL sample on production. Use a logged-out browser and a server-side fetch, because caches and logins hide problems.

• Every sample row matches its expected status, robots and canonical.
• /robots.txt returns 200. A 5xx here can make Google pause crawling the site.
• Response headers show no stray X-Robots-Tag.
• Analytics shows live visits on the production ID.

First hour

• Inspect 2 or 3 key URLs with the URL Inspection live test in Search Console. Read the crawl allowed and indexing allowed lines.
• Check that CDN or cache purges finished and old HTML is not still served.

First day and first week

• Run a free website audit to scan status codes, redirects, robots.txt, noindex and canonicals across a sample of pages.
• Watch server logs or crawl stats for a jump in 404 or 5xx responses.
• Check the Page indexing report in Search Console over the next days for new excluded reasons, such as "URL marked 'noindex'".
• Compare organic clicks to the same weekday last week, not to yesterday.

Rollback Rules

When to use: Agreed triggers that decide rollback, hotfix or ticket, and who makes the call.

Agree these before the deploy, not during it

Why fast matters

• Google says pages with a noindex are dropped when it recrawls them.
• Google generally caches robots.txt for up to 24 hours, so a bad file can affect crawling after you fix it.
• URLs that keep returning server errors are eventually removed from the index.

After any rollback: rerun the critical URL sample, note what failed in the release notes and add a check so it can't pass the gate again.

Gate by Release Type

When to use: Scale the gate to the change, from a CMS copy edit to a framework upgrade or first go-live.

Match the gate to the release

Not every deploy needs the full sheet. Use the change type to decide how much to check.

Common places SEO settings hide

• Environment variables for base URL and robots defaults.
• A CMS "discourage search engines" or "hide from search" toggle.
• CDN or edge rules that add headers.
• Feature flags that serve a different template to some users.

Worked Example (fictional bookkeeping software)

When to use: A filled-in gate for an invented SaaS release where a staging header rule nearly shipped noindex on the pricing page.

Worked example: Tallyfin pricing redesign

Example only. The company, people, URLs and figures are invented to show what a usable, filled-in version looks like.

Tallyfin, an invented bookkeeping software company, shipped a new pricing and plan-comparison template on a Tuesday. Release 4.12, deploy at 10:00.

• What the gate caught: the new pricing route had a header rule copied from the staging edge config. The HTML looked fine. Only the response headers showed the noindex.
• Decision: no-go at 09:40. Fix moved the rule to staging only. Recheck passed at 10:25, deploy at 10:30.
• Rollback owner: Mara (platform), with authority to revert without approval.
• Post-release: URL Inspection live test on /pricing showed indexing allowed. Audit on day 2 found no new noindex pages.

Why this worked

The sheet checked headers, not just the HTML, and the sample included the one template the release changed. The rollback owner was named before 10:00, so the no-go call took minutes.

Next step

Paste your critical URLs into the Source Code Viewer to see raw HTML and headers, and trace old URLs with the Redirect Checker. Then run a free website audit the day after release.