9 Indexing Problems Hurting Your Site’s Visibility (And the Fix for Each)

When a page stops showing up in Google, the reflex is always the same. Resubmit the sitemap, open URL Inspection, click Request Indexing, and wait. That move fixes exactly one category of indexing problems, and it does nothing for the category where most of your lost traffic actually lives.

The pages Google can’t reach are a different problem from the pages Google reached and decided not to keep. Both show up as “not indexed” in Search Console. They need opposite fixes. Resubmit-and-wait only ever helps the first kind, so most people spend a week clicking Request Indexing on pages Google already looked at and passed on.

Think of your site as a library. Some books never make it off the loading dock, blocked, mistagged, unreachable. Others get carried inside, flipped through, and set on the returns cart because nobody decided they were worth a shelf. This article walks through eight indexing problems in both families, how to tell which one you have, and the exact fix for each.

Every "not indexed" page falls into one of two buckets, and the fix only works if you match it to the right one.

Match the fix to the actual problem, and the rest of your indexing headaches sort themselves out.

Before you touch a single setting, figure out which family you're dealing with. Every indexing problem falls into one of two:

The reflex fixes (resubmit, request indexing) only nudge the crawl-access family. For quality problems, requesting indexing is like resubmitting a rejected manuscript unchanged. It comes back rejected.

You've got two diagnostic tools in Search Console, and they answer different questions. Here's how they split the work:

The report gives you the pattern, and inspection gives you the ground truth. When the two disagree, trust the live inspection.

Search Console diagnoses, it does not auto-fix. It will point at the problem and validate your fix once you've shipped it, but you still have to ship the fix. That's the whole reason the crawl-vs-quality split matters before you do anything. It tells you what kind of fix to build. Get that wrong, and you'll spend a week applying the wrong fixes while your most important pages stay completely invisible in search results.

How common is "not indexed," really? A 2025 study of 16 million pages by IndexCheckr found only about 37% indexed, with roughly 62% sitting outside the index. That dataset skews toward pages people were already monitoring with an indexing tool, so treat it as directional rather than a clean sample of the whole web. The direction is still the point: indexing is not guaranteed, and a page not being indexed is common enough that you need to diagnose the reason, not panic.

Your robots.txt file tells crawlers where they can and can’t go. One overly broad Disallow rule, often left over from a staging environment or copied from a template, can wall off a whole section of your site. This is a crawl-access problem, the cleanest kind to fix.

The fix is a direct audit. Open yourdomain.com/robots.txt, read every Disallow line, and confirm none of them cover URLs you want indexed. Test specific pages in Search Console’s robots.txt behavior via URL Inspection, which flags a live block. Never disallow your CSS and JavaScript files either. Google needs to render the page to judge it, and blocking those resources hides the real page from the crawler.

Robots.txt blocks crawling, not indexing. Google is explicit that it is not a mechanism for keeping a page out of search. A disallowed URL can still appear in results if it’s linked from other places, usually with no description, because Google was never allowed to read it.

So if your goal is to keep a page out of the index, robots.txt is the wrong tool. You want a noindex directive on a crawlable page, or password protection. Blocking crawl and expecting deindexing is one of the most common mistakes we untangle on technical audits, and it’s an easy one to make. Robots.txt feels like a lock, but it’s really a “please don’t come in” sign that Google can still index around.

A noindex directive is the reliable way to keep a page out of Google. Which is exactly why an accidental one is so damaging; it works perfectly on pages you never meant to hide.

These slip in through CMS settings and plugins. A “Discourage search engines” checkbox was left on after launch. An SEO plugin applies noindex to a whole post type. A theme template hard-codes the tag into the page head. It can also live in the HTTP response as an X-Robots-Tag header, which never shows in the page source; so plenty of people stare at clean HTML while a server header quietly deindexes the URL.

The fix: find and remove the directive from any page you want indexed. Check the page source for <meta name="robots" content="noindex">, check response headers for X-Robots-Tag, and audit your CMS and plugin templates by page type. Search Console’s URL Inspection will confirm a noindex block under “Excluded by ‘noindex’ tag.”

A noindex tag and a robots.txt block cancel each other out. If the page is disallowed in robots.txt, Googlebot never crawls it, so it never sees the noindex, and the URL can linger in the index anyway. For a noindex to work, the page has to stay crawlable. Let Google in, let it read the tag, then it drops the page.

This is the status that sends people in circles, and it’s the one worth understanding better than any other. “Crawled - currently not indexed” means Google reached the page, read it, and chose not to index it. There’s no broken tag to fix. Requesting indexing usually does nothing because nothing was blocking it in the first place.

