A WordPress pre-launch SEO checklist

A WordPress pre-launch SEO checklist helps you catch technical, indexing and content problems before a new website becomes publicly available. Launch day is a particularly bad moment to discover that the production site is still set to noindex, important pages point to staging URLs, the XML sitemap contains the wrong content or canonical tags reference a temporary domain.

SEO should therefore be part of the launch process rather than something added several weeks later. You do not need to turn a pre-launch review into a 200-point enterprise audit, but you should verify that search engines can access the correct version of the website, understand its structure and discover the pages you actually want indexed.

This checklist focuses on the WordPress-specific checks worth completing immediately before launch, from search visibility and canonical URLs to internal links, metadata, XML sitemaps, structured data, HTTPS and post-launch monitoring.

Why SEO should be checked before a WordPress launch

A website can look completely finished in a browser while still having serious SEO problems hidden in its configuration.

Common launch issues include:

• WordPress still discouraging search engines;
• noindex directives left over from staging;
• robots.txt rules blocking important sections;
• canonical URLs pointing to the staging domain;
• internal links containing development URLs;
• missing or incorrect XML sitemap entries;
• redirect chains created during a redesign;
• broken links caused by changed slugs;
• missing SEO titles and meta descriptions;
• incorrect Open Graph images;
• structured data describing the wrong content;
• HTTP resources remaining on an HTTPS site.

Many of these problems are easy to fix before launch and considerably more annoying once search engines, customers and analytics systems have already started discovering the new website.

1. Confirm that the production domain is final

Before reviewing individual pages, make sure WordPress is running on the domain that visitors and search engines are actually supposed to use.

Check:

• the primary domain;
• whether the preferred host uses www or not;
• HTTPS configuration;
• WordPress Address;
• Site Address;
• redirects from alternative domain versions.

For example, if the final site is:

https://www.example.com/

you do not want the website simultaneously exposing equivalent versions such as:

http://example.com/
http://www.example.com/
https://example.com/

These variants should normally resolve consistently to the preferred production version.

This is particularly important after a staging migration because URLs can survive inside content, configuration values, widgets, custom fields and plugin settings.

2. Check WordPress Search Engine Visibility

One of the most important launch checks is found under:

Settings → Reading → Search Engine Visibility

WordPress includes the option:

Discourage search engines from indexing this site

This setting is useful during development, but it should normally be disabled when a public production site is ready for indexing.

The official WordPress Reading Settings documentation explains how this option affects search-engine visibility.

Do not assume that migrating from staging automatically changed the setting. Check it directly on production.

Also remember that the WordPress setting is only one possible source of noindex. SEO plugins, custom code, server headers and individual page settings can introduce their own directives.

3. Inspect the robots meta tag

Open several important production pages and inspect their HTML source.

An indexable page will commonly contain something equivalent to:

<meta name="robots" content="index, follow">

or simply no restrictive robots meta directive at all.

A problematic production page might contain:

<meta name="robots" content="noindex, nofollow">

If a page should appear in search results, an accidental noindex directive is obviously something worth discovering before launch rather than three months later while everybody debates why Google appears to hate the website.

Google documents how page-level indexing controls work in its robots meta tag documentation.

4. Review robots.txt

Next, open:

https://example.com/robots.txt

and inspect the production rules.

A staging configuration might contain something extremely restrictive such as:

User-agent: *
Disallow: /

That tells compatible crawlers not to crawl the entire website.

Production rules should instead reflect the real crawling requirements of the site.

It is important to distinguish crawling from indexing. Google explicitly explains that robots.txt controls crawler access and should not be treated as a reliable mechanism for keeping sensitive content private or preventing a URL from being indexed.

For the deeper distinction, read Robots.txt vs real access control.

The official Google robots.txt documentation is also worth keeping nearby when reviewing crawler rules.

5. Make sure the staging site is not replacing production in search

A staging environment should not compete with the production website.

Before launch, confirm that development environments are protected appropriately and that search engines are not being invited to crawl duplicate versions of the final content.

A staging installation may live at addresses such as:

staging.example.com
dev.example.com
example.hostingprovider.com

If those environments contain copies of production content, use real access protection where practical rather than relying exclusively on robots.txt.

Our guide to WordPress staging site best practices covers staging access, test data, email safety, updates and deployment in more detail.

6. Search the database for staging URLs

One of the most common migration problems is leaving old environment URLs inside WordPress content.

Search for strings such as:

https://staging.example.com
https://dev.example.com

They may appear inside:

