WordPress Technical SEO Launch QA: A 32-Point Release Gate

A redesign can look finished while search engines see a different site: staging noindex remains active, canonical tags point to the old domain, XML sitemaps list redirects, or English pages connect to Chinese canonicals. This 32-point gate is designed for the hour before launch and the first 72 hours after it.

0. Freeze the map before touching production

Export the old site’s indexable URLs, top landing pages, backlinks worth preserving, current titles, canonicals, hreflang pairs, and response codes. Map every old URL to one destination: retained, redirected, deliberately removed, or consolidated. Do not invent a redirect target simply to avoid a 404; a relevant successor is useful, an unrelated homepage redirect is not.

Our redesign SEO migration guide covers project planning. The checklist below is the technical sign-off.

1. Crawl and response checks

1. Production uses HTTPS and one preferred host.
2. HTTP, www/non-www, and known alternate hosts resolve through one clean redirect path.
3. Important pages return 200; redirects return the intended 301 or 308.
4. Redirect chains and loops are removed.
5. True missing pages return 404 or 410, not a soft-404 200 template.
6. CSS, JavaScript, fonts, and meaningful images required for rendering are available to crawlers.
7. No production route depends on login, a geographic block, or a challenge page.
8. The server handles a realistic crawl without repeated 5xx errors.

2. Robots, noindex, and canonical are different controls

robots.txt controls crawling. A noindex robots directive controls indexing after a crawler can read it. A canonical consolidates duplicate or near-duplicate URLs. A redirect moves users and crawlers. Google warns against blocking a page in robots.txt when you expect it to read a noindex directive, and against using robots.txt for canonicalization.

9. Production robots.txt does not contain a copied staging block.
10. Important HTML pages have no accidental noindex meta tag.
11. PDFs or non-HTML assets that must stay out of search use an appropriate X-Robots-Tag.
12. Each unique page has one absolute canonical URL.
13. Canonical targets return 200 and are not noindexed.
14. Canonical tags, redirects, internal links, and sitemap URLs do not conflict.
15. Filtered, tracking, print, and pagination URLs have an explicit, tested policy.
16. WordPress attachment pages are disabled, redirected, or intentionally useful.

3. Sitemap and internal discovery

A sitemap should list the absolute canonical URLs you want in search. It is not a repair list for URLs the site cannot reach. Google accepts up to 50,000 URLs or 50 MB uncompressed per sitemap; larger sites use an index. For a normal WordPress site, the more important test is quality: no redirects, no noindex pages, no staging host, and correct lastmod values when supplied.

17. The sitemap URL returns 200 without authentication.
18. Only canonical, index-intended URLs are included.
19. The sitemap uses the production HTTPS host and absolute URLs.
20. Post types, author archives, tags, and media are included or excluded intentionally.
21. Navigation and contextual links reach every important page without relying on site search.
22. Orphaned campaign pages are linked, consolidated, or removed.

4. Bilingual and structured-data checks

23. Each language page has a self-referencing canonical in the same language.
24. hreflang links are reciprocal and include the correct language/region values.
25. x-default points to the intentional default, not whichever language JavaScript last selected.
26. HTML lang, visible interface, title, description, Open Graph locale, and Article language agree.
27. Structured data describes visible main content and uses the canonical page URL.
28. Organization, logo, author, dates, breadcrumbs, article section, images, and FAQs are accurate.

JSON-LD is easier to maintain, but format is not the main risk. Google’s structured-data policies require accurate, visible, non-misleading information. A valid graph can still be ineligible or simply not selected for a rich result.

5. Measurement and final live test

29. Analytics runs once per page and excludes internal or test traffic by a documented rule.
30. Forms, calls, bookings, consent mode, and thank-you routes are tested in production.
31. Search Console and analytics use the correct canonical property and host.
32. A sample from every template passes live URL inspection, rendered HTML review, rich-results validation where applicable, and a mobile visual check.

Use URL Inspection correctly

Search Console’s indexed view reports Google’s stored version; the live test checks whether the current page can be accessed and processed. A green live result is not a promise of indexing. Compare user-declared and Google-selected canonical, review the rendered HTML, then request indexing for a small number of changed URLs. For many URLs, submit a clean sitemap and let normal crawling proceed.

The first 72 hours

• Hour 0–2: crawl production, verify redirects and canonicals, submit the sitemap, and test the money pages.
• Day 1: review server errors, analytics continuity, form delivery, sitemap fetch, and unexpected noindex or canonical changes.
• Day 3: compare indexed/live samples, inspect new 404s, and confirm important old URLs reach their mapped destinations.
• Week 2: compare landing-page impressions and clicks by directory, not just sitewide totals.

Frequently asked questions

Should a redesigned site be resubmitted as a new Search Console property?

Not when the canonical protocol and host are unchanged; keep the existing property and submit the updated sitemap. Add or verify a property when the protocol, subdomain, or domain changes, while retaining access to the old property for migration monitoring.

Does requesting indexing make Google index a page?

No. It asks Google to recrawl the URL. The page still needs to be accessible, useful, canonicalized correctly, and eligible for indexing.

Should every WordPress archive be in the sitemap?

No. Include archives that offer a useful, distinct browsing page. Thin author, date, tag, attachment, or search pages can create redundant paths without helping readers.

Sources and scope

The gate follows Google Search Central and Search Console documentation checked in August 2026. Plugin interfaces change, so test the rendered production output rather than assuming a checkbox produced the intended tag. Passing this gate does not guarantee indexing or rankings.