WordPress Page Not Indexed by Google? A Practical Troubleshooting Checklist

A live WordPress page can still be missing from Google, so first confirm whether Google can access and index its URL. It is tempting to search the page title and assume the content is at fault. That check alone cannot tell you whether Google has discovered the page, crawled it, or added it to its index.

Finding out which step has stalled gives you a more useful starting point than rewriting a page that may have a technical issue. This checklist moves from diagnosis through WordPress settings, access, discovery, canonical choices, content, and follow-up. A submitted URL is not guaranteed to be included in Search, so use the status to guide your next move.

Indexing is Google’s process of processing a crawled page and storing it in the Google index, where it may become eligible to appear in Search.

Key Takeaways

• Inspect the exact URL in Google Search Console before changing the page.
• Check WordPress settings and page-level instructions for accidental noindex signals.
• Confirm Google can fetch the URL and find it through links or a sitemap.
• Compare the declared canonical with Google’s selected version.
• Improve distinctive, useful content when Google has crawled but not indexed the page.
• Request indexing once after fixing a real issue, then allow time for Google to respond.

WordPress Page Not Indexed by Google? A Practical Troubleshooting Checklist: What Should You Check First?

Start by inspecting the exact URL in Google Search Console, because a site-wide report and an individual URL answer different questions. “Exact URL” means the full live address, including its protocol and any trailing slash. The URL Inspection tool is Google’s specified way to check one page, while the Page Indexing report groups URLs Google already knows about.

URL Inspection’s indexed-status data describes the most recently indexed version, not necessarily what is live now. Enter the page’s complete address into the inspection tool and read its status. “URL is on Google” means the URL is eligible to appear in Search, not that it will appear for every query.

URL inspection results shown beside a WordPress page

Use the Live Test to check whether the current URL might be indexable. It tests the live page, while the stored status describes what Google last indexed. A difference between those views can explain why a recent fix has not yet changed the indexed result.

Inspect the Exact URL

Look at the inspected URL and its reported status before interpreting a broader report. If the page is currently indexed, the result can still differ from the live version. If it is not, note the reason shown and use the Live Test to check its current condition.

Sites with fewer than 500 pages can usually start with URL Inspection for key pages rather than relying on the Page indexing report. A site-wide view is more useful when you need to spot patterns across many URLs, such as a group affected by the same reason.

Read the Page Indexing Report in Context

The Page indexing report covers URLs Google knows about, but its examples do not form a complete list. A reason in the report can show up to 1,000 example URLs, and the sample is not guaranteed to include every affected page.

Check or report	What it tells you	How to use it
URL Inspection status	Stored status for the most recently indexed version	Check the exact important URL
Live Test	Whether the current URL might be indexable	Compare the live page with stored status
Page indexing report	Coverage patterns for URLs Google knows	Look for site-wide groups or shared reasons
A reason’s example-URL list	Up to 1,000 examples for that reason	Use as a sample, not a complete inventory

Treat “URL is on Google” as eligibility, not a promise that the page will appear for a particular search.

Could a WordPress Setting or Noindex Tag Be Blocking the Page?

If WordPress discourages indexing across the whole site, even a correctly published post can send the wrong signal. Check the site-wide setting first, then inspect instructions attached to the individual page. A published page is not necessarily asking search engines to include it.

The “Discourage search engines from indexing this site” checkbox is in Settings > Reading. As of 2026, clear the checkbox and save the changes to stop WordPress from discouraging indexing. This setting can be easy to miss after moving a staging site to the live site.

WordPress reading settings with the search visibility checkbox

Clear the Site-Wide Visibility Setting

Open the settings reading screen and check whether “Discourage search engines from indexing this site” is selected. If you want public pages considered for Search, clear it and save. Revisit the screen after saving to confirm the change remained in place.

This setting can affect the whole site, so it is worth checking even when only one post appears missing. It does not tell you whether Google has already revisited the page; use the live page and Search Console to check the current state.

Check the Page and SEO Plugin Settings.

SEO plugins often provide a page-level control for whether a post should appear in search results. Open the specific post or page and check its indexing settings. A single-page setting can override what you expect from the site-wide WordPress option.

Inspect the rendered source for a robots meta tag containing noindex. An X-Robots-Tag response header can also carry a noindex instruction, including for a page that does not show the instruction in its visible content.

• Site-wide Reading setting: clear the “disourage search engines” checkbox.
• Page-level plugin setting: make sure the page is not set to noindex.
• Robots meta tag: check the rendered page for a noindex instruction.
• Response header: check for an X-Robots-Tag that says noindex.

Google can read a noindex instruction only when the page is accessible to its crawler and not blocked by robots.txt. Google supports noindex in a robots meta tag or an X-Robots-Tag response header, not in robots.txt. After clearing a setting, verify that the live page no longer sends a noindex instruction.

Is Google blocked by robots.txt, an HTTP error, or a firewall?

A robots.txt block can stop Google from reading a page, but it does not reliably remove that URL from Search. Crawl access is different from indexing permission: robots.txt controls which URLs crawlers can access. Check the file at your website’s root and see whether a rule blocks the important URL or its path.

