Skip to content
AscendQ.ca — Websites, Apps & SEO Systems

Indexing & SEO 11 min read

How to Fix Pages Not Getting Indexed in Google Search Console

Page indexing: Discovered – currently not indexed
URL is unknown to Google
Sitemap: 129 submitted · 0 indexed

Nothing about SEO feels worse than publishing a site and watching Google ignore it. Search Console's verdicts sound alarming, the advice online is scattered across ten-year-old forum posts, and half of it is wrong. The good news: these verdicts are diagnosable in a fixed order, and in most cases nothing is "broken" — Google is rationing crawl on a young or duplicated site, and specific fixes accelerate it.

This is the exact diagnostic sequence we ran on our own production site this week (verdicts, causes, and fixes included below), and the same one we run in client audits. Work through it in order — each step eliminates a whole category of cause before you touch the next.

You're In The Right Place If…

  • Search Console shows "Discovered – currently not indexed" or "Crawled – currently not indexed" for most pages
  • URL Inspection says "URL is unknown to Google" for pages that are clearly in your sitemap
  • The sitemap report shows submitted counts but zero (or near-zero) indexed
  • Only your homepage is indexed weeks after launch
  • site:yourdomain.com in Google returns one or two results

First, Decode What Each Verdict Actually Means

Search Console's indexing states form a funnel, and knowing where a page sits in it tells you which fixes even apply. "URL is unknown to Google" means Google has never discovered the URL at all — it is not a quality judgement, it is absence of discovery. "Discovered – currently not indexed" means Google knows the URL (usually from your sitemap) but has not spent crawl budget on it yet. "Crawled – currently not indexed" means Google fetched the page and decided not to index it yet — this is where quality and duplication start to matter. "Duplicate without user-selected canonical" and "Alternate page with proper canonical tag" mean Google found more than one copy of the content and is choosing between them.

A brand-new domain almost always sits in the first two states for weeks. That alone is not a problem. What IS a problem is anything that makes Google's job harder while it decides how much to crawl you — and duplication is the most common self-inflicted wound.

Step 1 — Rule Out Hard Blockers In Five Minutes

Before anything clever, eliminate the three ways a site tells Google to go away. Check robots.txt (yourdomain.com/robots.txt) actually allows crawling — a stray "Disallow: /" from a staging config is more common than anyone admits. View source on a few pages and confirm there is no <meta name="robots" content="noindex">. Then check response headers for X-Robots-Tag: noindex — this one hides in CDN and hosting configs where you would never look, and it never shows up in your HTML.

# check the header nobody remembers to check
curl -sI https://yourdomain.com/some-page/ | grep -i x-robots-tag

# check what robots.txt actually serves
curl -s https://yourdomain.com/robots.txt

Step 2 — Hunt Down Duplicate Versions Of Your Site

Google hates ambiguity about which URL is "the real one", and most sites unknowingly serve their entire content at two or more addresses. The two we find constantly: the www/non-www split, and hosting-platform preview domains.

Test the www variant: if https://www.yourdomain.com returns your site with a 200 status instead of redirecting, every page on your site exists twice. Canonical tags mitigate this, but a 301 redirect from one host to the other removes the ambiguity entirely and consolidates crawl. Then test your hosting subdomain — yourproject.pages.dev, yourapp.vercel.app, yoursite.netlify.app. If those serve your content indexable, Google may crawl and even prefer them. They should either redirect to your real domain or send an X-Robots-Tag: noindex header.

  • curl -sI https://www.yourdomain.com/ — expect a 301 to the bare domain (or the reverse); a 200 means duplicate site
  • Check your host's default subdomain (.pages.dev / .vercel.app / .netlify.app) — noindex it or redirect it
  • Confirm every page's canonical tag points at the one true URL, trailing slash included
  • If you moved from http, confirm http:// 301s to https:// on every path, not just the homepage

Step 3 — Make Your Sitemap Earn Its Keep

Submit the sitemap in Search Console (Sitemaps → enter the URL) and then actually read the report: last downloaded date, discovered URL count, and errors. If you have deployed many times since the "last downloaded" date, resubmit — it prompts Google to fetch the current file rather than waiting for its own schedule. Make sure the URLs inside the sitemap are the canonical form (same host, same trailing-slash convention as your canonical tags) — a sitemap full of URLs that redirect wastes the little crawl budget a new site gets.

Step 4 — Give Google Reasons And Routes To Crawl

Discovery follows links. Orphan pages — reachable only through the sitemap — sit in "Discovered – currently not indexed" the longest. Strengthen internal linking so every important page is reachable within two or three clicks of the homepage: related-content blocks, category hubs, footer links for cornerstone pages. Then use URL Inspection → "Request indexing" on your handful of most important pages. It is rate-limited and not magic, but for key pages it reliably pulls the crawl forward.

