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.

For WordPress sites, many of these launch-critical signals live inside the same metadata layer. TheOneWP’s SEO Meta module can manage page-level SEO metadata such as titles, descriptions, robots directives, canonical URLs and social metadata, while dedicated modules can help surface global search visibility and sitemap configuration.

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 disruptive 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 the option.

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

For a more detailed explanation of what the setting does and what it does not protect, see WordPress’s “Discourage search engines” setting, explained.

Make the global search visibility state difficult to miss

A site-wide indexing preference is important enough that it should not remain buried in a settings screen after launch.

TheOneWP’s Search Visibility Notice module makes the current WordPress search visibility state easier to notice inside the administration area.

This does not replace inspecting the actual page response and it does not force search engines to index the website.

Its purpose is narrower: reduce the chance that a production site remains configured to discourage indexing because somebody forgot to revisit a staging-era setting.

3. Inspect the robots meta tag

Open several important production pages and inspect their HTML source.

An indexable page may contain something equivalent to:

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

or simply no restrictive robots directive at all.

A problematic production page might contain:

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

If the page should appear in search results, an accidental noindex directive needs to be corrected before launch.

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

Review page-level robots settings in your SEO system

WordPress’s global Reading setting is not the only place where indexing directives can originate.

Individual posts, pages, archives and custom post types may also have their own robots configuration.

TheOneWP’s SEO Meta module keeps page-level robots directives alongside the rest of the page’s SEO metadata, making it easier to review those signals before launch.

Regardless of which SEO system you use, inspect the final rendered source because themes, custom code or other plugins may also add robots directives.

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 asks 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. robots.txt manages crawler access and should not be treated as a privacy or authorization system.

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

For common crawler-configuration problems, see Common robots.txt mistakes that hurt SEO.

The official Google robots.txt documentation explains how Google interprets these 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 discover 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.

See WordPress staging site best practices for staging access, data isolation, email safety, payment testing and deployment controls.

6. Search the database for staging URLs

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

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. A naive database replacement can corrupt serialized values because those structures store string 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 canonical tags on 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 preferred URLs. See the official canonical URL documentation.

Manage canonical URLs from one clear metadata source

Canonical tags are particularly vulnerable to conflicts when several SEO plugins, themes or snippets generate them simultaneously.

TheOneWP’s SEO Meta module can provide the page-level canonical configuration when it is being used as the site’s SEO metadata owner.

Before launch, verify the rendered page rather than assuming that the canonical shown in one WordPress settings panel is necessarily the only one in the final HTML.

8. Review the permalink structure

Changing URL structure immediately after launch creates unnecessary migration 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 exposing unnecessary implementation details or temporary development decisions.

Also review custom post type rewrite slugs and taxonomy bases before launch. Once external sites 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 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 real content relationships. Sending every retired URL to the homepage does not make those pages equivalent.

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.

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

You can also review Google’s official sitemap documentation.

Keep sitemap generation aligned with indexing intent

TheOneWP’s XML Sitemap module can manage the sitemap used to expose eligible WordPress URLs for discovery.

The sitemap should reinforce the site’s indexing architecture rather than contradict it.

An ideal relationship looks like:

Public canonical page
→ indexable
→ internally linked
→ included in sitemap

rather than:

Page
→ noindex
→ redirected
→ still included in sitemap

A sitemap does not force Google to index a URL. Its job is to help search engines discover the URL set the site considers relevant.

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, canonical behavior and sitemap inclusion accordingly.

For developer-defined content structures, see WordPress custom post types and SEO.

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 more descriptive 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 sentence everywhere.

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

Manage titles, descriptions and indexing metadata together

SEO titles and descriptions do not exist in isolation from the rest of the page’s technical metadata.

A typical page may need:

SEO title
Meta description
Canonical URL
Robots directives
Open Graph title
Open Graph description
Social image

TheOneWP’s SEO Meta module keeps these page-level controls inside one workflow, making it easier to inspect representative production pages before launch.

The important part is still the rendered output. A clean settings screen is useful; correct HTML is what crawlers actually receive.

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 describe the structure of the content for visitors, assistive technologies and systems processing the document.

15. Check internal links

Search engines discover pages partly by following links, so important pages should not exist as isolated URLs that appear only 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 explain the importance of crawlable links and meaningful anchor text.

