Why Is My Page Not Indexed by Google? Causes and Fixes

A status-by-status troubleshooter for pages Google won't index: how to confirm the problem in URL Inspection, what each Search Console Page indexing reason means and how to fix it, the CMS settings that cause the most common cases, and the edge cases that survive the obvious checks. Checked against Google Search Central, Search Console Help and each platform's documentation in October 2026.

Sev LeoLinkedInTwitter

Sev Leo is an SEO expert and IT graduate from Lapland University, specializing in technical SEO, search systems, and performance-driven web architecture.

First, confirm the page really isn’t indexed

A page that doesn’t show up when you search for it isn’t necessarily missing from Google’s index. It may be indexed but ranking poorly, indexed under a different URL, or excluded on purpose. Check what Google actually stored before you change anything. Most of the causes below trace back to a failure at one of the four stages of technical SEO.

1. Open the URL Inspection tool in Search Console and paste the exact URL, including the protocol, trailing slash and any parameters. You’ll need a verified Search Console property that covers the URL.
2. Read the verdict. URL is on Google means the page is indexed, so you have a ranking or tracking problem, not an indexing one. URL is not on Google comes with a reason under Page indexing.
3. Note the Last crawl date and the Google-selected canonical. If the canonical is a different URL, Google indexed that one instead of yours.
4. Click Test live URL to see what Googlebot gets right now, then View tested page for the rendered screenshot, the HTML and the HTTP response headers.
5. Compare the indexed result with the live test. If the live test passes but the indexed result shows an error, you may have already fixed it and Google simply hasn’t recrawled the page.

Two limits are worth knowing. The live test can’t predict canonical selection: Google shows the selected canonical only in the indexed data, and duplicate conditions aren’t checked in the live test. And if your site has fewer than 500 pages, Google suggests a quick site: search first, because the full Page indexing report is mostly useful for bigger sites.

For a tour of the report itself (the chart, the “Why pages aren’t indexed” table and how Validate fix works), see our guide to every Search Console report. Google’s own walkthrough of URL Inspection is below. It was recorded in January 2020, so parts of the interface look different today.

Every Page indexing status: what it means and how to fix it

The table covers every reason Google lists in its Page indexing report documentation. Read the last column with your goal in mind: many of these statuses are correct for URLs you never wanted in Search. Google itself says that having a page marked duplicate or alternate “is usually a good thing,” because it means the canonical version was found and indexed.

The statuses below cause the most confusion, so here’s what to check for each.

Crawled – currently not indexed

Google fetched the page, found nothing blocking it, and decided not to index it for now. Google’s help page says the URL may or may not be indexed in the future and that there’s no need to resubmit it.

Google doesn’t give a per-URL reason, but its How Search works guide names common indexing issues: low-quality content, robots meta rules, and site design that makes indexing difficult. On CMS sites, check these in order:

• Is it a near-copy? Tag, author and date archives, filtered category pages and location pages that swap one word are the classic CMS duplicates. Merge them, or noindex the ones that add nothing.
• Is the content in the HTML Google saw? In View tested page, check that the main text appears in the rendered HTML, not just the header, navigation and footer.
• Is it linked from anywhere that matters? A page reachable only through the sitemap or on-site search sends a weak signal. Link it from a relevant hub page with descriptive anchor text.
• Would anyone link to it? If the honest answer is no, improve it, fold it into a stronger page, or remove it.

If a whole batch of new posts lands here at once, look at what the batch has in common; it usually points to a template or publishing process, not to individual URLs. If the batch is auto-generated, check for thin content from autoblogging before you hunt for a technical bug.

Discovered – currently not indexed

Google knows the URL exists but hasn’t crawled it. According to Google, it usually wanted to crawl the URL but expected that to overload the site, so it rescheduled the crawl, which is why the report shows no last crawl date.

That leaves two levers: how fast and reliably your server responds, and how many URLs you ask Google to crawl.

1. Open the Crawl stats report and look for slow response times and 5xx errors.
2. Reduce faceted, parameter, archive and session URLs that compete for crawling.
3. Make sure important pages are linked with plain <a href> links from pages Google already crawls.
4. List them in a clean sitemap with accurate lastmod dates. Our sitemap validator catches malformed XML, relative URLs and duplicates.

Google’s crawl budget guide is written mainly for large sites (roughly 1 million+ pages, or 10,000+ pages that change daily), but it also names sites with a large share of URLs in this status as part of its audience. For the large-site version of the problem, see our post on crawl budget mistakes.

Duplicate and canonical statuses

Three statuses mean Google found several URLs with the same content and indexed one of them: Duplicate without user-selected canonical, Duplicate, Google chose different canonical than user, and Alternate page with proper canonical tag. Inspect the URL and look at the Google-selected canonical. If it’s the URL you want indexed, there’s nothing to fix.

If Google picked the wrong one:

1. Make one URL the obvious choice. Give it a self-referencing canonical URL, use that exact URL in internal links, the sitemap and hreflang, and 301 the variants to it.
2. Check that the declared canonical really is a duplicate. Google says that if the user-declared canonical isn’t similar to the current page, it won’t ever choose it.
3. If the pages shouldn’t be duplicates (two city pages with the same copy, for example), make the content substantially different.
4. Give it time. Google’s canonicalization troubleshooting guide says pages can stay in a duplicate cluster for up to two weeks after you fix the content.

This is also why Request Indexing rarely helps with duplicates: the live test doesn’t evaluate canonical conditions.

noindex and robots.txt statuses

These two get confused, and combining them is one of the most common reasons a page gets stuck.

• robots.txt controls crawling. A Disallow rule stops Googlebot from fetching the page. As Google’s robots.txt introduction explains, it doesn’t reliably keep the URL out of Search: Google can still index a blocked URL it finds through links, usually without a description. That’s the “Indexed, though blocked by robots.txt” status.
• noindex controls indexing. It works as a <meta name="robots" content="noindex"> tag or an X-Robots-Tag: noindex HTTP header, but only if Googlebot can fetch the page. Block the page in robots.txt and Google never sees the noindex. Google doesn’t support noindex rules inside robots.txt.

To get a page indexed, remove both. To keep a page out, allow crawling and use noindex, put it behind a login, or return 404/410 if it shouldn’t exist. More on how the file works in our robots.txt glossary entry.

If a page shows Excluded by ‘noindex’ tag and you can’t find the tag in your template, check the response headers in View tested page. Hosting platforms, CDNs and plugins can add X-Robots-Tag without touching your HTML.

Soft 404, 404 and redirect statuses

A soft 404 returns HTTP 200 but looks like an error to Google: an empty search results page, a “product unavailable” template, a category with no items, or an app that shows an error message on a 200 response. Return a real 404 or 410 when the page is gone; otherwise add enough content that it doesn’t look empty. For client-side apps, Google’s JavaScript SEO guide suggests a JavaScript redirect to a URL that returns 404, or a noindex robots tag on the error state.

A plain 404 isn’t automatically a problem. Google says it’s fine for a page removed without replacement, and the report only lists URLs that returned 404 in the past month. Use a 301 when the page has moved.

Page with redirect is usually fine too: the redirecting URL isn’t indexed, its target can be. Redirect error means a loop, a chain that’s too long, or a broken URL in the chain. Googlebot generally follows up to 10 hops, per Google’s HTTP status code documentation, but chains usually come from stacked rules (a CMS plugin, a CDN and a server config all redirecting). Flatten them to one hop.

Server errors, 401 and 403

Server errors can be temporary, so a live test may pass even though Google’s crawl failed; check server and CDN logs for Googlebot requests around the last crawl date. 401 and 403 responses usually come from staging passwords, firewall rules or bot challenges. Googlebot never sends credentials, so a 403 served to it is a misconfiguration. If you allowlist Googlebot, verify it by reverse DNS lookup or Google’s published IP ranges, not by user agent, which anyone can fake.

CMS settings that stop pages from being indexed

On CMS sites, most indexing problems come from one setting applied to a whole template or environment, so one fix often recovers hundreds of pages. If you’re not sure what a site runs on, our CMS detector will tell you. Here’s what to check on each platform; every setting below was checked against the vendor’s documentation in October 2026.

WordPress

• Settings > Reading > Search engine visibility. When “Discourage search engines from indexing this site” is checked, WordPress (since version 5.3) adds a noindex, nofollow robots meta tag to your pages, according to the WordPress documentation. It’s often left on after a site launches, and it comes along when you copy a staging database to production. The symptom: every URL shows Excluded by ‘noindex’ tag.
• SEO plugin settings. SEO plugins have their own search-visibility options per post type, taxonomy and individual post. A noindex set there looks identical in Search Console, so check the settings for the whole content type, not only the post.
• Archive pages. Tag, category, author and date archives often repeat the same posts and end up as duplicates or Crawled – currently not indexed. Decide which archive types deserve to be indexed and noindex the rest.
• Security and caching plugins. Bot protection can serve Googlebot a 403 or a challenge page, and a cached error page served with a 200 can turn into a soft 404.

Webflow

• Staging indexing (Site settings > SEO > Indexing) controls the webflow.io subdomain. Turning it off publishes a robots.txt that blocks only the subdomain, and it needs a Site plan or a paid Workspace, per Webflow’s help center. Because it’s a robots.txt block, staging URLs Google already knew about can linger, so make sure your canonical tags point to your custom domain.
• The Sitemap indexing toggle (Page settings > SEO settings, or Item details for a CMS item) adds a noindex meta tag and removes the page from the sitemap. A toggle left off on a page or CMS item is a common cause of Excluded by ‘noindex’ tag.
• Sitemap mismatches. Pages disallowed in robots.txt, and pages with a noindex added through custom code, still appear in Webflow’s auto-generated sitemap unless you turn Sitemap indexing off. That’s how sitemap URLs end up reported as blocked or noindexed.
• Traffic control toggles in the same Indexing section can disallow whole groups of bots, and the search engine crawler group includes Googlebot. Both groups are allowed by default, so check that nobody switched off the wrong one.
• robots.txt can’t be deleted once you’ve created one in Webflow, only replaced. To undo a blocking rule, replace it with an allow-all rule and republish.