• post content;
• page-builder data;
• custom fields;
• menus;
• widgets;
• theme settings;
• plugin options;
• image URLs;
• canonical metadata;
• structured data;
• Open Graph metadata.

Use a WordPress-aware search-and-replace process when modifying serialized data. Running a naive SQL replacement across serialized option values can corrupt data because serialized strings store their lengths.

7. Check canonical URLs

Canonical tags help indicate the preferred version of a page when multiple URLs contain duplicate or very similar content.

A production page might contain:

<link
    rel="canonical"
    href="https://www.example.com/services/seo/"
>

Before launch, inspect the canonical tags of several representative pages.

Look for:

• staging-domain canonicals;
• HTTP instead of HTTPS;
• canonicals pointing to unrelated pages;
• homepage canonicals appearing on every page;
• parameterized URLs used unnecessarily;
• conflicting canonical implementations.

Google recommends using consistent canonical signals and linking internally to the canonical version of a URL. See the official canonical URL documentation.

8. Review the permalink structure

Changing URL structure immediately after launch creates unnecessary redirect work, so finalize it before the website becomes established.

Check:

Settings → Permalinks

and make sure the structure reflects the intended site architecture.

A typical content URL might look like:

https://example.com/guides/wordpress-security/

rather than something that exposes unnecessary implementation details or temporary development decisions.

Also review custom post type rewrite slugs and taxonomy bases before launch. Once external websites and search engines start discovering those URLs, changing them becomes a migration rather than a cosmetic adjustment.

9. Test old URLs if the launch is a redesign or migration

If you are replacing an existing website, collect the important URLs from the previous version and verify what happens when they are requested.

An old URL with a direct replacement should generally redirect to the most relevant new URL rather than simply landing on the homepage.

For example:

/old-seo-services/
    ↓ 301
/services/seo/

Avoid unnecessary redirect chains such as:

/old-page/
    ↓ 301
/intermediate-page/
    ↓ 301
/new-page/

where a direct redirect is possible.

Redirects should reflect actual content relationships. Sending every removed URL to the homepage may look convenient in a spreadsheet, but it does not magically turn unrelated pages into equivalent content.

10. Check the XML sitemap

Open the sitemap that the production site intends to expose.

WordPress core can provide a sitemap at:

https://example.com/wp-sitemap.xml

Other SEO systems may use locations such as:

https://example.com/sitemap_index.xml

Review the sitemap and confirm that it contains the canonical public URLs you actually want search engines to discover.

Look for:

• important pages missing from the sitemap;
• staging URLs;
• HTTP URLs on an HTTPS site;
• redirected URLs;
• noindex pages;
• private content;
• unnecessary taxonomy archives;
• custom post types that should not be indexed.

An XML sitemap helps search engines discover URLs, but it does not guarantee that those URLs will be indexed.

For a full explanation, see What is an XML sitemap, and why does it matter?.

You can also review Google’s official sitemap documentation.

11. Review indexable content types

WordPress can generate many public URL types:

• posts;
• pages;
• custom post types;
• categories;
• tags;
• custom taxonomy archives;
• author archives;
• date archives;
• attachment URLs;
• internal search pages.

Being technically public does not automatically mean that a URL deserves to appear in search results.

Before launch, decide which content structures have genuine search value and configure indexing, canonicals and XML sitemaps accordingly.

12. Check SEO titles

Important pages should have descriptive document titles that clearly communicate what each page contains.

For example:

<title>WordPress Development Services | Example Agency</title>

is considerably more useful than:

<title>Services | Example</title>

Review at least:

• the homepage;
• primary service pages;
• product pages;
• important category pages;
• blog or guide templates;
• custom post type templates.

Avoid templates that accidentally produce duplicate titles across large sections of the website.

13. Review meta descriptions

A meta description can provide a concise summary of a page:

<meta
    name="description"
    content="WordPress development, technical SEO and performance services for businesses and agencies."
>

Descriptions should represent the actual page rather than repeating the same generic marketing sentence everywhere.

Google may choose to display another snippet when it considers a different part of the page more relevant to a query, so meta descriptions are not guaranteed search-result copy. They are still useful metadata worth configuring properly before launch.

14. Check headings and visible page structure

Each important page should have a clear visible hierarchy.

A simple structure might look like:

H1: WordPress Development Services

H2: Custom WordPress Development
H2: WooCommerce Development
H2: WordPress Maintenance

H3: Development workflow
H3: Ongoing support

Do not treat headings as decorative font-size controls. They should help describe the structure of the content for visitors, assistive technologies and systems trying to understand the document.

15. Check internal links

