Why Google Isn't Indexing Your Pages (and How to Fix Each Cause)

You wrote a page, it's live, you can open it in a browser, and Google still won't show it. That's not one problem. It's at least ten different problems that all produce the same symptom: the page doesn't show up in search results.

Search Console's Page indexing report sorts pages into named statuses, and almost everyone skips straight past the names to the fix. That's backwards. The status tells you which of four unrelated categories you're in: Google can't reach the page, Google can reach it but was told not to index it, Google thinks it's a duplicate of something else, or Google crawled it and decided it isn't worth indexing. Each category has a different fix, and two of them (duplicates, low-value content) don't have a technical fix at all.

This goes status by status, in the order you'll actually find them useful, not the order Search Console lists them.

How to read the Page indexing report in the first place

Open Search Console, go to Indexing > Pages. You'll see a chart with "indexed" and "not indexed" counts, and below it a table of reasons with a count of URLs under each one. Click any reason to see the list of URLs, and click any URL to run it through the URL Inspection tool, which tells you the live status, the last crawl date, and whether the page is eligible to be indexed right now.

The report updates on a rolling basis, not in real time. A fix you ship today might not show a changed count for several days to two weeks, longer on a large site. Don't judge a fix by the chart moving; judge it by re-running URL Inspection on a sample of the affected URLs and checking whether the "why" matches what you expected.

Server error (5xx)

Google requested the page and your server returned a 500-level error. This usually means a WordPress plugin conflict, a database timeout, or a server under enough load that it's dropping requests from Googlebot specifically (shared hosting during a crawl spike is a common cause).

Diagnose it in URL Inspection: it'll show the exact response code Google got. Cross-check with your server error logs for the same timestamp. If it's intermittent, check whether it correlates with your crawl rate in Search Console's crawl stats report.

Fix: resolve the underlying server issue, then use URL Inspection to request a recrawl once you've confirmed (by requesting the URL yourself with a tool like curl -A Googlebot) that it now returns 200. Leaving this one alone is never fine. A page serving 5xx errors to Googlebot is also likely serving them to some share of real visitors.

Not found (404)

The page doesn't exist anymore, and the server is correctly saying so. This is usually expected: you deleted a product, merged two blog posts, or restructured URLs. It is not automatically something to fix.

The real question is whether anything of value still links to that dead URL. Check Search Console's Links report for internal and external links pointing at it. If something does, either 301 redirect the old URL to its closest living replacement or update the links. If nothing links to it and it genuinely has no replacement, leave it as a 404. Don't redirect orphaned 404s to your homepage out of habit; a pile of homepage redirects looks like a thin-content pattern and doesn't pass meaningful relevance.

Soft 404

The page returns a normal 200 OK, but Google's systems decided the content looks like a "not found" page anyway: an empty category, a product marked out of stock with no replacement, a search results page with zero results, or a thin page that's mostly boilerplate.

Diagnose by actually looking at the page the way a crawler would (view the rendered HTML, not just what you see with CSS applied). Ask whether there's a reasonable amount of unique content on it.

Fix depends on intent. If the content really is gone, return an actual 404 or 410 instead of a fake-200 empty page. If the page should exist and has real content, add enough substantive text and the correct HTTP status so it stops pattern-matching to "empty." Out-of-stock product pages are the classic case: show related products, show when it'll be back, don't leave a bare page with a sold-out label and nothing else.

Blocked by robots.txt

Googlebot requested /robots.txt, found a Disallow rule matching the URL, and didn't crawl it. Google can still index the URL from external signals (anchor text, links) without ever seeing the content, which is why you sometimes see a URL ranking with no title or description, just the bare URL. That's the separate "Indexed, though blocked by robots.txt" warning status, worth knowing exists if you see a blocked URL still showing up in results.

Diagnose with the robots.txt Tester in Search Console, or just open /robots.txt and check the Disallow rules against the path. Fix: remove or narrow the Disallow rule if you want the page indexed. Leave it blocked if you're intentionally keeping Google out of admin paths, internal search results, filtered/faceted URL parameters, or staging content, which is the correct use of robots.txt.