Finally, be honest about demand signals. A young domain with no external links gets a small crawl allowance. One or two legitimate mentions — a business directory, an industry association, a local chamber, a supplier's partner page — measurably accelerate how seriously Google takes a new site.

What NOT To Do

  • Do not resubmit the same URLs for indexing every day — the quota is small and repeat requests do nothing
  • Do not delete and resubmit your Search Console property — you lose history and fix nothing
  • Do not add third-party "instant indexing" tools or ping services — the Indexing API is for job postings and live events, not regular pages
  • Do not panic-rewrite all your content in week two — "Discovered, not indexed" on a new site is a queue, not a rejection

The Fix, Step By Step

  1. 1

    Run URL Inspection on 3–5 key pages

    In Search Console, inspect your homepage plus a few important inner pages. Write down each verdict — the rest of the fix depends on whether pages are unknown, discovered, crawled-not-indexed, or duplicates.

  2. 2

    Check robots.txt, meta robots, and the X-Robots-Tag header

    Confirm robots.txt allows crawling, pages have no noindex meta tag, and — the one everyone misses — no X-Robots-Tag: noindex response header from your CDN or host (curl -sI yourpage | grep -i x-robots).

  3. 3

    Kill duplicate hosts: www and platform subdomains

    301-redirect www to the bare domain (or the reverse — pick one). Noindex or redirect your host's default subdomain (.pages.dev, .vercel.app, .netlify.app). Confirm canonicals all point at the surviving host.

  4. 4

    Resubmit the sitemap and verify its contents

    Resubmit in Search Console after fixing duplicates so Google re-downloads the current file. Every URL in it must be the canonical form — no redirects, no old host, consistent trailing slashes.

  5. 5

    Request indexing on priority pages and strengthen internal links

    Use "Request indexing" for your top pages, then make sure no important page is an orphan — link it from the homepage, hubs, or related posts.

  6. 6

    Give it 2–6 weeks and re-inspect

    On a young domain, indexing follows trust, and trust follows time plus signals. Re-run URL Inspection weekly; verdicts moving from "unknown" to "discovered" to "crawled" means the machine is working.

From the trenches

How we hit this on a real production site

We ran this exact audit on ascendq.ca — our own site — this week. Symptoms: homepage "Submitted and indexed", key pages either "URL is unknown to Google" or "Discovered – currently not indexed", and the sitemap report reading 129 submitted, 0 indexed, two weeks after launch.

The diagnostic found two real problems hiding behind the "new site" noise: www.ascendq.ca served the entire site as a 200 duplicate instead of redirecting, and our Cloudflare Pages preview domain served a third indexable copy. Canonical tags were pointing the right way, robots and meta tags were clean — but Google was still being asked to evaluate three copies of a two-week-old site.

The fix: a 301 host redirect from www to the bare domain and an X-Robots-Tag: noindex header on all .pages.dev hosts (both implemented in the Cloudflare Worker in front of the site), then a sitemap resubmission and Request Indexing on the money pages. Structural causes: eliminated the same day. The rest is the 2–6 week trust curve every new domain walks — which is exactly why we publish this checklist instead of pretending there is a secret bypass.

Frequently Asked Questions

How long does "Discovered – currently not indexed" normally last?

On a new domain, two to six weeks for important pages is normal, and low-priority pages can sit longer. If well-linked pages are still stuck after two months with clean technicals, look harder at content depth and duplication.

Does "Request indexing" actually work?

For individual important pages, yes — it reliably pulls the first crawl forward. It does not bulk-index a site, it is rate-limited, and repeating it on the same URL does nothing extra.

My sitemap says "0 indexed" — is the sitemap broken?

Usually not. "Submitted" counts what you gave Google; "indexed" counts what has cleared the whole funnel. A valid sitemap with 0 indexed on a young site means Google is still deciding — fix duplicates, then let the number climb.

Should I use canonical tags or 301 redirects for the www duplicate?

Both have a role, but a 301 is stronger: canonicals are a hint Google can ignore, a redirect removes the duplicate from existence. Use the 301 for host-level duplicates and canonicals for page-level variants (parameters, print views).

Is being on a shared platform subdomain (.pages.dev etc.) hurting me?

Only if it serves an indexable copy of your site. Noindex it or redirect it to your custom domain and it becomes a non-issue.

Still stuck? Send us the exact error.

Paste the exact error message you're seeing and where it happens. We'll take a look — if it's quick we'll point you at the fix, and if it's deeper we'll tell you honestly what it takes.

Reach the Summit

Rather have someone just fix it?

This is literally what we do all day — websites, SEO, performance, and the weird errors in between.

Start the Conversation