Search engines discover pages partly by following links, so important pages should not exist as isolated URLs that only appear inside an XML sitemap.

Review:

• main navigation;
• footer navigation;
• contextual links inside content;
• category and archive links;
• breadcrumbs;
• related-content sections;
• links from high-level pages to deeper content.

Google’s link best practices recommend using crawlable links and meaningful anchor text.

Also make sure internal links point directly to the final production URL rather than passing through redirects unnecessarily.

16. Scan for broken links

Before launch, crawl or otherwise inspect the site for links returning errors.

Pay particular attention to:

• 404 pages;
• broken menu links;
• old staging URLs;
• missing images;
• outdated external references;
• redirect chains;
• links to removed documents;
• incorrect anchors.

This is especially important on migrations because a visually complete page can still contain links copied from the old website structure.

17. Test the 404 page

Visit a deliberately invalid URL such as:

https://example.com/this-page-does-not-exist/

The server should return a real HTTP 404 status rather than showing a 404-looking template with a successful 200 OK response.

The page itself should also help visitors recover by offering useful navigation, search or links to important site sections.

18. Verify HTTPS everywhere

The final website should consistently use HTTPS.

Check for:

• valid TLS certificates;
• HTTP-to-HTTPS redirects;
• mixed-content warnings;
• HTTP canonical URLs;
• HTTP sitemap entries;
• HTTP image URLs;
• HTTP scripts and stylesheets;
• internal links still using HTTP.

A browser padlock is useful, but it is not the end of the review. Metadata and generated URLs should use the preferred HTTPS version consistently as well.

19. Test the mobile version

Do not perform the final review exclusively on a desktop monitor large enough to qualify as furniture.

Google uses mobile-first indexing, meaning the mobile version of content is central to how Google crawls and indexes websites.

Test representative pages on mobile for:

• missing content;
• hidden navigation;
• unusable buttons;
• horizontal overflow;
• overlapping text;
• unreadable typography;
• lazy-loaded content that never appears;
• mobile menus whose links cannot be crawled normally.

Google documents these considerations in its mobile-first indexing best practices.

20. Review performance and Core Web Vitals

Launch is also a useful moment to check performance before real visitors start using the website.

Review major page templates for:

• very large hero images;
• uncompressed assets;
• unnecessary JavaScript;
• third-party scripts;
• layout shifts;
• slow-loading web fonts;
• large DOM structures;
• poor caching configuration.

Google’s Core Web Vitals documentation covers the metrics used to evaluate loading performance, interactivity and visual stability.

Performance optimization should not mean blindly chasing a perfect laboratory score. Fix real bottlenecks that affect users and representative production pages.

21. Check image SEO and accessibility basics

Important images should have appropriate alternative text where the image conveys meaningful information.

Also review:

• image dimensions;
• responsive image output;
• compression;
• modern formats where appropriate;
• descriptive filenames when practical;
• missing assets;
• images loaded from staging domains.

Decorative images should not receive keyword-filled alternative text merely because somebody heard that every image requires SEO optimization. Accessibility and SEO both benefit more from accurate descriptions than from stuffing unrelated phrases into attributes.

22. Check Open Graph and social metadata

Search metadata and social-sharing metadata are separate systems.

Important pages should have sensible Open Graph values such as:

<meta property="og:title" content="Example Page">
<meta property="og:description" content="A useful description.">
<meta property="og:image" content="https://example.com/social-image.jpg">
<meta property="og:url" content="https://example.com/page/">

Check that social metadata does not reference development domains, temporary images or outdated brand assets.

For the complete WordPress implementation, see Open Graph and Twitter Cards for WordPress.

23. Validate structured data

If the website outputs JSON-LD or other structured data, inspect representative page types before launch.

Structured data should describe the content actually visible on the page rather than simply outputting every schema type available in a plugin.

Possible examples include:

• Organization;
• Article;
• Product;
• BreadcrumbList;
• LocalBusiness;
• other content-specific types when appropriate.

Use Google’s Rich Results Test when the markup targets Google-supported rich-result features.

Google’s official structured data documentation explains how the markup is interpreted.

For the underlying WordPress concepts, see JSON-LD schema types explained.

24. Remove placeholder and test content

Search the production site for development leftovers such as:

• Lorem ipsum;
• test posts;
• demo products;
• placeholder author names;
• temporary telephone numbers;
• example email addresses;
• draft navigation items;
• unfinished landing pages;
• duplicate template content.

Search engines cannot infer that an embarrassing test page was merely forgotten. If it is publicly accessible and indexable, it is simply part of the website.

25. Check contact, legal and trust pages