Most of the time, this label is a value judgment. Google decided the page wasn't worth an index slot. The usual culprits are thin or near-duplicate content, a page that says little a hundred other pages don't already say (the predictable cost of chasing publishing volume over quality), or a page floating with almost no internal support telling Google it matters. This is a content quality problem, not a crawl problem, and it’s where the reflex fix fails hardest.

So fix the actual cause. Two levers, and they work together:

This is the biggest silent indexing killer, and almost no troubleshooting guide treats it as one. Most file Crawled - currently not indexed under just wait, which is a piece of advice that costs you a month and changes nothing. What it actually signals is that your pages read as a pile of loosely related URLs rather than a connected body of work on a subject. Our guide to topical authority, pillar pages, and content clusters covers the structure that fixes that at the root.

When several URLs serve the same or near-identical content, Google picks one to index and consolidates the rest. That’s canonicalization working as intended. The problem starts when Google’s pick disagrees with yours, or when it can’t tell which version is the original and treats them all as competing duplicates.

The variants pile up quietly. http and https, www and non-www, URLs with tracking parameters, faceted filter combinations, session IDs, trailing-slash mismatches. Each is a separate URL to Google, and each dilutes the signal that should be concentrated on one page.

The fix is consolidation:

A canonical tag is a hint, not a directive. Google reads it as a strong suggestion and usually honors it, but if your other signals, internal links, sitemaps, redirects, contradict the canonical, Google may pick a different URL as canonical anyway. So don’t rely on the tag alone. Line your signals up behind the version you actually want indexed.

In practice, that means checking what Google actually chose. URL Inspection reports the “Google-selected canonical” for any page, and when it differs from your declared canonical, that’s your signal to hunt down the contradiction, usually an internal link pointing at the wrong variant, or a sitemap listing the version you meant to drop. Fix the signal, not just the tag.

Status codes are how your server tells Google what a URL is. When they lie, search engine indexing breaks in ways the Page Indexing report flags directly.

A soft 404 is the sneaky one. The page returns a 200 OK (the “this is fine, index me” signal) but has no real content, an empty category, a “no results found” page, and a near-blank template. Google sees a healthy status on an empty page, gets confused, and often declines to index it. The fix depends on intent: if the page should be gone, return a true 404 or 410; if it should exist, add real content; if its value has moved elsewhere, 301-redirect it to the relevant page.

Then the honest error codes:

A burst of 404s after a migration is normal and self-corrects as Google recrawls. It’s persistent soft 404s and lingering 5xx errors that do real indexing damage, not a temporary spike.

Googlebot crawls your HTML first, then queues the page for rendering to execute JavaScript. Rendering happens, but on Google's schedule and within Google's resource limits, and it doesn't always finish. If your actual content — the copy, the product details, the internal links — only appears after a client-side render, you're betting your indexing on a second pass that may come late, may come partial, or may not come at all.

This is a crawl-access problem wearing a quality problem's clothes. The page loads perfectly in your browser. It returns a clean 200. Nothing is blocked. And Google may still see an empty shell with a loading spinner where your content should be. Sites built on client-side frameworks routinely discover that half their pages were indexed on the strength of a nav bar and a footer.

The fix is to stop making Google work for your content:

The nuance worth knowing: Google is genuinely good at rendering JavaScript now, and the "Google can't read JS" line you'll still see repeated is a decade out of date. That's not the issue. The issue is that rendering is a second queue with a cost attached, and Google spends that cost unevenly — readily on sites it already values, grudgingly on sites it doesn't. A large, established brand can get away with client-side rendering. A new site asking Google to render its way to every page is asking for patience it hasn't earned yet. Put the content in the HTML and the question never comes up.

An orphan page has no internal links pointing to it. Google discovers most pages by following links, so a page with no path in is one Google may never find, or may find, shrug at, and not index because nothing on your site signals it matters.

This is the same root cause behind many “Crawled - currently not indexed” cases, which is why internal linking keeps coming up. A clean internal-link graph is one of the most underrated indexing levers there is, and it’s structural, not a one-off tag fix.

The fix is a workflow, not a single action:

To find your orphans, run an internal link audit to map your inbound links and cross-reference the crawl against your full URL list or sitemap. Any page that appears in the sitemap but has zero inbound internal links is an orphan. That gap is usually invisible from inside the CMS, which is why so many orphaned pages go unnoticed for months while they sit outside the index.

Orphan pages are usually a symptom of publishing faster than you’re linking. The structural fix, building out clusters and linking them properly, is the same discipline that builds topical authority, and it pays off well beyond indexing. A well-linked page gets discovered, gets context, and gets a clearer vote of importance from the rest of your site, three things a lone URL never gets.

Your sitemap is a discovery aid, a list handed to Google of URLs you want crawled. It won’t force indexing on its own, but a clean one speeds discovery, and a messy one actively confuses Google about which pages matter.

