Technical SEO Handover Checklist Before Launch

Why Technical SEO Belongs in the Handover, Not the Afterword

A custom web build can be flawless in code review and still lose months of organic traffic the week it goes live. The reasons are nearly always technical: a noindex left on, a sitemap that never updated, a redirect map that collapses to 302s, canonical URLs that disagree with the ones in the sitemap. None of these are visible from the design handover. All of them belong on an engineer's checklist.

This guide is a pre-launch and migration checklist for custom web builds. It is written for developers, tech leads and anyone running a cut-over. Each item is something to verify, not to describe. For scope and background on SEO in web design more broadly, we have a separate primer; this piece stays at the handover layer.

Staging Protection Before Launch

Staging environments routinely leak into Google's index because they answer 200 to any user agent and carry no access control. A noindex on staging is necessary but not sufficient: a stray internal link, an open directory listing or an accidental sitemap entry can still cause a snapshot to appear in search results.

• Require HTTP basic auth or a VPN at the edge. The right answer to an anonymous request on a staging host is 401, not 200 with noindex.
• Serve X-Robots-Tag: noindex, nofollow on every response as a second line of defence.
• Give staging its own robots.txt that disallows the whole site (User-agent: * / Disallow: /). Do not reuse the production file.
• Remove the staging host from any sitemap, feed or canonical that production emits.
• Confirm you can reach staging only from an authenticated session, including subdomains and feature-branch previews.

Robots Directives at Launch

Launch day flips the gate. The production robots.txt must allow crawling of the paths you want indexed and disallow private areas (login, cart, internal search, filtered facets that explode URL space). A robots.txt that still reads Disallow: / is the single most common launch regression — easy to verify, trivial to miss. Google's own documentation on how robots.txt works is worth re-reading during the handover.

• robots.txt is reachable at /robots.txt and returns 200.
• No path that must rank is blocked (including CSS, JS and image hosts needed to render the page).
• Meta robots and X-Robots-Tag are not blanket noindex. Grep the codebase for leftover development flags.
• robots.txt points to the correct sitemap URL on the production host.

XML Sitemap

The sitemap is a signal to crawlers about what exists, not a magic indexing lever. Follow the sitemap guidance in Search Central: UTF-8, under 50 MB uncompressed and under 50,000 URLs per file, with an index file above that. Generate it from the same source of truth that renders the pages — a hand-kept list is correct until the next publish and silently wrong afterwards.

• Every indexable, canonical URL is listed exactly once.
• Non-canonical, redirected, blocked or paginated URLs are excluded.
• <lastmod> reflects the content's real update time, not the build clock.
• The sitemap is referenced from robots.txt and submitted in Search Console after launch.

Canonical Tags

Canonicals tell crawlers which URL is the authoritative version when alternates exist. Mis-set canonicals are a classic cause of indexing drift. Review the rules in the canonicalisation documentation and verify on real pages, not just in templates.

• Every indexable page carries exactly one self-referential canonical, absolute URL, matching protocol and host.
• Paginated listings canonicalise to themselves, not to page one.
• Filter and query-string variants either self-canonicalise, canonicalise to the clean URL, or return noindex — pick one policy and apply it consistently.
• Alternate language versions use hreflang, not cross-language canonicals.

HTTP Status Codes

Status codes are the API crawlers trust. Content that returns 200 gets indexed; content that returns 404 or 410 gets dropped; 5xx on repeat causes URLs to fall out of the index.

• Spot-check every template: homepage, listing, detail, category, author, search, pagination, 404.
• Error pages return the correct status code, not a soft 200 rendering of a "Not Found" template.
• Blocked or legally removed URLs return 410 rather than 200 with a holding page.
• Rate-limited endpoints return 429 instead of empty 200s to Googlebot.

Redirect Mapping During Migrations

A migration without a redirect map is a traffic reset. Build the map from the old live sitemap plus the top organic landing pages from analytics, not from a tidy spreadsheet of what the stakeholders remember. Google's guide to a site move with URL changes covers the sequencing in detail.

• Permanent moves return 301 (or 308 when the method must be preserved). 302 is for genuinely temporary swaps only.
• One hop, not a chain. Point every old URL at its final destination directly.
• Preserve query strings and fragments where the destination needs them.
• Keep redirects live for at least 12 months — Google needs repeat crawls to consolidate signals.
• Spot-check high-value URLs with a crawler before switching DNS, and again immediately after.

URL Consistency and Trailing Slashes

Pick one URL form per route and enforce it with a 301. Inconsistency across templates, sitemap and canonical is the fastest route to self-cannibalisation.

• Decide trailing-slash policy at the server, not per template. /path and /path/ must not both answer 200 with the same body.
• HTTP redirects to HTTPS. The www and apex versions are not both canonical.
• Lowercase-only paths. Mixed case variants 301 to the lowercase form.
• Internal links, sitemap, canonical and schema @id all use the same form.

Crawlability and Internal Links

Any page that is important enough to rank must be reachable by following links from the homepage within a few hops. Orphan pages — those with no incoming internal links — depend entirely on the sitemap, and that is a weaker signal.