Excluded by 'noindex' tag

Either a <meta name="robots" content="noindex"> tag in the page head, or an X-Robots-Tag: noindex HTTP header, told Google not to index the page after it crawled it. This is different from robots.txt: noindex requires Google to crawl the page first, which costs crawl budget, so if a page should never be indexed and never needs crawling either, robots.txt is the more efficient tool.

Diagnose: view page source and search for noindex, or check response headers with a browser devtools network tab. SEO plugins (Yoast, Rank Math) sometimes set this per-post, per-category, or sitewide for certain post types, and a sitewide default can accidentally catch new content.

Fix: remove the tag if the page should be indexed. Leave it on intentionally for thank-you pages, internal search result pages, duplicate filtered views, and thin tag/author archives that exist for site structure but add no search value.

Discovered - currently not indexed

Google knows the URL exists (usually from a sitemap or a link) but hasn't crawled it yet. This is almost always a crawl-priority problem, not a content problem: Google is choosing to spend its limited attention on your other pages first.

Diagnose by checking how the URL was discovered (sitemap vs. link, shown in URL Inspection) and how deep it sits in your site's internal linking. A URL with zero internal links pointing to it, buried five clicks from the homepage, sits at the bottom of the crawl priority list regardless of how good the content is.

Fix: link to the page from somewhere with actual crawl equity, submit it in your sitemap with an accurate lastmod, and if you have a large number of these, read the crawl budget section below, because volume of "Discovered" URLs is one of the signals Google names directly as a sign crawl budget is a real constraint for your site. It's fine to leave a handful of low-priority pages in this state if they genuinely don't matter for search traffic.

Crawled - currently not indexed

Google crawled the page, read it, and decided not to add it to the index. This is the status that means "Google saw it and passed," and it's the one most often mistaken for a bug when it's actually a quality judgment.

Diagnose honestly: is this page meaningfully different from your other pages, or is it a thin variant (a city-name template page, a tag archive, a near-duplicate of a better page you already have)? Check how much unique, substantive content sits above the fold and in the main body versus boilerplate.

Fix: either make the page clearly better and more unique, or consolidate it into a stronger page with a redirect, or accept it. Requesting indexing repeatedly on a page Google already evaluated and declined doesn't change the evaluation. It's genuinely fine to leave low-value pages in this state; not every URL on a large site needs to rank, and forcing indexing of thin pages can drag down how Google evaluates the rest of the site.

Duplicate without user-selected canonical

Google found multiple URLs with the same or near-identical content and you never told it which one is the "real" one with a canonical tag, so it picked one on its own (or none at all) and the others sit excluded.

Common causes: URL parameters that don't change content (tracking params, sort order, session IDs), HTTP vs. HTTPS or www vs. non-www duplicates, printer-friendly versions, paginated pages without proper canonical handling.

Diagnose by comparing the content of the excluded URL against the version Search Console lists as the "Google-selected canonical" in URL Inspection.

Fix: add a self-referencing canonical tag on the version you want indexed, and point canonical tags on the duplicates at that URL. Handle parameter duplication at the URL structure level where possible rather than leaving it to canonicalization alone.

Alternate page with proper canonical tag

This one is not a problem. It means you correctly set a canonical tag pointing this URL at another page, and Google respected it and is indexing the other page instead. This is the system working as designed for mobile/desktop pairs, print versions, and tracked-parameter URLs. Leave it alone.

Page with redirect

The URL redirects somewhere else, so Google indexes the destination instead of this URL, which is expected and correct for 301s on old content. The only thing to check is whether the redirect goes to a genuinely relevant destination and isn't a long chain. Multiple hops waste crawl budget and occasionally break the signal entirely; keep redirects to a single hop where you control the source.

Quality-related non-indexing: thin and duplicate content

