A page fails to show up on Google for one of four reasons: a noindex tag or robots.txt rule is blocking it, the site is too new for Google to have crawled it, the content is too thin or too similar to another page to earn its own listing, or a technical error is stopping Google's crawler from reading it. Indexing and ranking are two different problems, and confusing them wastes time on the wrong fix, since a page has to be indexed before it can rank anywhere. Google Search works in three stages: crawling, indexing, and serving results, and a page can fail at any one of them for a different reason. The fastest way to find out which stage is failing is the free URL Inspection tool in Google Search Console, which shows the exact status Google has recorded for that page.
Indexing vs ranking: the difference that changes your fix
These are separate systems, and they fail differently. Google's own "How Search Works" documentation lays out the sequence plainly: Google crawls pages with automated programs, indexes what it finds by analyzing the text and key tags, then serves relevant results when someone searches. A page that hasn't cleared stage one (crawling) or stage two (indexing) is invisible to stage three (ranking), no matter how good the content is.
The quickest diagnostic is a site: search, typing site:yourdomain.com/your-page-url into Google. If nothing comes back, the page is probably not indexed, though a site: search is a filtered, non-exhaustive sample rather than a guaranteed check, so confirm with URL Inspection before ruling out ranking work. If the page appears but far down the results, it is indexed and the problem is genuinely a ranking one, content depth, backlinks, or competition, not indexing. That single check saves hours spent tweaking a page that was never in the index to begin with.
Reason 1: A noindex tag or robots.txt rule is blocking the page
A
noindextag, set as a meta tag or anX-Robots-TagHTTP header, tells Google directly not to show a page in search results, even if the page is fully crawlable. A robots.txtDisallowrule is different: it blocks crawling, not indexing outright, so a disallowed page can still appear in results (usually with no description) if other pages link to it.
Both mechanisms are common causes of a "missing" page, and both are usually left over from development rather than intentional. According to Google Search Central's documentation on blocking indexing, the noindex rule can be set two ways: a <meta name="robots" content="noindex"> tag in the page's <head>, or an X-Robots-Tag: noindex HTTP response header for non-HTML files like PDFs. Either one is a direct, explicit instruction, and Google honors it.
Robots.txt works one level earlier, at the crawling stage. Google's robots.txt documentation shows the syntax: a Disallow: /path/ rule under a User-agent group tells compliant crawlers not to fetch that path. A page blocked this way is often still known to Google through external links, so it is possible to see a bare URL in search results with no title or snippet, because Google never got permission to read the content. New sites built on WordPress, Wix, or Squarespace frequently ship with a "discourage search engines" setting enabled by default during staging and never switched off at launch, which silently applies a sitewide noindex.
Fix: check the page's source for a noindex tag, check yourdomain.com/robots.txt for a blanket Disallow: / rule, and check the CMS's own search-visibility toggle. All three live in different places and all three block the site for the same underlying reason: nobody flipped the switch after launch.
Reason 2: The site (or page) is too new for Google to have found it yet
A brand-new page has to be discovered before Google can crawl it, and discovery happens through links, a sitemap, or a manual request, not automatically. Google's Search Console reports two "not indexed yet" states for this: "Discovered, currently not indexed" (Google knows the URL exists but has not crawled it) and "Crawled, currently not indexed" (Google read the page but has not added it to the index, and may still do so later).
New-site delay is real but usually shorter than people assume, provided the basics are in place: an XML sitemap submitted in Search Console, and internal links pointing to the new page from pages Google already indexes. A page with zero internal links and no sitemap entry is effectively an island Google has no reason to visit.
It is possible to nudge this along. Inside Search Console's URL Inspection tool, the "Request Indexing" button asks Google to prioritize a crawl of that specific URL. Search Engine Land's guide to SEO timelines is direct about what this button actually does. It does not skip the review Google runs before indexing anything, and it will not override a noindex tag or a robots.txt block. It can surface a page that links and a sitemap haven't found yet, since submitting the URL directly is itself a discovery route, but the tool has a small daily quota and doesn't guarantee indexing. It is a nudge, not a fast pass.
Fix: confirm the sitemap is submitted and current. Link to the new page from at least one already-indexed page on the site. Use Request Indexing in Search Console as a follow-up step, not a substitute for those first two.
Reason 3: The content is too thin, duplicate, or not worth a separate listing
Google's Page Indexing report lists specific reasons a page is excluded for quality or duplication, including "Duplicate without user-selected canonical," where Google has grouped a page with a near-identical one and chosen the other as the version it will show. Thin pages, near-duplicate category or filter pages, and auto-generated pages with little unique text are the most common triggers.
This is different from a technical block: Google can crawl and even index-eligible-check the page, then decide it adds nothing beyond a page that already exists. Google's Page Indexing report documentation explains that this is treated as working as intended, not an error, because showing near-identical pages to searchers wastes their time. A rel="canonical" tag pointing elsewhere causes this. So does a cluster of overlapping URLs with no clear original: a filtered product listing, a tag archive, a print-friendly version. Google collapses the cluster and indexes only the one page it judges most representative.
Fix: check whether the page has a canonical tag pointing elsewhere. Search Console's URL Inspection tool shows both the "Google-selected canonical" and any "user-declared canonical." If the page genuinely is unique, strengthen its unique content instead of fighting Google's merge decision.
Reason 4: A technical error is stopping Googlebot from reading the page
Server errors, blocked CSS or JavaScript files, and broken redirect chains stop Google from rendering a page correctly, which can prevent it from being indexed even when nothing looks wrong to a human visitor. Google's own crawling guidance is explicit that any resource a page depends on to render (images, CSS, scripts) has to be accessible to an anonymous crawler, not just to a logged-in browser.
Sites built on JavaScript-heavy frameworks are especially prone to this. If Googlebot cannot execute the scripts that load the actual content, it may index an empty shell of a page instead. A 5xx server error during a crawl attempt can break indexing too. So can a redirect chain long enough to exceed Googlebot's documented ten-hop limit, or a robots.txt rule that accidentally blocks the folder holding a site's CSS. None of these show an obvious symptom on the live page a human sees in a browser.
Fix: use the URL Inspection tool's "Test Live URL" feature. It renders the page the way Googlebot sees it and flags any blocked resources. A page that looks fine to a person but renders blank or broken in that test has found its problem.
How to check exactly what's happening in Google Search Console
Search Console is the direct source of truth for indexing status, and it separates the diagnosis into a specific, ordered process rather than guesswork.
The process, in order:
- Open the Page Indexing report. This shows every URL Google knows about, grouped by status, indexed versus the specific reason it is not.
- Run the URL Inspection tool on the exact page. Paste the full URL into the search bar at the top of Search Console; it returns the live indexing status, the last crawl date, and the Google-selected canonical.
- Check for a noindex tag or blocked resources. The inspection result flags both directly if either is present.
- Confirm the sitemap includes the page. Under Sitemaps, verify the URL is discoverable through the submitted sitemap, not just through internal navigation.
- Use Request Indexing as the final step, not the first one. Only request a recrawl once the underlying cause (noindex, robots.txt, thin content, technical error) has actually been fixed; requesting indexing on a page that is still blocked just wastes the request.
Google's own Search Console documentation describes the Page Indexing report and URL Inspection tool as the two purpose-built reports for exactly this kind of diagnosis, one for a site-wide view and one for a single-URL deep dive.
When it's worth bringing in outside technical help
Most indexing problems are fixable with the five checks above and an hour with Search Console. Scale is where it gets harder. A site with thousands of pages, several CMS migrations behind it, or overlapping robots.txt rules nobody fully documented tends to have more than one of these five reasons active at once. Fixing one without checking the others just uncovers the next blocker.
The Social Target's SEO work runs that kind of audit by default: a full technical crawl, not a single-page check. Every noindex tag, thin page, and broken crawl path gets found in one pass instead of one support ticket at a time.
Getting a page indexed is also the floor underneath a newer problem: showing up inside AI-generated answers, not just the classic blue links. SEO and AEO run on the same retrieval foundation: an AI system cannot cite a page it cannot find any more than Google can rank one. If the AEO side of this is new territory, here's what answer engine optimization actually means once the indexing basics above are sorted.
These four reasons narrow the possibilities more than they pin down the exact cause every time, since quality, prioritisation, and crawl-capacity issues can overlap in Search Console. Start with the Page Indexing report, run the URL Inspection tool on the actual page, and work down the four reasons above until the exact blocker turns up. Tell us about your business if the audit turns up more questions than answers, that's the kind of technical mess a full SEO audit is built to sort out in one pass.
↳ Frequently asked
01How long does it take Google to index a new page?
There is no fixed timeline. A page with a submitted sitemap and internal links from already-indexed pages is often crawled within days; a page with neither can sit undiscovered indefinitely. Search Console's URL Inspection tool shows the actual status rather than a guess.
02Does robots.txt block indexing?
Not directly. A robots.txt Disallow rule blocks crawling, not indexing outright. A blocked page can still appear in Google's results, usually without a title or description, if other pages link to it. A noindex tag is the direct way to block indexing.
03Can a page rank without being indexed?
No. Indexing is a prerequisite for ranking. A page has to be stored in Google's index before it can be served for any search query, so an unindexed page cannot rank anywhere, regardless of how strong the content is.
04What does "Discovered, currently not indexed" mean in Search Console?
It means Google found the URL, usually through a sitemap or a link, but has not crawled it yet. There is no error to fix here on the page itself; it typically means Google has deprioritized the crawl, often due to site-wide crawl capacity.
05Does requesting indexing in Search Console speed things up?
It can nudge Google to prioritize a crawl of that specific URL, but it does not bypass Google's normal review, and it will not fix an underlying block like a noindex tag or a robots.txt rule. Fix the actual cause first, then request indexing.
06Is thin content the same as duplicate content?
No, though both keep a page out of the index. Thin content means a page has too little unique substance to be worth a separate listing. Duplicate content means a page overlaps closely enough with another page that Google indexes only one and treats the other as an alternate version.