Why isn’t my WordPress site showing up on Google?

If your WordPress site is not showing up on Google, the first thing to determine is what “not showing up” actually means.

Your website may not have been discovered yet. Google may know about the site but be unable to crawl it. The pages may be crawlable but marked noindex. Google may have indexed them but chosen different canonical URLs. Or the pages may already be indexed and simply not rank for the searches you are testing.

Those are different problems and require different fixes.

Randomly changing SEO titles, resubmitting the sitemap repeatedly or installing another SEO plugin before identifying the cause usually adds more variables without solving anything.

For WordPress sites, several of the most important indexing signals are controlled directly by the site’s SEO configuration. TheOneWP’s SEO Meta module provides page-level controls for metadata such as robots directives and canonical URLs, while other modules can make global visibility and sitemap configuration easier to inspect.

In this guide, we will work through the main reasons a WordPress website may not appear in Google, starting with the basic indexing controls and moving through crawling, sitemaps, canonical URLs, content quality and Search Console diagnostics.

First, understand what “not showing up on Google” means

There are several stages between publishing a WordPress page and seeing it in search results.

A simplified sequence looks like this:

URL exists
↓
Google discovers URL
↓
Google crawls URL
↓
Google processes and renders page
↓
Google evaluates page
↓
Google may index page
↓
Indexed page may appear for relevant searches

A problem can occur at any stage.

This means these two statements are not equivalent:

Google has not indexed my page.

and:

My page does not rank when I search for a keyword.

A page can be indexed while ranking so far down the results that you never encounter it manually.

Indexing and ranking are different

Indexing means Google has added information about a page to its search index.

Ranking refers to where an indexed page may appear for a particular search.

If your page is indexed but appears on page eight for the query you are testing, you primarily have a ranking problem rather than an indexing problem.

If Google explicitly reports that the URL is not indexed, improving keyword placement in the title is unlikely to solve the immediate issue.

Diagnose the stage that is failing before trying to improve the next stage.

Check whether Google has indexed the page

A quick preliminary check is to search for the exact URL or use a query such as:

site:example.com

or:

site:example.com/example-page/

This can give you a rough indication of what Google currently exposes in search.

However, a site: query should not be treated as a complete indexing audit.

For a specific URL you control, Google Search Console provides much more useful diagnostic information.

Use Google Search Console URL Inspection

Google Search Console’s URL Inspection tool can show information about a particular page, including whether Google knows the URL and its current indexing status.

A practical workflow is:

1. open Google Search Console;
2. select the correct property;
3. inspect the exact production URL;
4. review the indexing status;
5. check the reported canonical information;
6. test the live URL when necessary;
7. fix any underlying problem before requesting another crawl.

The official Google Search Console documentation explains how Search Console can be used to diagnose page-level indexing problems.

Do not immediately request indexing before fixing the problem

The Request Indexing button is not an SEO repair tool.

If the page still contains:

• a noindex directive;
• a server error;
• an incorrect canonical;
• an access restriction;
• broken content;

asking Google to crawl it again merely gives Google another opportunity to observe the same problem.

Fix the cause first.

Then request another crawl when doing so is useful.

Check the WordPress Search Engine Visibility setting

One of the first WordPress-specific checks should be:

Settings
→ Reading
→ Search engine visibility

WordPress includes the option:

Discourage search engines from indexing this site

If this remains enabled on a production website, WordPress can output directives asking search engines not to index the site.

This frequently happens when a website was configured this way during development and nobody turned the setting off before launch.

The official WordPress Reading Settings documentation describes this option.

For the detailed WordPress behavior and limitations of the setting, see WordPress’s “Discourage search engines” setting, explained.

Make accidental global noindex harder to overlook

The search visibility setting is simple enough that it is easy to underestimate.

A production website can be completely functional, load quickly and look correct to visitors while still carrying a site-wide instruction discouraging indexing.

TheOneWP’s Search Visibility Notice module is designed to make that WordPress visibility state more obvious inside the administration area.

It does not change how Google makes indexing decisions, and it does not replace checking the actual HTML or HTTP response.

Its purpose is narrower and more practical: make it harder for an important production-wide setting to remain unnoticed after staging, migration or launch work.

Do not confuse the WordPress setting with privacy

The WordPress search visibility setting does not password-protect a website.

Its purpose is to communicate an indexing preference to search engines.