• Run a full crawl from the homepage and compare the discovered URL list to the sitemap. Investigate the diff in both directions.
• Navigation, breadcrumbs and footer links use real anchor tags with real hrefs, not onClick handlers on <div>s.
• Pagination exposes a crawlable path to every page in a long listing. Infinite scroll has a non-JS fallback.
• Internal links in body copy use descriptive anchors, not "click here".

Rendered Content

Googlebot renders JavaScript, but rendering is a second-pass, best-effort activity. Content that depends on client-side fetches may appear in the index late, incompletely or not at all. Prefer server-rendered HTML for anything that must rank.

• Open the page with JavaScript disabled: the main heading, body text and primary links must be present.
• View the page source (not the DOM) and confirm the ranking content is in the HTML response.
• Test with Google's URL Inspection tool after launch to see the rendered HTML Google actually produced.
• Lazy-load media below the fold; never lazy-load the LCP element or primary copy.

Titles, H1s and Meta in the CMS

Content editors need to change titles and meta without a developer. If the handover does not expose these controls, every future edit becomes a ticket, and most of them never get filed.

• Each page template exposes editable fields for <title>, meta description, H1, OG title/description/image and canonical override.
• Templates emit exactly one H1, derived from a field the editor controls.
• Defaults are sensible when a field is left blank — never an empty <title> tag or a placeholder like "Untitled".
• Preview reflects the final rendered <head>, not a sanitised version of it.

Structured Data

Schema.org JSON-LD is the format Google parses most reliably. Validate it, do not just emit it.

• Every template renders the right types: Organization on home and about, BreadcrumbList on nested pages, Article/BlogPosting on editorial content, Product and Offer on commerce pages.
• Validate with Google's Rich Results Test and the Schema Markup Validator before launch.
• Fields in schema match the visible page content. Hidden prices or ratings get the markup disqualified.
• Multiple JSON-LD blocks are fine; conflicting @ids are not.

Core Web Vitals and Performance

Core Web Vitals are measured in the field, not in the lab, so pre-launch verification sets a floor rather than guaranteeing the result. Follow the current thresholds documented on web.dev — LCP, INP and CLS — and treat lab tooling (Lighthouse, PageSpeed Insights) as a smoke test.

• LCP under 2.5 s on the templates that matter: home, pillar landing, article, product.
• INP under 200 ms on interactive pages (menus, filters, forms).
• CLS under 0.1 — reserve space for images, embeds and ads.
• Fonts load without a layout shift. Hero media has explicit width and height.
• Third-party scripts are audited, lazy-loaded where possible, and never block the main thread above the fold.

Mobile Behaviour

Google indexes the mobile version. Any difference between mobile and desktop is a potential ranking regression.

• Mobile and desktop render the same body copy, the same internal links, the same structured data.
• Tap targets are at least 48×48 CSS pixels with sensible spacing.
• Viewport meta is set and the layout works down to 360 px.
• No horizontal scroll on any production template at any breakpoint.

Broken Links

Run a full crawl of the production host immediately after launch. A clean codebase can still ship with dead links to a migrated article, an unresolved image or a third-party resource that moved.

• Zero 4xx or 5xx on internal links.
• Images, scripts and stylesheets return 200.
• Outbound links to key references are alive.
• Social and Open Graph image URLs resolve.

Analytics and Search Console Handover

Analytics without an owner is noise. Make sure the client has access on launch day, not after the first week of questions.

• Analytics tag fires on every template; conversion events are defined and tested.
• Google Search Console property is verified for the correct protocol and host — ideally the domain property so www, apex and subdomains roll up.
• Sitemap is submitted in Search Console the moment production goes live.
• The client is granted owner-level access; the agency keeps collaborator access until the engagement ends.
• If an external SEO team is picking up the work, they get read access as part of the handover packet. Independent practices like Navicore's post-launch technical SEO work publish the exact artefacts they need at handover — align on that list before launch rather than after.

Post-Launch Crawl

The pre-launch checklist is a prediction; the post-launch crawl is the measurement. Run one within 24 hours of DNS flipping and another after a week, when Google has had time to recrawl.

• Compare the crawl against the sitemap: unknown URLs, orphaned URLs, duplicated titles, missing canonicals.
• Watch Search Console coverage and page experience reports daily for the first two weeks.
• Watch server logs for Googlebot: hit frequency, status mix, discovery of the new URL set.
• Investigate the first ranking drop quickly — most launch regressions are reversible if caught inside a week.

Ownership: Developer Fixes vs Ongoing SEO Work

The handover ends where ongoing work begins. Developers own the mechanics in this checklist: status codes, redirects, canonicals, performance budgets, schema templates, crawlability. SEO specialists own the content strategy, keyword research, link acquisition, competitive analysis and the slow work of earning rankings. The split is not always clean — content tooling, programmatic SEO and performance budgets sit across both — which is why multidisciplinary teams like Navicore run development and search inside a single workflow rather than lobbing tickets between separate agencies.

Whatever the arrangement, document it. Write down which checks the engineering team re-runs on every deploy (status codes, canonical sanity, sitemap freshness), which the content team owns (titles, meta, internal linking), and which the SEO function reports on monthly (coverage, Core Web Vitals field data, visibility). A handover without an operating model is a snapshot that stales within a release.

Treat this list as a verification gate, not reading material. If every item above returns a clean answer against the production host, the technical side of the handover is complete — and the launch becomes a cut-over rather than a cliff.