Page Not Indexed by Google? Every Status Explained and Fixed

You publish a page. You wait. You search for it, and nothing. Or worse, a page that used to bring in steady traffic has vanished from the results, and Search Console now lists it under "Why pages aren't indexed" with a status you've never seen before.

Indexing problems feel mysterious because Google's explanations are short and a little cryptic. "Crawled, currently not indexed." "Duplicate, Google chose different canonical than user." "Discovered, currently not indexed." Each of these means something specific, though, and each has a different fix. Once you know which one you're dealing with, most indexing problems become straightforward.

This guide explains every common status, what causes it, and what to do about it, starting with the ones that are fully in your control.

First: check the page, not the whole report#

Search Console's Page indexing report (under Indexing > Pages) groups every URL Google knows about into indexed and not indexed, with a reason for each non-indexed group. It's useful, but it lags and it summarizes. When one specific page matters, go straight to the URL Inspection tool.

Paste the page's URL into the search bar at the top of Search Console. You'll see whether the URL is on Google, when it was last crawled, which canonical URL Google selected, and whether indexing is allowed. Then click "Test live URL" to see what Google sees right now, which matters when you've just fixed something and the stored result is out of date.

Also, one important point before we start: not every non-indexed URL is a problem. A healthy site always has URLs Google correctly leaves out: redirected old URLs, filtered and sorted versions of category pages, pages you deliberately set to noindex, duplicates that point to a canonical version. The goal isn't zero non-indexed pages. It's making sure every page you want in search is indexed.

The statuses you control directly#

These happen because of something on your site, and fixing them is usually quick.

Excluded by "noindex" tag#

What it means: the page tells search engines not to index it, through a robots meta tag in the HTML or an X-Robots-Tag in the HTTP response. Google respects that and leaves the page out.

Common causes: a staging site's "discourage search engines" setting carried over to production, an SEO plugin setting that applies noindex to a whole content type (tags, categories, author pages, sometimes posts by mistake), a template that included noindex during development, or a plugin or theme update that changed a default.

How to fix it: view the page source and search for "noindex". Also check the HTTP headers, since X-Robots-Tag doesn't appear in the page source. On WordPress, check Settings > Reading for "Discourage search engines from indexing this site," and your SEO plugin's settings for the content type. Remove the noindex, then request indexing in URL Inspection.

This is the most dangerous status on the list, because a single setting can remove a whole section of a site from Google, and the page itself looks perfectly normal to visitors. Nobody notices until traffic drops.

Blocked by robots.txt#

What it means: your robots.txt file tells Google not to crawl the URL. Note the difference from noindex: robots.txt blocks crawling, not indexing. A blocked page can still occasionally appear in results without a description if other sites link to it, but Google can't read its content.

Common causes: a "Disallow: /" left over from a staging environment, a rule written for one folder that accidentally matches others, or a migration that changed URL structures without updating robots.txt.

How to fix it: open yoursite.com/robots.txt and read it line by line. Search Console's robots.txt report shows the version Google fetched and any errors. Remove or narrow the rule, then test the URL again.

One trap worth knowing: if you want a page removed from Google, don't block it in robots.txt and add noindex at the same time. If Google can't crawl the page, it can't see the noindex tag.

Page with redirect#

What it means: the URL redirects somewhere else, so Google indexes the destination instead. For old URLs you intentionally redirected, this is correct and needs no action.

When it's a problem: when the page you want indexed is the one redirecting. That usually means a redirect rule is broader than intended, or an internal link, sitemap entry, or canonical tag points at a redirecting URL instead of the final one.

How to fix it: trace the redirect path for the URL. Make sure important pages resolve directly with a 200 status, and update internal links and sitemaps to use final URLs. Long redirect chains and loops cause their own "Redirect error" status, so keep redirects to a single hop.

Not found (404) and Soft 404#

Not found (404) means the URL returns a "not found" response. For pages that were deliberately deleted, that's fine. For pages that should exist, it usually means a broken URL, a deleted page someone didn't mean to delete, or a migration that changed URLs without redirects.

Soft 404 means the page returns a success status, but Google thinks it looks like an error page or an empty page. Thin category pages with no products, search results pages with no results, and pages whose main content failed to load are typical examples.

How to fix them: restore or redirect pages that should exist. For soft 404s, add real content to the page, or return a proper 404 or 410 status if the page truly has nothing useful on it.

Server error (5xx), 401, and 403#

What it means: when Google tried to crawl, your server returned an error, required a login (401), or refused access (403).

Common causes: hosting outages or overloaded servers, security plugins or firewalls blocking Googlebot, pages accidentally placed behind a login, or a CDN rule treating crawlers as bots to block.

How to fix it: check your server and uptime history for the dates of the errors. Make sure your firewall or security tool isn't blocking Google's crawlers. Pages meant to rank must be publicly accessible without login.

The canonical statuses#

These are about duplicate content, and they cause more confusion than any other group.

Alternate page with proper canonical tag#

What it means: this page points to a different URL as its canonical version, and Google agreed. Usually correct, for example when a filtered or tracking-parameter URL points to the main page. No action needed if that's what you intended.

Duplicate without user-selected canonical#

What it means: Google found this page to be a duplicate of another, and the page doesn't declare a canonical, so Google picked one version to index.