A site may therefore remain completely accessible in a browser while still telling compatible search engines that its pages should not be indexed.

This distinction matters because a website can look perfectly healthy to you while its search directives are telling Google something completely different.

For the distinction between crawler instructions and actual protection, see Robots.txt vs real access control.

Check for a noindex meta tag

Open the HTML source of an affected page and search for:

noindex

You may find:

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

or:

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

A supported noindex directive tells Google not to include that page in search results.

Google documents the mechanism in its official noindex documentation.

Check page-level robots settings in WordPress

A global WordPress visibility setting is not the only place where noindex can originate.

An SEO system may also allow individual posts, pages, archives or custom post types to use different robots directives.

This means a site can be globally indexable while one specific page still outputs:

noindex

When TheOneWP’s SEO Meta module is the component managing page-level SEO metadata, robots directives should be reviewed there alongside the page’s other indexing configuration.

Regardless of which SEO system you use, inspect the final rendered HTML rather than assuming the settings interface is the only component capable of generating the directive.

Check HTTP headers for X-Robots-Tag

Not every indexing directive appears inside the HTML.

A server or application can also return an HTTP header such as:

X-Robots-Tag: noindex

This can prevent indexing even when the visible HTML source contains no robots meta tag.

This distinction becomes particularly important for:

• PDF files;
• images;
• generated files;
• pages controlled through server configuration;
• sites using reverse proxies or security layers.

If Search Console reports a noindex issue but you cannot find one in the HTML, inspect the HTTP response headers too.

Check whether robots.txt blocks Googlebot

Your site’s robots.txt file normally exists at:

https://example.com/robots.txt

A disastrous production configuration might contain:

User-agent: *
Disallow: /

This asks compatible crawlers not to crawl the entire website.

A more subtle mistake may block only an important section:

User-agent: *
Disallow: /guides/

Now the homepage may be crawlable while the entire guide section is restricted.

If you are troubleshooting crawler directives, see Common robots.txt mistakes that hurt SEO.

robots.txt and noindex solve different problems

A robots.txt rule primarily controls crawling.

A noindex directive controls indexing when the crawler can access and process it.

This creates an important diagnostic trap.

Suppose the page contains:

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

while robots.txt simultaneously prevents Google from crawling the page.

Google cannot read a page-level noindex directive on a page it is not allowed to fetch.

Google documents that pages must remain crawlable for its crawler to discover a page-level or HTTP-header noindex instruction.

A robots.txt block does not necessarily remove a known URL from Google

Another common misconception is that adding a URL to robots.txt automatically removes it from search results.

It does not.

Google may know about a blocked URL through links or previous crawling even when it can no longer fetch the page.

This is why crawler management and indexing management need to be considered separately.

Check whether Google can access the page at all

A page cannot be processed normally if Googlebot receives an error or authentication challenge instead of the intended content.

Check whether the production URL returns the expected response.

Potential problems include:

• HTTP 401 authentication requirements;
• HTTP 403 access restrictions;
• HTTP 404 missing pages;
• HTTP 5xx server errors;
• DNS failures;
• connection timeouts;
• firewall rules;
• bot protection blocking Googlebot;
• maintenance mode.

A page that looks correct when you are logged in as a WordPress administrator may behave differently for anonymous visitors or external crawlers.

Test the page while logged out

Open the URL in a private browser window.

This simple test can reveal problems such as:

• login requirements;
• membership restrictions;
• maintenance screens;
• conditional redirects;
• different content for authenticated users;
• plugin-generated access restrictions.

If the public version cannot be accessed properly, Google’s crawler may encounter the same problem.

Check whether the site was accidentally left in staging mode

Development and staging environments often intentionally use:

• noindex;
• restrictive robots rules;
• password protection;
• disabled sitemaps;
• different canonical URLs.

The problem appears when staging configuration is copied to production.

After deployment, always verify that the production site does not still contain:

noindex

or:

User-agent: *
Disallow: /

and that its canonical URLs use the real production domain.

For the broader environment workflow, see WordPress staging site best practices.

Check your XML sitemap

An XML sitemap can help Google discover important URLs.

Modern WordPress includes native XML sitemap functionality, while SEO systems may provide their own sitemap implementation.

Depending on the configuration, your sitemap may be available at a URL such as:

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

or:

https://example.com/sitemap_index.xml

Open it and confirm that the affected page is present when it is supposed to be included.