A URL blocked by robots.txt can still be indexed if other pages link to it. Google may know the address from those links and index the URL without crawling the page itself. That means a robots.txt rule is not a reliable way to keep a page out of search results.

Check Crawl Rules Without Confusing Them with Noindex

Read the rules that apply to Googlebot and compare them with the URL path. A broad rule can affect a folder of pages, while a narrower rule may affect just one address. Check the exact path, because a block on a parent directory can cover a page deeper within it.

Do not treat an allowed URL as a guarantee of indexing. An allowed rule means the crawler can try to access the page; it does not decide whether Google will include that page in Search. The distinction matters when a blocked URL appears in results without its page content.

Confirm Google Can Fetch a Successful Response

Check the response status for the live URL and review any fetch failure reported in Search Console. Google may skip rendering a page that returns a non-200 HTTP status code. Pages returning 200 are sent to the rendering queue unless a robots meta tag or header tells Google not to index them.

If Google cannot fetch the page, check whether a firewall, CDN, security plugin, or hosting rule is restricting the request. Security tools can treat automated traffic differently from your own browser, so a page that loads for you may still fail for Googlebot.

Use the Live Test to see whether Google can access the current URL, then investigate the server or security layer if it cannot. A fetch failure is an access issue, not a reason to rewrite the page. If Search Console reports a fetch failure or non-200 response, resolve the access or server problem before requesting another crawl.

Can Google Find the URL Through Your Sitemap and Internal Links?

Google needs a discovery route before it can crawl a URL, and an internal link or sitemap can provide one. Give the page a clear route in from a page Google already knows, rather than relying on an address with no links pointing to it.

Google recommends sitemaps contain only URLs intended for Search, written as fully qualified absolute URLs with UTF-8 encoding. Check that the page appears in the active sitemap using its live URL, not an old staging address or a different version of the same page.

Check Search Console to see whether you submitted and processed the sitemap. A sitemap submitted through Search Console can be hosted anywhere on a site. Without Search Console submission, a sitemap generally affects URLs beneath its parent directory.

Sitemap check	Correct practice	Limit or detail
URLs and encoding	Use absolute live URLs and UTF-8.	Include only URLs intended for search.
File size and URL count	Keep each sitemap within its limits.	Maximum 50MB uncompressed or 50,000 URLs
priority, changefreq and lastmod	Use lastmod only when consistently accurate	Google ignores priority and changefreq.
Hosting with or without Search Console submission	Submit the sitemap in Search Console	Without submission, it generally applies beneath its parent directory

A single sitemap cannot exceed 50MB uncompressed or 50,000 URLs. If your website has more entries, split them across multiple sitemap files. Google ignores the priority and changefreq values, so adding them does not make a page more important or prompt a faster crawl.

Google uses lastmod when the value is consistently and verifiably accurate and reflects the last significant update. Do not change it just to make a page look fresh. A meaningful internal link from a relevant page gives Google another route and helps visitors reach the content, too.

Keep sitemap entries limited to canonical URLs that you genuinely want considered for Search.

Is Google Choosing a Different Canonical URL?

A page can be crawlable yet absent as a separate result because Google selected another URL as its canonical. Canonical means preferred version: a canonical tag identifies which URL you want associated with duplicate or very similar versions.

For an indexed page, URL Inspection can show the Google-selected canonical. Compare that address with the canonical declared on the page. Google can select a different version, so the tag records your preference but does not guarantee Google will follow it.

Look for versions that may appear to be separate URLs, such as staging and live addresses, HTTP and HTTPS, or www and non-www. None of these variations is automatically wrong; the issue is whether Google and your site treat the intended version consistently.

Check internal links and the sitemap for mixed versions. If they point to several addresses for the same page, Google receives conflicting signals about which URL you consider primary. Use the live URL you want visitors and search engines to treat as the main version.

The Live Test cannot predict which version Google will treat as canonical. It checks the current page, but Google’s choice is reflected in indexed-status information. For a page that is not indexed, do not treat a Live Test as confirmation of its eventual canonical.

Make the canonical tag, internal links and sitemap agree on the version you want Google to treat as primary.

What If Google Crawled the Page but Did Not Index It?

If Google has crawled the page but still hasn’t indexed it, check whether it offers a reason to exist beyond repeating familiar information. Useful difference matters: Google evaluates the whole page experience, including whether the main content is useful, distinctive and easy to access.

“Crawled – currently not indexed” means Google visited the URL but has not added it to the index. “Discovered – currently not indexed” means Google knows the URL but has not crawled it yet. The labels describe different stages, so check the exact status before deciding what to change.

Thin, duplicated or generic content may add little beyond pages already available in Search. A page can be well formatted and still offer no new reason for Google to choose it. Compare its answer, examples and details with what a reader can already find on your site.

Ask whether the page reflects first-hand expertise, includes useful examples, offers original analysis or gives a clearer answer. A practical WordPress tutorial, for instance, can add value through precise steps and screenshots of the actual settings rather than broad advice alone.

