A new WordPress page may not be indexed because Google hasn’t discovered it yet, because a page-level setting blocks indexing, or because technical signals point Google elsewhere. Start with the URL Inspection tool in Google Search Console instead of changing plugins at random. It tells you whether the page is indexed, whether Google can access it, and which issue deserves attention next.
A live test alone doesn’t prove that a page is in Google’s index. A page can be available to Google during a live check and still show “URL is not on Google” because the index status is based on a previous crawl. Once you know which state you’re dealing with, the fix is usually much more focused.
Summary
- Use URL Inspection to separate an indexing problem from an access problem. A successful live test means Google can fetch the page now; it doesn’t confirm that the page has been indexed.
- Check WordPress settings,
noindexdirectives, robots.txt, canonical tags, duplicate versions, the XML sitemap, and internal links before assuming a recent plugin or theme caused the issue. - Request indexing for a few important URLs or submit a sitemap for many pages, but treat those actions as discovery and recrawl requests—not guarantees of immediate inclusion.
Confirm the Actual Status First
The first step for a WordPress new page not indexed is to inspect the exact URL in Google Search Console. Open the URL Inspection tool, enter the complete page address, and read the indexed result before making changes. You need the appropriate access to the Search Console property to inspect and request indexing for that URL.
The report can show that the URL is on Google, not on Google, or awaiting information from a recent crawl. It can also reveal details about crawling, indexing, canonical selection, and enhancements. Read the status for the inspected URL rather than relying on a general impression from the site.
A live test answers a different question. It checks whether Google can access the page at the time of the test. It may show that the page is available even when the indexed report says the URL is not on Google. In practical terms:
- Indexed status: what Google knows from its latest processed crawl.
- Live test: whether Google can access and evaluate the URL now.
- Search appearance: whether the page is actually returned for a query.
That distinction explains why a newly published page can pass every live accessibility check and still be missing from search results. The page may be technically reachable but not yet discovered, crawled, selected for indexing, or processed into the index.
Use a Google site search as a secondary signal by searching for the page’s full URL or a distinctive phrase from the page. A query such as site:example.com/page-address/ can help locate an indexed version, but it isn’t a complete index report. Search results are samples, not proof that every indexed URL has been returned.
If the page appears in URL Inspection as indexed, the issue may be ranking, query relevance, or a different URL being shown. If it is not indexed, continue with the checks below. Google’s documentation explains that recrawling can take from a few days to a few weeks, so avoid treating a short delay as proof that WordPress is broken. The Google documentation on requesting a recrawl also explains the difference between inspecting individual URLs and submitting a sitemap.
Because of Page-Level Indexing Controls
A page-level indexing control is one of the first things to check when a new page is not indexed on WordPress. Look for a noindex directive, an unpublished status, a visibility restriction, or a plugin setting that tells search engines not to include the page.
Open the page in the WordPress editor and confirm that it is published rather than saved as a draft, private page, password-protected page, or scheduled post. Check the public URL while logged out or in a private browser window. If the page only works for an administrator, Googlebot won’t be able to treat it as a normal public page.
Next, inspect the SEO settings attached to that specific page. Many WordPress SEO plugins expose an indexing option in an advanced panel. The setting should allow search engines to index the page if you want it included. A plugin may output a noindex robots meta tag even when the WordPress page itself appears public. The Yoast instructions for noindexing a WordPress post show where this type of control can appear in the editor; the exact labels may differ between plugins.
Check both the page-level setting and the default setting for its content type. A plugin can be configured to noindex an entire group of pages, such as a particular post type, taxonomy, or archive. If several new pages stopped appearing after a configuration change, inspect the global SEO settings instead of editing each page individually.
Recent theme or plugin changes deserve review, but they aren’t automatically the cause. Look for changes that could affect:
- robots meta tags in the page source;
- canonical tags;
- the generated XML sitemap;
- page visibility or login requirements;
- redirects or changes to the public URL;
- template output that replaces the intended page content.
You can view the page source and search for noindex and canonical. This is a useful confirmation, but interpret the result alongside URL Inspection. A source check shows what the page currently outputs; Search Console shows how Google processed the URL during its latest crawl.
If you find noindex, remove it only when the page is meant to appear in search. Then save the page and confirm that the directive is gone from the public version. If you find no indexing restriction, don’t keep changing SEO settings. Move to discovery and technical signals.
When Google Cannot Discover the URL
If Google cannot discover the new page, make the URL easy to find through the XML sitemap and relevant internal links. A public page can be accessible when you open its address directly and still have weak discovery signals if nothing on the site points to it.
Start by opening the XML sitemap in a browser. WordPress sites may expose a sitemap generated by WordPress itself or by an SEO plugin. Confirm that the new page’s exact canonical URL appears in the appropriate sitemap file. Large sitemap systems can use an index file that links to separate post, page, category, or other sitemap files, so check the linked files rather than stopping at the index.
If the URL is missing, review why. The page may be marked noindex, excluded by a post-type setting, set as private, or omitted because the sitemap provider filters that content type. Fix the underlying setting first. Manually forcing a URL into a sitemap won’t solve a page that is still blocked or configured not to be indexed.
Add useful internal links from relevant public pages. A navigation item, category page, related article, or contextual link can help users and crawlers reach the new page. The link should use the page’s intended public URL and should not pass through an unnecessary redirect. Avoid adding a large number of unrelated links simply to create activity; relevance and clarity are more useful than volume.
Then open the page URL directly in a logged-out browser. Check that it returns the intended content rather than a login screen, redirect chain, error page, or an alternate URL. Also test the exact version you linked, including the preferred protocol, hostname, and trailing-slash format. If the sitemap is reported as unreadable, don’t immediately assume that every page is excluded. A sitemap submission status can mean Google has not successfully fetched or processed it yet. Test whether the sitemap URL is publicly accessible, inspect its format, and check whether the listed URLs are valid. The Google Search Central documentation on recrawling identifies sitemaps as a way to help Google discover many URLs, especially after a launch or site move.
Because of Robots, Canonical, or Duplicate Signals
Robots.txt, canonical tags, and duplicate content signals can keep a technically public WordPress page from being treated as the page you expect Google to index. Review all three before blaming a plugin or theme.
Open the site’s robots.txt file at the standard public location and look for rules that disallow crawling of the new page, its directory, or a broader path containing it. A crawl block can prevent Google from fetching the page content. It is different from a noindex directive: robots.txt controls crawling, while page-level indexing directives tell a crawler how the page should be treated after it can access it.
Be careful when changing robots.txt. A broad disallow rule can affect more pages than intended. Compare the rule with the exact page path and check whether the page is being redirected elsewhere. If the page is blocked, remove or narrow the rule only if that section is intended to be publicly crawled.
Next, verify the canonical URL. The canonical tag should normally identify the version you want search engines to treat as primary. Check that it uses the correct protocol and hostname, points to the intended page rather than the homepage, and doesn’t contain an outdated slug. A canonical tag pointing to another URL is a signal that the inspected page may not be the preferred version.
The URL Inspection report can also show Google’s selected canonical. That result may differ from the canonical declared by the page. When it does, compare the page content, internal links, sitemap entry, redirects, and canonical tags across the competing URLs.
Look for duplicate or near-duplicate versions created by WordPress. Common examples include:
- a page available under both an old and new slug;
- attachment or print-style URLs that repeat the same content;
- category or tag archives that closely reproduce the page;
- HTTP and HTTPS versions;
- different hostname versions;
- query-parameter URLs;
- copied pages created during a redesign.
A duplicate page isn’t automatically a technical failure. Google may choose one version and leave another out of the index. The practical question is whether the excluded URL is the one you want users to find. If it isn’t, consolidate the signals around the preferred URL with consistent internal links, a matching sitemap entry, a suitable canonical, and redirects where appropriate.
After a Sitemap or Recrawl Request
A recrawl request can help Google revisit a page, but it cannot guarantee immediate indexing. Use URL Inspection for a small number of important WordPress pages and use a sitemap when many new URLs need to be discovered.
For an individual page, inspect the exact URL in Search Console and choose the option to request indexing if it is available. Do this after correcting the page, not as a substitute for checking the page. If the URL has a noindex tag, is blocked by robots.txt, or points to the wrong canonical, repeated requests won’t fix the underlying signal.
Google places limits on individual URL submissions, and submitting the same URL repeatedly does not make it crawl faster. A request is best treated as a notification that the page may be ready for another look. It isn’t a promise that the page will be crawled immediately or included in search.
For many new pages, submit the relevant XML sitemap through Search Console. Make sure the sitemap contains the public, preferred URLs and excludes pages that shouldn’t be indexed. A sitemap is especially useful when a site has just launched or when many URLs were added during a structural change.
After submitting, monitor the sitemap status and inspect representative URLs. Don’t assume that a successful submission means every listed page is indexed. Sitemap processing, crawling, canonical selection, and indexing are separate stages.
A sensible sequence looks like this:
If a page still isn’t indexed, return to URL Inspection and read the current reason. Don’t keep submitting the same request while leaving a technical problem untouched. Repeated requests can create the impression of activity without improving the page’s eligibility or discoverability.
A Step-by-Step Troubleshooting Workflow
The most reliable way to fix a WordPress new page not indexed is to follow one diagnostic order: confirm the status, check the page, check the site, check discovery signals, then make one focused change.
Use this workflow:
Inspect the exact URL. Enter the complete public URL in Search Console. Record whether Google says it is indexed, whether it can be accessed, and which canonical Google selected. If the URL is already indexed, investigate search visibility rather than trying to force indexing again.
Run the live test. Use the live test to identify current access problems. Confirm that the page loads for Google without a login, unexpected redirect, server error, or blocked resource. Remember that a successful live test doesn’t establish indexed status.
Check WordPress publishing and visibility. Confirm that the page is published, public, and available at the URL you expect. Open it while logged out. Check whether a password, membership rule, maintenance mode, or scheduled status is preventing public access.
Review page-level indexing settings. Inspect the SEO plugin panel and the page source for
noindex. Review the default settings for the page type if several pages have the same problem. If a recent plugin or theme change coincides with the issue, compare its output—but don’t assume correlation proves the cause.Review robots.txt and canonical signals. Check for a crawl block affecting the page path. Confirm that the canonical points to the preferred URL and compare it with Google’s selected canonical in Search Console.
Check discovery. Confirm that the exact URL appears in the XML sitemap. Add a relevant internal link from a public page. Open the URL and sitemap directly to catch redirects, access restrictions, or formatting problems.
Look for competing URLs. Search for old slugs, alternate hostnames, duplicate page versions, and similar archives. Decide which URL should be primary, then make internal links, canonicals, redirects, and sitemap entries consistent with that decision.
Make one focused change. If you found a noindex directive, remove it. If the URL was missing from the sitemap, correct the sitemap configuration. If the canonical was wrong, fix that signal. Changing several plugins and templates at once makes the next diagnosis harder.
Request a recrawl appropriately. Request indexing for a small number of corrected pages or submit the sitemap for many pages. Then monitor the status rather than repeatedly resubmitting the same URL.
This process answers how to fix WordPress new page not indexed without treating indexing as a single switch. A page needs to be public, crawlable, discoverable, and presented as the preferred version. Even after those conditions are met, indexing is a separate Google decision, so use URL Inspection and the sitemap reports to track the actual state instead of relying only on a site search.
Last content update: September 19, 2026.