Google Crawled Your Page but Did Not Index It: What to Check

When Google Search Console reports “Crawled - currently not indexed,” Google says it fetched the URL but did not include it in its search index. The index is the collection of pages Google has processed and may show in search results. The status is common and does not, by itself, identify a problem or explain why Google left the page out.

In Search Console, inspect the exact URL and compare Google’s stored information with a live test of the page. This can help you find verifiable issues, such as an unintended noindex directive or a canonical that points to another URL. Duplicate or low-value content is also worth investigating, but a successful test does not guarantee that Google will index the page.

What “crawled” tells you

Google fetches pages and then decides whether to add them to its index. “Crawled - currently not indexed” means Google reports that it fetched the URL, which remains outside its index. The status does not tell you whether Google displayed the page’s content correctly, chose another URL to represent it, or why it made that choice. Google also says it does not index every page it crawls, so the status does not automatically require action. (Google’s Page indexing report)

This differs from “Discovered - currently not indexed,” which means Google found the URL but has not fetched it. If JavaScript displays the page’s main content, the crawl status alone does not show whether Google’s tools ran that code and displayed the content correctly. Check the displayed page in URL Inspection.

Compare the indexed record with a live test

In Search Console, open URL Inspection and enter the exact URL, including its protocol, hostname, path, and trailing slash. In the indexed information, note the last crawl date and, if shown, the canonical you declared and the one Google selected. A canonical is the URL you want Google to treat as the main version when similar pages exist.

Then choose Test live URL to check the page as it is now. Google’s URL Inspection documentation says the live test checks whether Google can access the URL and checks some technical conditions. Review the page as Google displays it after running its code. Where available, also check the HTML, response headers, loaded resources, and JavaScript messages. Confirm that the main text and purpose are visible.

The indexed record shows what Google stored during an earlier visit. The live test checks the page under current test conditions. A page can pass the live test and still remain outside the index.

Check technical signals and alternate URLs

First confirm that the URL serves the intended page. Google’s technical requirements describe a successful HTTP response as a basic eligibility condition. Check the final destination if the URL redirects, and verify that the destination is the page you expect.

Next, look for indexing directives. Review the page’s robots meta tag and the HTTP X-Robots-Tag header for noindex. Also check robots.txt. These controls work differently. noindex tells Google not to index a page when Google can crawl it and read the directive. A robots.txt block can stop Google from seeing the directive. Google explains how to block indexing with noindex.

Compare the canonical in Search Console with the page’s canonical tag, redirects, sitemap entries, and internal links. Google uses canonical tags as signals, but it can choose a different URL to represent the page. Its canonicalization documentation explains how Google groups similar pages and chooses a canonical.

Look for alternate URLs that serve nearly the same main content. Examples include parameter-based filter pages and print versions. Also look for near-identical product or location pages, and old URLs that still resolve. If Google selects another URL as canonical, decide whether that is the correct page to appear in search. If it is, consolidate signals around that URL. If the inspected URL deserves its own result, make sure its content and technical signals distinguish it clearly.

Check rendering and page value

If the live test does not show the main content, check how the page displays it. A script might need data from an API, a service that provides information to the page, but fail to get that data. A blocked resource or content that appears only after a user action can also keep the content from appearing. Google treats crawling, rendering, and indexing as separate stages for JavaScript pages. Read the JavaScript SEO guidance, then use URL Inspection’s displayed output to see what Google’s test received.

If the page displays correctly and its technical signals agree, compare it with other pages that meet the same reader need. Does it offer distinct information, analysis, experience, or a useful tool? Or does it repeat content already on your site with only minor wording changes? Google’s people-first content guidance provides criteria for this review. The guidance does not show that Google excluded a particular page for quality reasons, so use content value as something to investigate, not as a diagnosis.

For similar pages, compare their shared template and the ways their content differs. Google’s spam policies define scaled content abuse as creating many unoriginal pages mainly to manipulate rankings while offering little value. The policy does not say Google automatically excludes content because someone used AI to help write it. The question is whether the pages offer useful, original value. (Google’s spam policies)

Make a change before requesting indexing

First decide whether the URL should be indexed at all. A duplicate, filter, or alternate page may be better represented by another URL. If you find a verified technical problem, fix that problem and rerun the live test. If the canonical is wrong, align the page’s signals with the URL you want Google to treat as primary. If the page lacks a distinct purpose or useful information, improve the substance rather than adding text for its own sake.

Link to important pages from relevant pages on your site so Google can follow those links. Keep the sitemap accurate, too. Google says a sitemap can help it find URLs, but submitting one does not guarantee that Google will crawl or index them. (Google’s sitemap overview)

After an important change, use URL Inspection to request indexing for that URL. Google limits the number of requests per day, and a request does not guarantee that Google will index the page. Its help documentation says the process may take a week or two. Record the change, then check the indexed information again after Google visits the page. Repeated requests for an unchanged URL do not fix technical or content problems.

What the checks cannot prove

A successful live test shows that Google’s inspection tool accessed the page under the test conditions. It does not guarantee indexing, show which canonical Google will choose, or explain Google’s final decision. A screenshot can reveal missing text or a visible display problem, but it cannot tell you why Google did not index the URL.

A browser or ordinary HTTP request shows whether that browser or requester can access the page. It does not prove that Googlebot fetched it or show what Google received during an earlier crawl. A site: search gives only a rough check, not a full diagnosis. Use URL Inspection to check the specific URL. Keep in mind that the Page indexing report has limits: its example URL lists show samples, and recent changes may take time to appear. (Page indexing report details)

Key Takeaways

• Inspect the exact URL: Compare its indexed information with a live test, including Google’s selected canonical when available.
• Verify the page Google receives: Check rendered content, response status, indexing directives, and relevant resources before changing the page.
• Resolve URL duplication deliberately: Decide which version should represent similar pages, then make canonical, redirect, sitemap, and internal-link signals consistent.
• Improve a real content gap: Give the page a distinct purpose and useful information; the status alone does not prove a quality problem.
• Request indexing after a meaningful fix: A request asks Google to revisit the URL, but it does not guarantee that Google will index it.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com