Page Not Indexed? How to Find the Exact Cause, Step by Step

You published a page, waited, and it still doesn't appear in Google. Search Console says URL is not on Google or gives a reason such as Crawled - currently not indexed, and the label alone rarely tells you what to change.

Almost every indexing problem comes down to a short list of signals: the HTTP status code, redirects, robots.txt, noindex rules, the canonical Google chooses, duplication and quality, and whether Google has found the URL at all. Checked in the right order, they lead to the cause quickly.

This guide walks through that order. You will learn what each status in Search Console's Page indexing report means, how to tell a technical block from a decision Google made, how to fix each cause and how to confirm the fix.

How indexing works, and where it can stop

Google describes Search in three stages: crawling, indexing and serving results (How Google Search works). Before any of that, Google has to discover the URL, usually through a link from a page it already knows or through a sitemap. During the crawl it also renders the page and runs its JavaScript in a recent version of Chrome.

1. DiscoveryLinks from known pages, sitemaps
2. Crawlingrobots.txt, server errors, HTTP status
3. RenderingJavaScript run in a recent Chrome
4. Indexingnoindex, duplicates and canonical choice, quality
5. ServingRelevance to each query; indexed is not the same as ranked

A page can stall at any stage. Google is also explicit that indexing isn't guaranteed, and lists low content quality, robots meta rules that disallow indexing and a site design that makes indexing difficult as common issues. So the plan is simple: first rule out the blocks you control, then work on the decisions Google makes.

Step zero: ask Google about the exact URL

The Page indexing report summarizes every URL Google knows in your property, but Google says it isn't meant for investigating a specific page. For that, paste the full URL into the URL Inspection tool at the top of Search Console.

The verdict reads URL is on Google or URL is not on Google. Expand Page indexing; these fields map directly onto the checks in this guide:

Sitemaps, Referring page

How Google discovered the URL. URL is unknown to Google means it has never seen it.

Last crawl, Crawled as

When Google last fetched the page and with which crawler (mobile or desktop).

Crawl allowed?

Whether a robots.txt rule blocks the URL.

Page fetch

Whether your server actually delivered the page.

Indexing allowed?

Whether a noindex rule was found.

User-declared canonical, Google-selected canonical

The URL you named as canonical and the one Google chose.

For sites with fewer than 500 pages, Google suggests a quick site: search for the exact URL, such as site:https://www.example.com/pricing. Either way, "URL is on Google" means the page is eligible to appear, not that it will show for any particular search.

What each Page indexing status means

These are the exact status names from Google's documentation, what they mean and where to start. The report's Source column says whether an issue comes from your Website or from Google; as a rule, you can fix only the ones marked Website.

The order of checks that finds the cause

Each signal depends on the ones before it. If robots.txt blocks a URL, Google never sees its noindex tag. If the URL redirects, you are inspecting the wrong page. A canonical only matters once the page can be crawled and indexed. Working top-down stops you fixing a symptom while the real block stays.

1. Status code. The page must answer 200. Google doesn't index URLs that return 4xx codes, and drops URLs that keep returning server errors (How HTTP status codes affect Google's crawlers). Watch for login walls, bot protection that blocks Googlebot, and error pages that return 200.

2. Redirects. If the URL redirects, Google reports it as Page with redirect and indexes the target, if anything. Inspect the final URL and point internal links and sitemap entries straight at it.

3. robots.txt. If Crawl allowed? says No, find the matching rule. Search Console's robots.txt report shows the robots.txt files Google fetched, when, and any parsing errors.

4. noindex. If Indexing allowed? says No, look for a robots or googlebot meta tag in the <head> and an X-Robots-Tag response header. CMS settings, SEO plugins and server configuration are the usual sources.

5. Canonical. Compare User-declared canonical with Google-selected canonical. If Google chose another URL, it treats your page as a duplicate and shows that URL instead.

6. Content and duplication. If everything technical is clean and the status is Crawled - currently not indexed, ask whether the page adds something your site, and the web, doesn't already offer.

7. Discovery. If the URL is unknown or Discovered - currently not indexed, give Google a route to it: links from pages it already crawls, a sitemap entry and a fast, stable server.

robots.txt or noindex? Don't mix them up

Google's introduction to robots.txt says the file mainly manages crawler traffic and "is not a mechanism for keeping a web page out of Google". A disallowed URL can still be indexed from links, without a description; that is what the Indexed, though blocked by robots.txt warning reports.