If an important public page is missing, investigate why.

For a complete explanation of what belongs in these files, see What is an XML sitemap, and why does it matter?.

Use a sitemap to support discovery, not to force indexing

A sitemap is useful because it gives search engines a structured list of URLs that the site considers important enough to expose for discovery.

TheOneWP’s XML Sitemap module provides sitemap management within WordPress for sites using TheOneWP’s SEO tooling.

Its role is discovery and URL communication.

It does not override:

• noindex;
• canonical selection;
• server errors;
• access restrictions;
• Google’s decision about whether a page should be indexed.

A URL being present in a sitemap and simultaneously marked noindex is not a clever way to force Google to choose one. It is simply contradictory configuration.

A sitemap does not guarantee indexing

Finding a URL in the sitemap is useful, but it does not prove that Google has indexed it.

A sitemap helps search engines discover URLs.

Google still decides whether to crawl and index each page.

Therefore, this sequence:

URL is in sitemap
→ therefore URL must be indexed

is incorrect.

Submit the sitemap in Google Search Console

If the site has a valid sitemap, submit its location through the Sitemaps section of Search Console.

This makes the sitemap location explicit and gives you reporting about whether Google can process it.

Do not create a new sitemap every time you publish a post.

A dynamic sitemap should continue updating at the same known URL.

Check whether the page has internal links

Google discovers URLs partly by following links.

If an important WordPress page exists but nothing else on the site links to it, discovery and understanding of its place in the site architecture can become weaker.

Important pages should normally be reachable through meaningful internal paths such as:

• navigation;
• category or taxonomy archives;
• related articles;
• hub pages;
• contextual links inside content;
• custom post type archives.

An XML sitemap is useful, but it should not be the only place where an important page is connected to the rest of the site.

Check for orphan pages

An orphan page is a page with no meaningful internal links pointing to it.

WordPress makes it surprisingly easy to create these.

You can publish a page, obtain a perfectly valid URL and then never add it to:

• a menu;
• an archive;
• a category;
• another article;
• a content hub.

The page technically exists, but the website architecture barely acknowledges it.

For important search content, give Google and visitors a logical path to the page.

Check the canonical URL

A canonical tag tells search engines which URL should be treated as the preferred representative among duplicate or very similar pages.

A normal self-referencing canonical might look like:

<link rel="canonical"
      href="https://example.com/guide/">

A configuration mistake could instead output:

<link rel="canonical"
      href="https://example.com/another-page/">

If your page points canonically somewhere else, Google may decide that the other URL is the representative version.

Manage canonical URLs deliberately in WordPress

Canonical URLs should normally follow the intended URL architecture automatically.

However, page-level overrides can be useful when a specific content relationship requires them.

TheOneWP’s SEO Meta module keeps canonical configuration alongside the rest of the page’s SEO metadata.

This makes canonical information one of the first places to inspect when a specific WordPress URL is crawlable but Google appears to prefer another version.

Do not add custom canonicals casually. A canonical pointing somewhere else is effectively telling search engines that another URL is the preferred representative.

Check Google-selected canonical in Search Console

Google may choose a canonical URL that differs from the one declared by the website.

URL Inspection can report information about:

• the canonical declared by the site;
• the canonical selected by Google.

If they differ unexpectedly, investigate:

• duplicate content;
• redirects;
• internal links;
• sitemap URLs;
• canonical tags;
• HTTP and HTTPS duplication;
• www and non-www duplication.

Check HTTP and HTTPS versions

If a website has migrated to HTTPS, make sure the preferred URLs consistently use:

https://example.com/

rather than exposing conflicting versions such as:

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

Production should redirect obsolete HTTP URLs to the preferred HTTPS versions.

Internal links, canonical URLs and sitemap entries should also use the intended protocol consistently.

Check www and non-www versions

The same principle applies to:

https://www.example.com/

and:

https://example.com/

Choose the preferred hostname and make the website architecture consistent.

The alternative version should normally redirect appropriately to the preferred version rather than remaining available as another copy of the site.

Check whether the URL redirects

Open the page and determine whether it returns its content directly or redirects elsewhere.

For example:

/old-page/
→ 301
/new-page/

If you are checking whether /old-page/ is indexed as an independent page while it permanently redirects elsewhere, you are inspecting the wrong URL.