The common failure is a sitemap stuffed with junk: 404s, redirect chains, noindexed URLs, non-canonical variants, parameter URLs. Every one of those wastes attention and muddies the signal. A sitemap should list only indexable, canonical URLs, the exact pages you want in the index, nothing else.

The fix:

A tidy sitemap won’t rescue a thin page, but it makes sure your good pages get discovered fast, and that Google isn’t spending crawls on URLs you don’t even want indexed.

Crawl budget is how much Googlebot will crawl on your site in a given window, roughly, its crawl capacity limit combined with how much demand your content generates. Waste it on thousands of low-value URLs, and your genuinely important pages get crawled less often, which slows indexing and re-indexing.

Crawl budget mainly matters for large or frequently-updated sites, think tens of thousands of pages or more. If you run a few hundred or a few thousand pages, Google says you generally don’t need to worry about it, and there are almost certainly better places to spend your time. Chasing crawl budget on a small site is a distraction.

For sites that genuinely have the problem, the fix is pruning waste, so crawlers spend their budget on pages that count:

Don’t use noindex to save crawl budget. Google still has to crawl a page to see the noindex, so it spends the budget anyway, then drops the page. To actually save crawl, block it from being crawled in the first place. Use noindex for “keep it out of the index,” robots.txt for “don’t crawl here.” Different jobs.

Here's the part most guides skip entirely, and the reason so much indexing anxiety is misplaced. Not every page needs to be indexed, and chasing 100% indexation is a mistake.

Plenty of URLs should stay out of the index entirely. These pages were never built to compete for a query, so keeping them out isn't a failure; it's the system working as intended. Here's a quick rundown of the usual suspects:

Forcing any of these into the index does more harm than good. Every low-value page you get indexed dilutes the quality signals across your domain and burns crawl budget that belonged to your real pages. Index bloat is a real problem, and the answer to it is fewer indexed pages, not more.

This is why the diagnostic step matters so much. When you open the Page Indexing report and see "not indexed" URLs, the right question isn't "how do I index everything?" It's "Should this page be indexed at all?" A tag page you've noindexed showing up as excluded is Search Console working correctly, not a bug to fix.

Google actively removes low-value pages, too. Indexing Insight tracked a May 2025 purge across roughly two million monitored URLs and found that over a quarter of them were actively removed within weeks, with some sites losing 15-75% of their indexed pages. Alarming if your good content got caught, but for the thin and duplicate URLs that make up a lot of index bloat, a purge is Google cleaning house, and often that's fine. The goal was never maximum indexation. It's about successfully indexing the pages meant for searchers, and keeping the structural or thin pages hidden.

Somewhere along the way, indexing became a thing people believed they could nag Google into. Click the button often enough and the page shows up. It was never true, and in 2026 it's not even close. Google is crawling more than it keeps and is increasingly comfortable saying no. Half the pages sitting in your not-indexed bucket aren't stuck — they were read, weighed, and declined.

That's uncomfortable, because it means most indexing problems aren't technical at all. The robots.txt blocks and stray noindex tags are the easy half; you find them, you fix them, they're done. The hard half is a page that works perfectly and simply isn't worth a slot. No tool flags that. Search Console labels it "Crawled - currently not indexed" and leaves you to draw the conclusion yourself.

So draw it. If a page has been crawled and passed over, Google has told you what it thinks of the page. Requesting indexing again is arguing with a decision that was already made on the merits. The only move that has ever worked is making the page genuinely valuable enough to be indexed, then linking to it well enough that Google can tell you prioritize it.

It varies, but the pattern is fast for pages that Google decides to keep. Onely’s indexing research puts about 56% of indexable URLs indexed within a day and 87% within two weeks. If a page still isn’t indexed after a few weeks, it’s usually a quality or crawl issue to diagnose, not a matter of waiting longer.

No. Robots.txt blocks crawling, not indexing. A disallowed URL can still appear in Google if it’s linked from elsewhere, often with no description because Google couldn’t read it. To reliably keep a page out of the index, use a noindex tag on a crawlable page or password-protect it instead.

Open the URL Inspection tool in Search Console and click Request Indexing. This queues the page for a recrawl but doesn’t guarantee or instantly grant indexing. It only helps crawl-access issues. If the page is “Crawled - currently not indexed,” requesting indexing won’t work; fix the content and internal links first.

Not usually. Plenty of pages, tag pages, filters, thin archives, utility pages, should stay out of the index, and chasing 100% indexation causes index bloat that dilutes your quality signals. Check the reason per URL in the Page Indexing report. If a low-value page is excluded, that’s Search Console working correctly.

At least monthly for most sites, more often after a migration, redesign, or large content push. Review the Page Indexing report for new not-indexed reasons and watch for sudden drops in indexed pages. Set up Search Console email alerts so you’re notified of coverage issues instead of finding them weeks later.