noindex works the other way round. Google's noindex documentation is direct: if robots.txt blocks the page or the crawler can't access it, Google never sees the rule, and the page can still appear in results.

The two places a noindex rule can hide look like this. Both have the same effect for Google:

<meta name="robots" content="noindex">
<!-- or only for Google's crawlers -->
<meta name="googlebot" content="noindex">

HTTP/1.1 200 OK
Content-Type: application/pdf
X-Robots-Tag: noindex

A header rule never appears in the page source, so it is easy to miss. Google's robots meta tag specification shows how it is set in server configuration; if a whole file type vanishes from Google, search your configuration for lines like these:

# Apache: every PDF gets noindex, nofollow
<Files ~ "\.pdf$">
  Header set X-Robots-Tag "noindex, nofollow"
</Files>

# NGINX: the same rule
location ~* \.pdf$ {
  add_header X-Robots-Tag "noindex, nofollow";
}

When nothing is blocking the page

If the page returns 200, doesn't redirect, allows crawling and indexing and names itself as canonical, you are no longer looking at a technical block but at a decision Google made. The right response depends on the status.

Crawled - currently not indexed

Google fetched the page and chose not to index it for now. Its documentation says the page "may or may not be indexed in the future" and that there's no need to resubmit it. The URL Inspection help adds that a page must be high enough in quality to warrant indexing and must not duplicate another indexed page. So ask an editorial question: is this a thin variation of something else on the site, such as a tag archive repeating the same posts, a location page that only swaps the city name, or a product page built on a copied manufacturer description? If so, merge it into a stronger page, or give it content and a purpose nothing else on the site covers, and link to it from relevant pages.

Discovered - currently not indexed

Google knows the URL but hasn't crawled it yet. Its documentation says that typically Google wanted to crawl the URL, expected that doing so would overload the site, and rescheduled; that is why the last crawl date is empty. Check that your server responds quickly and without errors, and that the page is linked from pages Google crawls often, not only listed in a sitemap.

The duplicate statuses

Here the page isn't missing: Google indexed another URL in its place. Inspect the Google-selected canonical. If it really is the same content, accept it and link to it consistently. If it isn't, Google's advice is to make sure the content differs substantially, and your canonical tag, redirects, sitemap and internal links should all name the same preferred URL.

Fix, request indexing and confirm

After a change, confirm it before you wait. The live test shows at once whether the block is gone; the indexed status follows later.

• Run Test live URL and confirm Page fetch is Successful, Crawl allowed? is Yes and Indexing allowed? is Yes.
• Open View tested page and check the screenshot and HTML: the main content Google receives should be there.
• Click Request indexing once. Google says indexing typically takes a day or so but can take much longer, and that you can't request indexing for a URL the live test considers non-indexable.
• For many fixed URLs, submit or resubmit a sitemap with accurate <lastmod> values instead of requesting each URL; there is a daily request limit.
• If the URLs appear under one reason in the Page indexing report, click Validate fix. Google says validation typically takes up to about two weeks and emails you when it passes or fails.
• Re-inspect the URL after the next crawl date and compare it with the live test.

Google is candid about timing: crawling can take from a few days to a few weeks, and not every page will be indexed. If the live test is clean and the status is still a "currently not indexed" decision, the remaining work is on the page and its links.

Check any URL with the Indexability Checker

Search Console only covers sites you have verified, and the live test shows one URL at a time. Backlnk's free Indexability Checker runs the technical part of this guide for one URL or a list of up to 50 URLs on the same website:

• It checks the HTTP status and redirects, robots.txt, meta robots, X-Robots-Tag, the canonical and whether the URL is in the site's sitemap.
• Each URL gets one verdict (indexable, not indexable or needs attention) naming the signal that decided it, with the evidence in a signal table.
• Under Options you can render the page in a browser, which matters when robots or canonical tags are added by JavaScript.
• Every verdict can be exported as CSV, handy for checking a batch of URLs after a release.

"Indexable" means nothing on the page or server blocks indexing; it doesn't mean Google has indexed the page or will rank it. Google's decision is only visible in Search Console, so use both: the checker finds technical blocks fast, URL Inspection tells you what Google did. For a whole site, the free full audit combines Backlnk's checks in one report sent by e-mail.

Next step

Take your most important unindexed URL, inspect it in Search Console and run it through the Indexability Checker. Work down the order (status, redirects, robots.txt, noindex, canonical, content, discovery) and stop at the first signal that fails. Fix it, confirm with a live test, request indexing once and give Google time to recrawl.