Also make sure internal links point directly to final production URLs rather than passing through unnecessary redirects.

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 during migrations because a visually complete page can still contain links copied from the previous 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

Google primarily uses the mobile version of content for indexing, so representative pages need to be tested at mobile widths before launch.

Check for:

• missing content;
• hidden navigation;
• unusable buttons;
• horizontal overflow;
• overlapping text;
• unreadable typography;
• lazy-loaded content that never appears;
• mobile navigation whose links are inaccessible.

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

20. Review performance and Core Web Vitals

Launch is a useful moment to test performance before real traffic reaches the website.

Review representative 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 relevant user-experience metrics.

Performance optimization should focus on real bottlenecks affecting users rather than treating a perfect laboratory score as the only objective.

21. Check image SEO and accessibility basics

Important images should have appropriate alternative text when they convey 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 every image field happened to be available. Accurate descriptions are more useful for both accessibility and search understanding.

22. Check Open Graph and social metadata

Search metadata and social-sharing metadata are separate systems.

Important pages should have coherent 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.

TheOneWP’s SEO Meta module can keep social metadata alongside the page’s wider SEO configuration, helping reduce the chance that different components generate competing values.

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 outputting every schema type available in an interface.

Possible examples include:

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

Use Google’s Rich Results Test when markup targets Google-supported structured-data features.

Google’s official structured data documentation explains the general relationship between structured data and search features.

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

Check for duplicate schema and social metadata generators

A production launch is a good time to establish which component owns each metadata layer.

Potential generators include:

• SEO plugins;
• themes;
• social plugins;
• commerce plugins;
• custom PHP;
• page builders.

Multiple systems are not automatically wrong, especially when specialized plugins describe different entities.

The problem appears when they output contradictory canonical tags, robots directives, Open Graph values or structured-data entities for the same page.

Inspect the rendered production HTML and decide which component is responsible for each signal.

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.

If a test page is publicly accessible and indexable, search engines have no reason to understand that somebody intended to delete it later.

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 and 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 help you:

• inspect individual URLs;
• check indexing status;
• submit sitemaps;
• review search performance;
• identify certain crawling and indexing problems;
• monitor page experience 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 one containing development URLs.

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

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 canonical and indexing information reflect the intended production configuration.

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 ultimately matters. A perfect staging audit cannot compensate for a deployment that changes the final output.

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 diagnostic 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.

Using TheOneWP during a pre-launch SEO review

TheOneWP cannot guarantee that Google will index or rank a website after launch.

Its useful role is to make several WordPress-level SEO signals easier to manage consistently before the site becomes public.

The primary module for this workflow is SEO Meta, which can centralize page-level metadata such as:

• SEO titles;
• meta descriptions;
• robots directives;
• canonical URLs;
• social metadata;
• supported structured-data configuration.

The Search Visibility Notice module covers a different launch risk by making WordPress’s global search visibility state more obvious.

The XML Sitemap module supports the discovery side by exposing the site’s eligible public URLs through a structured sitemap.

The responsibilities remain distinct:

Search Visibility Notice
→ surface global WordPress search visibility

SEO Meta
→ manage page-level search and social metadata

XML Sitemap
→ expose eligible URLs for discovery

Google Search Console
→ show how Google processes the live website

Keeping these responsibilities clear is more useful than trying to solve every launch problem with one giant setting panel.

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 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 crawler instructions as a substitute for security.

When those foundations are correct, search engines can evaluate the actual website rather than spending their time encountering problems left over from development and migration.

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

Final thoughts on a WordPress pre-launch SEO checklist

A WordPress pre-launch SEO checklist is primarily about removing avoidable technical contradictions before the website becomes public.

A production page should not be internally linked as the preferred URL while its canonical points to staging. It should not appear in the XML sitemap while carrying an accidental noindex. A public launch should not inherit a site-wide search visibility setting that was deliberately enabled during development.

Review the production domain, indexing directives, robots.txt, canonicals, sitemap, metadata, internal links, redirects, HTTPS, mobile rendering, social previews and structured data as parts of one connected system.

TheOneWP’s SEO Meta module can provide the central page-level metadata layer, while Search Visibility Notice and XML Sitemap address the global visibility and discovery sides of the launch process.

Then verify the live website after deployment.

A staging environment can tell you what should happen. The production crawl, rendered HTML and Search Console data tell you what actually happened.

That final verification is what turns a pre-launch checklist from paperwork into a useful release process.