How to fix it: add a self-referencing canonical tag to the version you want indexed, and point duplicates to it. If the pages shouldn't be duplicates, make their content meaningfully different.

Duplicate, Google chose different canonical than user#

What it means: your page declares a canonical, but Google decided a different URL is the better canonical and ignored yours. This happens when the signals disagree: your canonical says one thing, but your internal links, sitemap, and redirects point toward another URL.

How to fix it: make all your signals agree. Canonical tag, internal links, sitemap entries, and hreflang should all point at the same URL. Check that the canonical URL you chose returns a 200 status and isn't blocked or noindexed.

Watch for accidental canonical changes too. A theme update, SEO plugin update, or template change that makes a page's canonical point somewhere new can quietly remove that page from results. It's one of the quieter ways rankings disappear.

The two frustrating ones: "Crawled" and "Discovered"#

These two statuses cause the most frustration because there's no single setting to fix. Google isn't blocked. It's choosing.

Discovered, currently not indexed#

What it means: Google knows the URL exists, usually from a sitemap or a link, but hasn't crawled it yet.

Common causes: a large site with many new URLs at once, a site Google doesn't consider important enough to crawl often yet, weak internal linking to the new pages, or a server that responded slowly, so Google backed off.

How to fix it: link to the page from important, already-indexed pages on your site. Keep it in your sitemap. Make sure the server responds quickly. Avoid generating huge numbers of low-value URLs (like endless filter combinations) that use up crawling attention. Then be patient, or request indexing for the pages that matter most.

Crawled, currently not indexed#

What it means: Google visited the page, read it, and decided not to index it, at least for now.

Common causes: almost always about perceived value. The page is thin, very similar to other pages on your site or elsewhere, doesn't add much beyond what's already indexed, or sits on a site that hasn't built much authority on the topic yet.

How to fix it: improve the page rather than repeatedly requesting indexing. Add depth, specifics, and first-hand experience. Consolidate near-duplicate pages into one stronger page. Link to it from relevant pages on your site with descriptive anchor text. Then request indexing once.

A useful reality check: if many of your pages sit in this status, the issue is usually the site's overall content, not a technical bug. Fewer, better pages tend to beat many thin ones.

How to ask Google to index a page#

Once you've fixed the cause:

1. Open URL Inspection in Search Console and paste the URL.
2. Click "Test live URL" to confirm Google can now access the page and indexing is allowed.
3. Click "Request indexing."
4. Make sure the page is in your XML sitemap and linked from other pages on your site.

Requesting indexing doesn't guarantee it, and there's a daily limit, so save it for pages that matter. Pages fixed from a technical block (noindex, robots.txt, errors) often return within days. Pages held back for quality reasons take longer and depend on the improvements you made.

A quick status-to-fix reference#

Why indexing problems go unnoticed for so long#

Here's the uncomfortable part. Most of the controllable statuses above, noindex, robots.txt, canonicals, redirects, status codes, are caused by a change on your own site. A deploy, a plugin update, an SEO setting, a migration. And none of those changes look like anything to a visitor. The page loads. It looks the same. Nothing seems wrong.

Search Console will eventually tell you, but eventually is the problem. Google has to recrawl the page, process it, and update the report, and then someone has to open the report and notice. By then, the page may have been out of the index for a week or two, and its traffic with it.

The fastest way to catch these isn't checking Search Console more often. It's noticing the change on the page itself, the moment it happens.

Where MyKavo fits into this#

MyKavo is our product, so here are the plain facts. On every scan, MyKavo checks each monitored page's HTTP status, robots meta tag, canonical URL, title, meta description, headings, and redirects, and it watches robots.txt and sitemaps too, all compared with a baseline you approved. When a page flips from "index" to "noindex," MyKavo treats it as critical and alerts you right away, with the before and after values side by side, through email, Slack, Discord, or a webhook. Canonical changes, new redirects, and error statuses are flagged the same way, ranked by severity.

That catches the controllable statuses in this guide at the moment they're introduced, rather than after Google has already dropped the page. On WordPress, the free MyKavo plugin also tells you which plugin, theme, or core update caused a change, which covers a large share of accidental noindex and canonical changes.

Connect Search Console and MyKavo adds your clicks, impressions, and positions, with URL inspection built in and drop alerts matched against the changes it detected beforehand. The Site Audit crawls the whole site for indexability problems, like noindex mistakes, redirect chains, broken pages, and duplicate titles, with every issue explained.

Want to check a page right now without signing up? The free Meta Tag Checker grades a page's robots meta, canonical, title, and description, and the Redirect Chain Checker and Bulk URL Status Checker show redirects and status codes.

Honest limits: MyKavo can't make Google index a page. It won't fix "Crawled, currently not indexed," because that's about content quality, and it doesn't see Google's internal decisions. What it does is make sure the causes you control never sit unnoticed.

The bottom line#

Indexing problems come in two kinds. The first, noindex tags, robots.txt blocks, canonicals, redirects, and errors, is caused by something on your site and can be fixed in minutes once you know about it. The second, "Crawled" and "Discovered, currently not indexed," is Google making a judgment, and the fix is better pages and better internal linking.

For the first kind, speed is everything. MyKavo watches the tags and statuses that decide whether your pages can be indexed and alerts you the moment one changes, with the evidence attached. Check a page with the free Meta Tag Checker, or start free and never find out about a noindex tag from a traffic report again.