Google will normally focus on the destination of a permanent move rather than treating the obsolete address as the current content location.

Check for redirect chains

Unnecessary redirect chains complicate crawling:

/page-a/
→ /page-b/
→ /page-c/
→ /final-page/

Where practical, old internal references and redirects should point directly to the current destination.

This also makes troubleshooting considerably easier because humans already have enough layers of indirection in their lives.

Check whether the page returns a soft 404

A page can technically return:

HTTP 200 OK

while its visible content effectively says:

Page not found

or contains almost nothing useful.

Search engines may treat such pages as soft 404s.

If Search Console reports this condition, inspect what an anonymous visitor actually receives.

Do not try to repair a soft 404 by changing the SEO title. The problem is slightly more existential than that.

Check server errors

Intermittent server problems can prevent reliable crawling.

Review:

• web server error logs;
• PHP errors;
• application logs;
• hosting resource limits;
• database availability;
• CDN errors;
• firewall logs.

If Googlebot repeatedly encounters server errors, crawling and indexing can be affected.

Check whether a security plugin blocks crawlers

WordPress security plugins and firewalls can accidentally become overenthusiastic.

Review systems that:

• block bots;
• challenge unfamiliar user agents;
• restrict countries;
• apply rate limits;
• block suspicious IP addresses;
• require JavaScript challenges.

The goal is not to disable security indiscriminately.

It is to verify that legitimate Google crawlers are not being prevented from accessing public content that you actually want indexed.

Check whether JavaScript hides important content

Google can process JavaScript, but JavaScript-heavy architectures introduce additional rendering considerations.

If important page content exists only after complex client-side execution, verify what Google actually receives and renders rather than assuming the browser experience and crawler experience are identical.

This is particularly relevant for:

• headless WordPress sites;
• single-page applications;
• client-rendered content;
• JavaScript-generated internal links;
• lazy-loaded primary content.

For a conventional server-rendered WordPress site this is often less problematic, but custom frontend architectures deserve explicit testing.

Check mobile rendering

Google primarily uses the mobile version of content for indexing.

Therefore, make sure important content and links are not available only in the desktop layout.

Check whether mobile visitors receive:

• the same primary content;
• important headings;
• internal links;
• structured data where appropriate;
• images and alternative information;
• the same indexing directives.

A responsive design should not turn into two materially different information architectures merely because the viewport became narrower.

Check whether the content is genuinely useful

Technical accessibility does not guarantee indexing.

Google does not necessarily index every page it discovers and processes.

A technically correct page may still be left out of the index if it does not appear sufficiently useful or distinct.

Review whether the page offers:

• substantial original information;
• a clear purpose;
• useful detail;
• information not already repeated elsewhere on the site;
• a reason for somebody to search for and visit it.

Thin pages can create indexing problems

Consider dozens of WordPress pages containing:

Title
One sentence
Featured image
Nothing else

They may all be technically crawlable and included in the sitemap.

That does not mean every one of them deserves independent search visibility.

Before assuming Google has malfunctioned, ask whether each URL provides enough standalone value to justify its existence as a search result.

Duplicate and near-duplicate pages can be consolidated

WordPress can generate several URL structures around related content:

• posts;
• category archives;
• tag archives;
• author archives;
• custom post type archives;
• taxonomy archives;
• parameterized URLs.

If several URLs contain substantially the same content, Google may cluster them and choose one representative canonical.

This can make some URLs appear “missing” even though Google understands them as duplicates of another page.

Check custom post types separately

If ordinary posts appear in Google but a custom post type does not, investigate the custom content structure rather than assuming the entire website has an indexing problem.

Check whether the post type:

• has public frontend URLs;
• outputs indexable pages;
• is included in the sitemap;
• has internal links;
• uses correct canonical URLs;
• has useful individual content.

Custom post types can behave differently from normal posts depending on how they were registered and how the SEO system is configured.

For the broader architecture, see WordPress custom post types and SEO.

Check taxonomy and archive pages

Do not assume every WordPress-generated archive should appear in Google.

A useful category containing many related articles can be a valuable landing page.

A tag archive containing one post and no unique content is a different proposition.

If an archive is intentionally marked noindex, its absence from search results is expected behavior rather than an indexing failure.

Check whether the page is new

New content is not guaranteed to appear in Google immediately after publication.

Discovery, crawling and indexing take time.

The amount of time varies based on the site, URL and Google’s crawling behavior.