• Add specific experience or evidence that supports the page’s advice.
• Resolve gaps in the reader’s question instead of leaving key steps unclear.
• Consolidate genuinely redundant material that serves the same purpose.
• Remove page clutter that hides or interrupts the main content.

Relevant internal links can help Google discover a page, but they do not promise indexing. Use them where they make sense to a reader, such as from a related guide or category page. Avoid adding links solely to make a page appear more important.

Keep a page only when it serves a clear reader need that is not already met better by another URL on the site.

Can JavaScript, Mobile Content, or User Interaction Hide the Page?

A page can return successfully yet appear incomplete to Google if its main content depends on JavaScript or a user action. Check the rendered version to see whether Google can access the same essential information a visitor sees on a mobile device.

Google’s JavaScript Search process has three phases: crawling, rendering and indexing. Google uses the mobile version of a site’s content for indexing and ranking, and crawls it with its smartphone agent. A desktop view alone may not show what Google can access.

Check What Google Renders

URL Inspection can show a rendered page, loaded resources and JavaScript output for an indexed result or a Live Test. Use that view to check whether the important text appears, whether resources load and whether the page has rendered as expected.

Compare the rendered text with the content you consider essential. If a script fails or a required resource does not load, Google may not see the page in the same way as someone using your site. Review both the mobile and desktop layouts.

Keep Essential Content Available Without Interaction

Google will not load primary content that requires a user to click, swipe or type. Keep key information available without those actions. A tab or accordion should not hold the only copy of a page’s main answer if Google must interact with it to reveal that text.

Interactive features can still help visitors browse or organise a page. The key check is whether Google can access the essential information, rather than having it hidden behind an action it will not perform. Test the rendered page after changes to scripts or plugins.

Make the page’s essential text available in the initial accessible experience, then use the rendered view to confirm what Google can see.

When Should You Request Indexing and How Long Should You Wait?

Request indexing only after the live URL is ready, and treat the request as a signal rather than a guarantee. One request is enough for a key URL after you have fixed a real issue and confirmed the page is accessible and indexable.

Google says a new page or site can take about a week to start being crawled and indexed. After a recrawl request, crawling can take a few days to a few weeks. URL Inspection also has a daily limit on indexing requests for each Search Console property.

Repeatedly requesting the same URL will not make Google crawl it faster, and a request does not guarantee inclusion in Search results. Page indexing report validation typically takes about two weeks, and sometimes longer, and is a separate process from a recrawl request.

Use this follow-up checklist after you have made the page ready:

1. Confirm the live URL is indexable.
2. Verify that the intended canonical is in place.
3. Make sure the page is discoverable through a sitemap or relevant link.
4. Request indexing once for a key URL.
5. Record the current status in Search Console.
6. Check back after a reasonable interval.

Note the request date and the status you saw. That makes it easier to tell whether Google’s report has changed, without sending the same request again each day. Set a reminder for a week or more rather than repeatedly submitting the same URL while Google processes the request.

Conclusion

The most useful next step is to act on the specific status of the URL, not to change several WordPress settings at once. A technical obstacle, a discovery gap and a page Google has crawled but not chosen to index need different responses.

Keep the exact URL and its Search Console status to hand as you investigate. If the issue calls for help with the site itself, WordPress development services can address technical work; SEO services can help assess how the page fits the wider site.

If you would like help diagnosing a WordPress indexing problem, contact the team for a practical review.

FAQ About the WordPress Page Not Indexed by Google

How long does it take Google to index a new WordPress page?

A new page or site can take about a week to start being crawled and indexed. After a recrawl request, Google may take a few days to a few weeks to crawl the URL. Those are different stages, and neither is a fixed deadline for appearing in Search. Keep the page live and check its status rather than sending repeated requests.

Should I request indexing every day in Search Console?

No, you should not request indexing every day for the same URL. URL Inspection has a daily limit on requests for each Search Console property, and repeated submissions do not make Google crawl the page faster. Request indexing once after making the live page ready, then give Google time to process it and check the status later.

Can a page blocked by robots.txt still appear in Google?

Yes, a page blocked by robots.txt can still appear in Google if other pages link to its URL. Google may index the address without crawling the page, so it may not have the page’s content available. Robots.txt controls crawler access; it is not a reliable way to remove a URL from Search results.

Does a site: search prove that a WordPress page is not indexed?

No, a site: search is only a quick check and does not prove that a page is absent from Google’s index. Search results can vary, and a query may not show every indexed URL. Use URL Inspection in Search Console to check the exact address and its indexed status, then compare that information with the Live Test if needed.

Why does Google show a different canonical URL from the one I set?

Google can select a different canonical because its preferred version does not always match the canonical tag you declared. For an indexed page, compare both versions in URL Inspection. Then make sure the canonical tag, internal links and sitemap consistently point to the version you want treated as primary.

Do small WordPress sites need the Page indexing report?

Sites with fewer than 500 pages probably do not need the Page indexing report to check key pages. URL Inspection is usually enough to diagnose an individual important URL. The report becomes more useful when you want to look for patterns across many URLs, but its example list isn’t guaranteed to be complete.