Crawled currently not indexed? Start with these checks

First, decide whether you want this URL in search. Your main service page probably belongs there. A shopping basket or a filter URL that repeats another product listing may not. Fixing the latter just to increase your indexed-page count can send you in the wrong direction.

Google’s Page indexing report says the status can change and there is no need to resubmit an unchanged URL.

The label does not tell you what caused the exclusion. If someone recommends a rewrite immediately, put the page and its inspection result in front of them first. What, exactly, needs fixing?

Which indexing status are you actually seeing?

Read the full status label first. A URL Google has discovered needs a different investigation from one it has already fetched.

Use the label shown for your exact URL. Similar-looking labels can point to very different next steps.

Why does the live test pass while the page stays unindexed?

The live test checks what Google can fetch now. The indexed result describes the version recorded in Google’s systems. Start with that recorded result.

Copy the exact URL into Google Search Console. Record the indexed result before running a live test. Then note the last crawl date and the Google-selected canonical where it is available. Save both screenshots.

A passing live test is useful: it rules out some current access problems. But it does not run all the checks Google uses to select pages for its index, including duplicate and canonical evaluation. That is why the green result and the indexing exclusion can both be correct.

Check the dates. If Google last crawled the URL before your rewrite, the inspection may still describe the older page.

Google explains these limitations in its URL Inspection documentation. For a single URL, read its inspection details alongside the broader report. Their dates and scope differ.

Is Google choosing another URL as the canonical?

When several URLs contain similar material, Google may choose one to represent them in search. Confirm which one you intended to keep.

Look at the HTML canonical, redirects and internal links together. If a product exists at both a clean address and a tracking-parameter address, link to the version you want indexed. Keep that choice consistent in your sitemap.

Compare the Google-selected canonical with the address you want visitors to find. If they differ, inspect both pages before changing the annotation.

For example, if a tracking URL repeats the clean product page, make your canonical, internal links and sitemap agree on the clean address. If the two pages serve different needs, compare their content before treating them as duplicates.

Do not replace every canonical with the homepage URL. That can confuse the relationship between unrelated pages. Google’s canonical documentation covers redirects, HTML annotations, sitemaps and inconsistent signals.

What should you check on a WordPress page?

Check the page while logged out. Your administrator view can hide a problem that visitors and crawlers still encounter.

Open the published URL in a private browser window. Does it show the full article? Then check the document response, canonical and robots directives. A correct setting in your SEO plugin helps only if the public page delivers it.

• Confirm the production site is not carrying a staging noindex directive.
• Check the SEO plugin’s setting for this post and its content type.
• Inspect the visible content after your page cache and CDN refresh.
• Check that a security plugin is not returning a challenge or empty response.
• Follow the published navigation and content links to the page.
• Verify the primary copy is available in rendered HTML.

A saved change does not always reach the public page immediately. If your editor shows the new version while an anonymous visitor sees the old one, inspect the page cache and CDN response. Another rewrite will leave that delivery problem unresolved.

For JavaScript-heavy pages, inspect the rendered version as well as the initial response. A working interface can conceal missing text from a crawler. Google’s JavaScript SEO guide explains how crawling, rendering and indexing fit together.

Does this page answer anything your other pages miss?

Put this page beside the other article on your site that answers the same question. Can you explain why a visitor needs both?

A city-name swap rarely answers that question. Neither does another 500 words of background. Look for the missing detail: a local constraint, a worked example or the step someone keeps getting wrong.

Add something the reader can use: an observed error, a worked example, a dated source or a decision the existing explanation leaves unresolved. Extra length alone supplies none of those.

Suppose two guides explain exactly how to submit a sitemap. Keep the stronger guide, merge any useful missing details and plan an appropriate redirect if you retire the redundant URL. If they solve separate problems, make the distinction visible in the title, opening answer and internal links.

Keep useful old material. Before consolidating anything, export the content and check its existing traffic, links and business role.

What evidence should you record before choosing a fix?

Write down the observation before deciding what it means. “Google last crawled the old version” is evidence. “The new page is too short” is a guess until you investigate.

Start with the URLs that matter to your business. The hypothetical worksheet below shows how one observation can lead to a specific check. It is not a client recovery report.

Keep one row per URL. Record the crawl date, canonical, response status and robots directives, then add what you changed and when. When Google crawls again, you can compare the new result with that record instead of trying to remember what was live last week.

How do you save a useful record of the problem?

Save the document response before changing a setting. A screenshot of the status alone leaves your developer with very little to investigate.

In your browser’s developer tools, open Network and reload the page. Select the main document request rather than an image or stylesheet. Save its final URL, status and response time, along with the date and timezone of your check. Remove cookies and authorization headers before sharing an export.

If present, save the Cache-Control, Age, Content-Type and X-Robots-Tag headers. They can help your developer investigate caching or an indexing directive. To check whether an update reached the public page, compare its canonical and opening paragraph with the copy saved in WordPress.

If your developers use command-line checks, ask them to preserve the redirect chain, HTTP status and response body as separate artifacts. A header-only request cannot tell you whether the article renders correctly. Keep credentials out of screenshots, shared HAR exports and public issue reports.

Link the saved response to the URL’s worksheet row. If a firewall challenge disappears before your developer opens the page, that capture may be the only record of what you saw.

What did our own website check establish?

Our breadcrumb update exposed a useful limit of public website checks: a working page tells you little about whether Google has selected it for search.

On 4 October 2026, Digital Magma checked 145 sitemap-linked URLs, including the homepage, during its breadcrumb update. All returned HTTP 200, and every non-home URL contained BreadcrumbList markup. This was a public HTTP audit, not a fresh Search Console indexing export.

So we could confirm the responses and markup. We could not use that result to claim 145 indexed pages. That would require current Search Console evidence.

When should you request another crawl?

Request a crawl after publishing a new page or making a meaningful correction. The request tells Google there is something to fetch, without deciding whether it belongs in the index.

Once the page is accessible and the change is worth recrawling, use URL Inspection for an individual address. Use an updated sitemap to communicate a collection of new or revised URLs. Keep modification dates truthful.

Keep a dated record of the change. Google’s recrawl guidance says crawling can take days to weeks and repeated requests do not speed it up. There is no acceptance deadline.

When the next crawl appears, compare its date with your update. If it happened earlier, give Google time to fetch the revised page before judging the result.

Can an unindexed page appear as a Google AI search link?

Indexing is required for a page to qualify as a supporting link in Google’s AI Overviews or AI Mode.

Google’s AI search guidance says the page must also be eligible for a search snippet. No extra technical requirement applies solely to those answers. Eligibility does not promise a citation.

For your article, explain the answer clearly and link to the evidence. Use BlogPosting, Person and Organization markup to describe the actual article, author and publisher. Adding those types cannot make an excluded URL eligible by itself.

Other engines have independent retrieval systems. Google’s indexing status cannot certify visibility in ChatGPT, Perplexity or Bing Copilot. Check crawler access and actual cited answers separately when measuring those platforms.

Crawled currently not indexed: common questions

These answers address the decisions that usually come up after the first inspection.

Sources, author and how this guide was prepared

This guide uses Google’s documentation and the dated public-site check described above.

Research also reviewed public Reddit questions about conflicting reports and ecommerce parameters. Community explanations were treated as questions to verify, not technical authority. English, Russian and Chinese versions of Google’s recrawl guidance were cross-checked. No third-party article was translated into this post.

AI tools assisted the research and drafting. The technical references are linked above, the worksheet is hypothetical, and our site observation covers only the public checks described in that section. Found an error? Send it through our contact page.