For a new page:

1. make sure it is internally linked;
2. include it in the sitemap when appropriate;
3. verify that it is indexable;
4. inspect it in Search Console;
5. request indexing when appropriate;
6. allow Google time to process it.

Pressing Request Indexing every eleven minutes does not turn Search Console into a progress bar.

Check whether the entire domain is new

A brand-new website may take time to be discovered and evaluated.

Make sure the site has:

• public crawlable pages;
• internal navigation;
• a functioning sitemap;
• consistent canonical URLs;
• useful content;
• Search Console verification.

Do not assume a site-wide technical failure solely because a newly launched domain has not immediately produced search visibility.

Check whether important pages are linked from the homepage or hubs

Internal linking communicates structure.

If an important guide requires six obscure archive clicks to reach while a low-value page sits in the primary navigation, your architecture may be communicating priorities you did not intend.

Important content does not need to live directly on the homepage, but it should sit inside a clear hierarchy.

Check sitemap URLs for staging or old domains

After migrations, inspect the actual URLs inside the XML sitemap.

Look for accidental values such as:

https://staging.example.com/
https://old-example.com/
http://example.com/

when production should use:

https://example.com/

A sitemap populated with obsolete URLs does not accurately describe the current website.

Check canonical URLs after migration

The same migration problem can affect canonical tags.

A production page might accidentally contain:

<link rel="canonical"
      href="https://staging.example.com/page/">

This sends exactly the kind of signal you do not want after launching the live domain.

Inspect representative URLs after every major migration.

Check WordPress Site Address settings

WordPress stores important URL configuration under:

Settings
→ General

Review:

WordPress Address (URL)
Site Address (URL)

Incorrect values can cause redirects, asset problems and broader URL inconsistencies.

Do not change these values casually on production merely because one page is missing from Google, but verify them when a migration or domain change has occurred.

Check whether SEO plugins conflict

Running several components that all control indexing can produce contradictory output.

Potential generators include:

• SEO plugins;
• themes;
• custom snippets;
• security plugins;
• maintenance plugins;
• server headers.

For example, one component may output:

index, follow

while another outputs:

noindex, follow

Inspect the final rendered response rather than assuming the last settings panel you opened is the only system involved.

Choose one primary owner for page-level SEO metadata

Canonical URLs, robots directives and other page-level SEO metadata should have a clear source of truth.

If several systems attempt to manage the same values, troubleshooting becomes considerably harder because the WordPress editor may show one setting while the final HTML contains another.

TheOneWP’s SEO Meta module can serve as that page-level metadata owner when TheOneWP is being used for the site’s SEO configuration.

Before migrating to it or any other SEO system, inspect existing metadata and disable overlapping output where appropriate.

Do not install another SEO plugin just to force indexing

If the site already has an SEO system producing correct metadata, adding another one can introduce:

• duplicate canonical tags;
• conflicting robots directives;
• multiple sitemaps;
• duplicate structured data;
• competing social metadata.

Indexing problems are better diagnosed than outnumbered.

Check for accidental noindex after an SEO plugin migration

When changing SEO systems, verify that per-page indexing settings migrated correctly.

Important pages can accidentally inherit:

noindex

or lose custom canonical information if metadata formats differ between plugins.

Audit representative pages rather than assuming the replacement system interpreted every stored field correctly.

See Migrating SEO fields between WordPress plugins for the wider migration process.

Check Search Console Page Indexing reports

URL Inspection is useful for individual pages.

The broader Page Indexing reports in Search Console can help identify patterns across the site.

You may discover groups of URLs affected by conditions such as:

• excluded by noindex;
• redirected pages;
• not found responses;
• server errors;
• duplicate pages;
• crawled but not indexed URLs;
• discovered but not indexed URLs.

A repeated pattern across hundreds of URLs usually deserves a structural investigation rather than hundreds of individual button clicks.

What does “Discovered – currently not indexed” mean?

This generally means Google knows about the URL but has not currently indexed it.

The immediate question is therefore no longer:

How do I make Google discover this URL?

Google already knows it exists.

Instead, examine:

• site architecture;
• internal linking;
• server reliability;
• content usefulness;
• duplication;
• whether the URL genuinely deserves independent indexing.

What does “Crawled – currently not indexed” mean?

In this situation Google has already crawled the URL but is not currently including it in the index.

