WordPress SEO Launch Checklist: Before You Go Live

Direct answer: Before launching a WordPress site, confirm that search engines are allowed to index it, preferred URLs return 200, redirects are mapped, canonicals and sitemaps list the same URLs, key content appears in the initial page experience, and analytics conversions work. A visually finished site can still launch invisible to search.

This checklist covers a new WordPress build or a first public launch. If an existing site is being replaced, use a dedicated migration and redesign plan as well, because historic URLs and signals must be preserved.

Freeze the launch URL inventory

Create a table of every page intended for launch with its final URL, page type, indexability, canonical, title, H1, source page and redirect target. This becomes the release contract. Mark staging, preview, search, cart, account and other utility URLs separately so they do not enter the index by accident.

Choose permanent, readable slugs before launch. WordPress describes permalinks as permanent URLs; changing them later requires redirects and updates to internal links. Avoid dates in evergreen service URLs unless the date is part of the content’s lasting identity.

Remove staging blocks at the right time

During development, staging should be protected with authentication or network restrictions. At launch, verify WordPress’s “Discourage search engines from indexing this site” setting is off and inspect the rendered source for unexpected noindex. Check the HTTP X-Robots-Tag header too, because a plugin or server can set it outside the page markup.

Do not rely on robots.txt to keep confidential staging pages out of search. Google’s robots.txt guidance explains that crawl blocking is not a reliable indexing control; use authentication for private environments.

Confirm one preferred version of every URL

Select HTTPS and either the www or non-www hostname. Redirect all alternatives to the preferred version in one hop. Enforce one trailing-slash pattern and consistent lowercase slugs. Each indexable page should output one self-referencing canonical that uses the final URL.

Test common alternatives:

• HTTP to HTTPS;
• preferred and non-preferred hostnames;
• uppercase or accidental duplicate slugs;
• URLs with tracking parameters;
• attachment pages and media URLs;
• pagination, author, tag and category archives.

Map redirects from the previous site

For a replacement site, crawl the old site and combine that list with sitemaps, analytics landing pages, Search Console exports and known backlinks. Map each valuable old URL to the closest equivalent new URL. Use a permanent redirect for a permanent move; do not send unrelated pages to the homepage.

Test the map before DNS or production cutover. Look for redirect chains, loops, mixed protocols and targets that are themselves non-indexable. Keep the redirects long enough for users and search systems to update their references.

Check titles, headings and visible content

Every indexable page needs a descriptive title and one clear visible H1. Navigation labels and page copy should state what the organisation offers in language customers understand. Do not launch template filler, invented testimonials, fake counters or claims that the business cannot verify.

Put essential service information, contact paths and internal links in server-rendered HTML. Page builders may display a section in a browser while hiding it from the initial response or behind interaction. Use Search Console’s URL Inspection live test or the Rich Results Test to compare rendered output.

Validate navigation and internal links

Users and crawlers should be able to reach every important page through normal links. Use a logical route from homepage to service or category to detailed page. Google recommends crawlable <a href> links, not click handlers on generic elements.

• Repair broken and redirected internal links.
• Link guides to their canonical service owner.
• Use descriptive anchors without repetitive exact-match stuffing.
• Keep utility pages out of primary navigation unless users need them.
• Ensure menus and accordions remain keyboard-accessible.

Publish a clean XML sitemap

WordPress core or an SEO plugin can generate XML sitemaps. Use one system, not competing outputs. Google says a sitemap should contain the canonical URLs you prefer to show. Remove redirected, noindex, staging and duplicate URLs. Reference the sitemap index in robots.txt and submit it in Search Console after launch.

Open a sample of sitemap URLs and verify 200 status, self-canonical and indexability. An accepted sitemap is not proof that every URL will be indexed.

Review plugins, themes and structured data

Keep only necessary plugins, update them in a tested staging environment and remove abandoned extensions. Confirm that the theme supports one meaningful page heading, responsive images, accessible controls and stable layouts. Back up files and the database before launch and verify that restoration works.

Structured data must describe visible facts. Check Organization markup on the appropriate organisation page and Article markup on editorial content. Validate with Google’s Rich Results Test, but remember that valid markup does not guarantee a rich result.

Test speed and mobile interaction

Measure representative templates, not just the homepage. Test on a mid-range phone and a constrained connection. Optimise the likely largest content element, reserve media dimensions, avoid loading excessive scripts, and make forms and menus responsive to taps. Compare laboratory findings with field data once enough real-user data exists.

Verify analytics and consent

Test page views, form starts, successful submissions, tap-to-call and other agreed conversions. Prevent duplicate events on refresh. Filter internal testing only through a documented method. Make the consent experience match the organisation’s legal advice and ensure blocked tags behave as intended.

Run the final launch-day sequence

1. Take a recoverable backup and record the release version.
2. Deploy the approved build and redirect map.
3. Remove staging-only index blocks on production.
4. Crawl the site and verify status, canonical, robots and internal links.
5. Test forms, calls and key events on mobile and desktop.
6. Submit the final sitemap and inspect priority URLs in Search Console.
7. Monitor logs, errors, indexing and conversions daily during the first week.

PAKWM’s WordPress development service covers the build context, while its SEO service is the relevant owner for search governance.

Sources

• WordPress.org: permalinks
• Google: build and submit a sitemap
• Google Search guide for developers

Preparing a WordPress launch with search requirements? Request a quote from PAKWM with the launch date, current URL list and conversion goals.