A chunk of "Crawled - currently not indexed" and "Discovered - currently not indexed" isn't a crawling problem at all, it's Google's helpful content guidance working as intended. Google's own self-assessment questions ask whether content offers original information, whether it's comprehensive rather than derivative, and whether it would be considered trustworthy enough that someone would want to cite or recommend it. Programmatic pages built from a template with the city or product name swapped out, pages that summarize another source without adding anything, and pages produced mainly to target a keyword rather than serve a reader are the pattern Google explicitly calls out as search-engine-first content.

There's no technical switch for this. The fix is rewriting or consolidating. If you've got a template generating five hundred near-identical location pages, decide honestly which ones have enough unique local detail to stand on their own, and merge or remove the rest. For deeper diagnostics on template and thin-page patterns, see our full technical SEO checklist.

It's also worth knowing that a page Google won't index for being thin isn't going to get cited by an AI answer engine either; the quality bar for both systems overlaps more than it diverges. If visibility in AI answers is the actual goal rather than just a clean indexing report, getting cited by ChatGPT and Google AI Overviews covers what comes after indexing is fixed.

Crawl budget: when this matters, and when it doesn't

Google is explicit that crawl budget management is not a concern for most sites. Their guidance names the sites it applies to: large sites north of roughly a million pages that change moderately often, medium-to-large sites of 10,000+ pages that update daily, or any site (regardless of size) showing a lot of URLs with the "Discovered - currently not indexed" status, because that's a direct signal Google isn't getting through everything it knows about.

If that's not you, don't spend time on log file analysis or server capacity tuning for crawl budget; put the time into content and internal linking instead. If it is you, the levers Google names are: reduce duplicate URLs (parameter handling, faceted navigation), fix soft 404s so Google stops re-crawling dead weight, keep server response times fast since "crawl capacity limit" is explicitly about how much load your server can handle without degrading, and avoid long redirect chains. Log file analysis (checking your raw server logs for Googlebot's actual request patterns) is the way to see what's really being crawled versus what you assume is being crawled, and it's worth doing once you're in the size range where this guidance applies.

Requesting indexing the right way

The URL Inspection tool has a "Request indexing" button. Use it for a single URL after you've fixed the underlying issue (a noindex removed, a server error resolved, a redirect corrected), not as a first response to a "not indexed" status you haven't diagnosed. Google's own guidance notes there's a daily cap on how many requests you can submit, that indexing "typically takes a day or so" but can take longer, and that submitting a request doesn't guarantee indexing. For anything beyond a handful of URLs, submit or update your XML sitemap with accurate lastmod dates instead of requesting each one by hand.

Summary table

FAQ

Why does Search Console show a different "not indexed" count than what I see with a site: search?

The site: operator reflects a loose, outdated sample of the index and isn't a reliable count for anything. Search Console's Page indexing report is the only count worth trusting, and even that lags live reality by some days.

Does marking a page noindex hurt the rest of my site?

No. Noindex is scoped to that URL. It can indirectly help if it removes thin or duplicate pages from competing with your stronger content for the same query, which is part of why Google names large volumes of thin pages as a negative quality signal in aggregate.

I fixed the cause, why does the status still show "not indexed" a week later?

Recrawling and reprocessing isn't instant, and the Page indexing report itself updates on a delay. Use URL Inspection on a sample of fixed URLs to check the live status rather than waiting on the aggregate chart, and request indexing on a few of them once you've confirmed the fix is live.

Should I disavow or remove links to a 404 page instead of redirecting it?

Different problem entirely; that's about link quality, not indexing status. See our guide to disavowing links if that's what you're actually trying to solve.

Is "Discovered - currently not indexed" the same as a crawl budget problem?

Not necessarily for one or two URLs; that's often just low internal link priority. It becomes a crawl budget signal when it shows up across a large share of your URLs on a big site, which is one of the specific triggers Google names in its crawl budget documentation.

More technical SEO breakdowns like this one live in our guides section.