Submitting the sitemap again is unlikely to address the fundamental issue because discovery and crawling have already occurred.

Review the page itself and its relationship to the rest of the site.

Ask whether it is:

• substantially unique;
• useful;
• canonical;
• internally connected;
• free from conflicting indexing signals;
• meaningfully different from other pages.

What does “Duplicate without user-selected canonical” mean?

This indicates that Google considers the URL a duplicate and another version may be selected as canonical.

Review duplicate URL patterns such as:

• HTTP and HTTPS;
• www and non-www;
• URL parameters;
• print versions;
• duplicate archives;
• multiple URLs exposing the same underlying content.

Then align canonical tags, internal links, redirects and sitemap entries around the preferred version.

What if the homepage is indexed but posts are not?

If Google knows the homepage but not deeper content, examine discovery and indexing at the page level.

Check whether posts:

• appear in navigation or archives;
• are present in the sitemap;
• contain noindex;
• use self-referencing canonicals;
• return HTTP 200;
• contain useful content;
• are publicly accessible.

A functioning homepage proves that the domain exists. It does not prove that every content template is configured correctly.

What if some WordPress pages are indexed and others are not?

This usually points toward a page-level or content-type-level difference rather than a complete site blocking issue.

Compare an indexed URL and a non-indexed URL.

Look for differences in:

• robots directives;
• canonical tags;
• HTTP status;
• internal links;
• sitemap inclusion;
• content depth;
• template behavior;
• post type configuration.

Comparing one working page with one failing page is often more productive than staring at global settings until they confess.

What if the site used to appear on Google and disappeared?

A sudden loss of previously indexed pages deserves additional investigation.

Check whether something recently changed:

• site migration;
• domain change;
• HTTPS migration;
• SEO plugin;
• robots configuration;
• WordPress Reading settings;
• canonical tags;
• URL structure;
• server availability;
• content removal;
• manual actions or security issues reported in Search Console.

The timing of the visibility change can help narrow the investigation considerably.

Do not use robots.txt to fix a noindex problem

If a page contains an accidental noindex, remove the incorrect indexing directive.

Do not then block the page in robots.txt.

Google needs to crawl the page again to observe that the noindex has been removed.

Blocking crawling at that moment can prevent the crawler from seeing your correction.

Do not remove a page from the sitemap just because it is not indexed yet

If the URL genuinely belongs in search and remains canonical and indexable, removing it from the sitemap solely because Google has not indexed it does not address the underlying reason.

Sitemap inclusion is not a reward granted after indexing.

It is part of URL discovery and site communication.

Do not change URLs repeatedly while troubleshooting

If a page is not appearing in Google, repeatedly changing:

/guide/
/wordpress-guide/
/best-wordpress-guide/
/ultimate-wordpress-guide/

creates new URLs and migration problems while destroying the stable target you were trying to diagnose.

Keep useful URLs stable unless there is a genuine architectural reason to change them.

Do not publish dozens of near-identical pages hoping one gets indexed

Creating more pages does not automatically create more search visibility.

If ten URLs answer essentially the same question with slightly different wording, the site may simply have created ten pages competing to represent one concept.

Consolidation can be more useful than multiplication.

A practical WordPress indexing diagnosis workflow

When a page is missing from Google, use a consistent sequence instead of changing everything simultaneously.

Step 1: Inspect the URL in Search Console

Determine whether Google knows the URL and what indexing state it reports.

Step 2: Test the live URL

Verify that the production page is accessible.

Step 3: Check WordPress search visibility

Make sure the production site is not globally discouraging indexing unintentionally.

Step 4: Check robots directives

Look for noindex in both HTML and HTTP headers.

Step 5: Check robots.txt

Make sure important paths are crawlable.

Step 6: Check the HTTP response

Confirm the intended page returns correctly rather than redirecting, failing or requiring authentication.

Step 7: Check the canonical

Make sure the page does not identify another unintended URL as canonical.

Step 8: Check the sitemap

Confirm that eligible important URLs appear where expected.

Step 9: Check internal links

Make sure the page is connected logically to the website.

Step 10: Review content quality and duplication

If Google has already crawled the page, investigate whether the page deserves separate indexing.

Step 11: Fix the underlying issue

Do not request another crawl until the relevant problem has actually been corrected.

Step 12: Request recrawling when appropriate

After the fix, use Search Console when a manual request is useful and allow time for Google to process the change.