SEO is not only about robots directives and title tags. A production website should also contain the information visitors reasonably need to understand who operates it and how to interact with the organization.

Depending on the website, review:

• contact information;
• about pages;
• privacy policy;
• cookie information;
• terms where relevant;
• company details;
• author information for editorial content.

The exact legal requirements depend on the website, business and jurisdiction, so they should be reviewed separately from the technical SEO checklist.

26. Verify analytics and Search Console

Before launch, make sure the production website is connected to the monitoring systems you actually plan to use.

For Google Search, create or verify the relevant Search Console property.

Google Search Console can be used to:

• inspect individual URLs;
• check indexing status;
• submit sitemaps;
• review search performance;
• identify certain crawl and indexing problems;
• monitor Core Web Vitals and other reports.

Google’s Search Console documentation explains the basic workflow.

27. Submit the production XML sitemap

After launch, submit the production sitemap through Search Console.

For example:

https://example.com/wp-sitemap.xml

or:

https://example.com/sitemap_index.xml

Do not submit an old staging sitemap or a sitemap containing development URLs.

Submitting a sitemap helps Google discover the URL set, but it does not guarantee indexing. Google still evaluates whether individual URLs should be indexed.

28. Inspect important URLs after launch

Once DNS, caching and production deployment are stable, use Search Console’s URL Inspection tool on a small set of representative pages.

For example:

• homepage;
• one main service page;
• one article;
• one product or custom post type entry;
• one important archive page.

Check whether Google can access the live page and whether the canonical and indexing information reflects what you expect.

Google provides the URL Inspection tool specifically for examining indexing information and testing live URLs.

29. Crawl the website again after deployment

A pre-launch crawl is useful, but a post-deployment crawl is equally important because migration itself can introduce new problems.

Recheck:

• status codes;
• redirects;
• canonicals;
• robots directives;
• internal links;
• page titles;
• meta descriptions;
• images;
• sitemap URLs;
• staging-domain references.

The production crawl is the one that matters. A perfect staging audit followed by a broken migration is still, rather inconveniently, a broken website.

30. Monitor indexing after launch

Do not assume the SEO work ends when the website becomes public.

During the days and weeks following launch, monitor:

• Search Console indexing reports;
• sitemap processing;
• 404 errors;
• unexpected redirects;
• canonical issues;
• organic impressions;
• important pages that remain undiscovered;
• staging URLs appearing in search.

New websites can take time to be discovered, crawled and indexed, and Google does not guarantee that every eligible URL will be indexed.

If a WordPress site remains absent from Google after launch, use the troubleshooting process in Why isn’t my WordPress site showing up on Google?.

A compact WordPress pre-launch SEO checklist

If you need a final launch-day version, check these items before making the site public:

• Production domain and HTTPS are correct.
• HTTP and alternate host versions redirect consistently.
• WordPress Search Engine Visibility is configured for production.
• Important pages are not accidentally marked noindex.
• robots.txt does not block required public content.
• Staging remains properly protected.
• No staging URLs remain in content or metadata.
• Canonical URLs point to the production domain.
• Permalink structure is final.
• Old URLs have appropriate redirects when required.
• The XML sitemap loads correctly.
• The sitemap contains the correct canonical URLs.
• SEO titles and meta descriptions are reviewed.
• Heading structure is sensible.
• Important pages receive internal links.
• Broken links and missing assets have been checked.
• The 404 template returns an actual 404 status.
• Mobile layouts and navigation work correctly.
• Performance has been tested on representative pages.
• Images are optimized and use appropriate alt text.
• Open Graph metadata uses production URLs and images.
• Structured data has been validated.
• Placeholder content has been removed.
• Analytics and Search Console are configured.
• The production sitemap has been submitted.
• Important URLs have been inspected after launch.
• A final production crawl has been completed.

Pre-launch SEO is mostly about consistency

The goal of a WordPress pre-launch SEO review is not to predict every ranking outcome before Google has even discovered the site. It is to make sure the production website presents a coherent technical picture.

The domain should be consistent. HTTPS should be consistent. Internal links should point to the preferred URLs. Canonical tags should agree with those URLs. The sitemap should contain the same canonical pages. Pages intended for search should be crawlable and indexable. Pages that should remain private should use real access controls rather than wishful thinking disguised as a robots.txt rule.

When those foundations are correct, search engines can spend their time evaluating the actual website rather than navigating problems created during development and migration.

For Google’s broader recommendations, the official SEO Starter Guide and Google Search Essentials provide the primary reference points for crawlability, indexing and search-friendly website development.