Shopify

• Private mode. New stores start in private mode, which hides every page behind a password page from visitors and search engines until you launch, per Shopify’s help center. If Google sees only the password page, check that the store is set to public.
• The default robots.txt blocks crawling of cart, checkout, account and admin pages, plus filtered (/collections/*+*) and sorted (/collections/*sort_by*) collection URLs. Shopify says “Indexed, though blocked by robots.txt” on URLs like these is normal and usually needs no action.
• Custom robots.txt.liquid edits aren’t supported by Shopify Support, and Shopify warns that getting them wrong can cost you all your traffic. If pages stopped being crawled after a theme change, check this file first.
• Collection-aware product URLs. The same product can live at /products/handle and inside a collection path, which themes generate with the Liquid within filter. Shopify’s own docs flag the SEO implications of the same content on separate URLs. Check that the canonical tag on both versions points to the /products/ URL; collection versions in the Duplicate statuses are then expected.

Next.js and other headless setups

• Client-only rendering. If a page renders only in the browser, the first HTML response can be an empty shell, and content or links that appear only after a click or scroll can be missed. Server rendering or static generation puts the content in the initial HTML. See our JavaScript SEO glossary entry and our comparison of headless vs traditional CMS for SEO for rendering modes.
• notFound() after streaming starts. In the App Router, if notFound() runs inside a Suspense boundary after the response started streaming, Next.js keeps the 200 status and adds a noindex robots tag, per the Next.js docs. Missing pages then show up as Excluded by ‘noindex’ tag, not Not found (404), and a live page that hits this path (say, the CMS API returned nothing for its slug) becomes a noindexed 200. Calling notFound() before streaming starts returns a real 404.
• Preview and staging deployments. Vercel adds X-Robots-Tag: noindex to preview deployments and to superseded production deployments, but not when a custom domain such as staging.example.com is assigned to a non-production branch, per Vercel’s knowledge base. That staging domain can then be indexed as a duplicate unless you add the header yourself. The reverse mistake is environment-based noindex logic that also fires in production.
• Redirect stacking and page weight. Trailing-slash, locale and www rules from the framework, host and CDN can combine into Redirect errors; pick one URL format and test it with curl -I. And large inlined hydration data counts toward Googlebot’s 2MB HTML limit (see the edge cases below).

Edge cases that survive the obvious checks

If the template is clean and the status still makes no sense, one of these is often the cause. Each one comes from Google’s current documentation: the robots.txt specification, the Googlebot documentation linked above, the pagination docs and the hreflang guide. Cases already covered in the status sections (robots.txt plus noindex, client-side soft 404s, slow duplicate clusters) aren’t repeated here.

What won’t force a page into the index

• Request Indexing in URL Inspection asks Google to recrawl a URL. It’s subject to a quota, it doesn’t guarantee indexing, and Google says Crawled – currently not indexed URLs don’t need resubmitting. Use it once, after a real fix.
• Resubmitting a sitemap helps Google find new or changed URLs. It doesn’t make Google decide a page is worth indexing, one of several limits of automated indexing worth planning around.
• IndexNow doesn’t reach Google, because Google isn’t one of the search engines participating in it. It’s still useful for Bing and the other engines that are.
• Google’s Indexing API only supports pages with JobPosting or BroadcastEvent (livestream) structured data. Using it for ordinary pages won’t get them indexed.

When to use each of these, quotas included, is covered in our guide to submitting a URL to Google.

How to confirm the fix worked

1. Reproduce the fetch yourself. Run curl -I on the exact URL. You want a 200 (or a single 301 to a 200) and no X-Robots-Tag: noindex, and the HTML should contain the canonical you expect.
2. Run Test live URL and open View tested page. Check that the main content and internal links appear in the rendered HTML.
3. Request indexing once for that URL.
4. For template-wide fixes, use Validate fix in the Page indexing report. Google says validation typically takes up to about two weeks and can take longer.
5. Check your logs for Googlebot requests to the URL after the deploy, and the status code it received.
6. Re-inspect after the next crawl. The Last crawl date should be later than your fix, and the status should have changed.

To catch template-wide problems such as missing canonicals or robots.txt issues before Google recrawls, run the affected pages through a quick technical SEO audit.

A 15-minute triage order for any non-indexed page

1. Inspect one affected URL and one healthy URL on the same template; compare status, Google-selected canonical and last crawl.
2. Rule out hard blocks: HTTP status, robots.txt, noindex in HTML and headers, logins and firewalls.
3. Check which URL Google chose: canonicals, redirects, duplicates.
4. Check what Google saw: rendered HTML, page size, links that work without clicks.
5. Check the CMS: search visibility settings, per-template SEO settings, staging rules.
6. Only then judge value. If a crawlable, unique page still sits in Crawled – currently not indexed, improve it or merge it into a stronger page.

Fix the cause in the template, not page by page, and every URL that uses it recovers together.