WordPress not showing on Google checklist

• Verify the site in Google Search Console.
• Inspect an affected URL with URL Inspection.
• Determine whether the problem is discovery, crawling, indexing or ranking.
• Check WordPress Search Engine Visibility.
• Search the page source for noindex.
• Check HTTP headers for X-Robots-Tag.
• Review robots.txt.
• Test the page while logged out.
• Check its HTTP status code.
• Review firewall and security-plugin restrictions.
• Check the canonical URL.
• Compare the declared canonical with Google’s selected canonical.
• Check HTTP and HTTPS consistency.
• Check www and non-www consistency.
• Look for unexpected redirects.
• Check the XML sitemap.
• Submit the sitemap through Search Console.
• Make sure important pages have internal links.
• Look for orphan content.
• Review custom post type indexing settings.
• Check for duplicate or near-duplicate pages.
• Review content usefulness.
• Check for staging URLs or staging directives.
• Review server errors and logs.
• Check mobile rendering.
• Fix the actual problem before requesting another crawl.

Check these issues before launching a new WordPress site

Many indexing emergencies are considerably easier to prevent than to diagnose after launch.

Before making a new WordPress site public, verify:

• search visibility settings;
• robots directives;
• canonical URLs;
• production domain references;
• XML sitemap availability;
• HTTPS redirects;
• important internal links;
• server accessibility;
• representative pages in Search Console after launch.

The full deployment-oriented review is covered in A WordPress pre-launch SEO checklist.

Using TheOneWP when diagnosing indexing problems

TheOneWP cannot force Google to crawl, index or rank a page.

What it can do is make several of the WordPress-level signals involved in the process easier to manage and inspect.

The primary module for page-level indexing configuration is SEO Meta.

It belongs in the part of the diagnostic process involving:

• robots directives;
• canonical URLs;
• page-level SEO metadata;
• content-type-specific SEO configuration.

The Search Visibility Notice module addresses a different problem: making WordPress’s global search visibility state difficult to overlook when a production site is still configured to discourage indexing.

The XML Sitemap module supports the discovery side by maintaining the sitemap configuration used to expose eligible URLs to search engines.

The responsibilities remain separate:

Search Visibility Notice
→ warn about global WordPress visibility state

SEO Meta
→ manage page-level indexing and canonical signals

XML Sitemap
→ expose eligible URLs for discovery

Google Search Console
→ show how Google currently interprets the site

None of those tools guarantees indexing.

The goal is to keep the signals generated by WordPress coherent enough that configuration mistakes can be diagnosed instead of hidden beneath another layer of conflicting SEO output.

Use SEO Meta as the page-level source of truth

If several plugins, a theme and custom snippets all generate robots directives or canonical tags, finding the cause of an indexing problem becomes unnecessarily difficult.

TheOneWP’s SEO Meta module can serve as the page-level metadata owner when using TheOneWP for SEO.

A useful workflow becomes:

Inspect Search Console
→ inspect rendered page
→ identify indexing signal
→ review SEO Meta configuration
→ correct the signal
→ verify rendered HTML
→ request recrawling when appropriate

This is considerably more useful than installing another plugin and waiting for Google to be impressed by the increased plugin count.

Final thoughts: why your WordPress site may not show on Google

If your WordPress site is not showing up on Google, do not begin by assuming that Google simply needs another sitemap submission or another SEO plugin.

Determine where the process is failing.

Google first needs to discover and access the URL. The page must be crawlable enough for Google to process the relevant indexing signals. It must not accidentally contain noindex. Canonical information should point to the intended URL. The server must return usable content. Important pages should be linked internally and represented consistently in the site’s architecture.

Even after all of that is correct, indexing is not guaranteed.

Google still evaluates whether a page should be included in its index, and an indexed page still has to compete for visibility for actual searches.

Use Search Console to identify the current state, inspect the final response Google can access and fix the specific problem rather than changing several unrelated SEO settings simultaneously.

Within WordPress, TheOneWP’s SEO Meta can keep robots and canonical configuration under one page-level metadata system, while Search Visibility Notice and XML Sitemap cover the global visibility and discovery sides of the process.

Once discovery, crawling, indexing and ranking are treated as separate stages, the question “Why isn’t my WordPress site showing up on Google?” stops being one giant mystery and becomes a much more manageable diagnostic process.