Blog · 2026-08-30

New Site With Zero Pages Indexed? Check Whether Your Canonical and Sitemap Contradict Each Other

Before you start rewriting content: run the URL Inspection API and look at lastCrawlTime. All empty means your signals are fighting. Align the canonical tag, og:url, JSON-LD and sitemap, verify every entry returns 200, resubmit the sitemap, and that usually solves it.

The site has been live for weeks, the sitemap is submitted, the content is not thin, and Search Console still shows 0 indexed. The usual reaction is to go back and rewrite articles, change titles, or reassure yourself that a new domain just takes time. Stop for a moment. Zero pages indexed is usually not a quality problem, it is a site telling the search engine two contradictory stories, and rewriting content will not fix it. You fix it by looking in the right place.

Start With lastCrawlTime: All Empty Means Google Never Came, Not That It Came and Disliked You

Run every URL on the site through the Search Console URL Inspection API (urlInspection().index().inspect()) and focus on two fields: coverageState and lastCrawlTime. Together they split "not indexed" into two completely different illnesses:

• lastCrawlTime has a value and the state is "Crawled - currently not indexed": Google came, looked, and decided to pass for now. Only at this point do content quality and template duplication become the issue.
• lastCrawlTime is empty and the state is stuck on "Discovered - currently not indexed", or even "URL is unknown to Google": Google never crawled it. The writing could be excellent and it has not been read. The problem is in the technical signals, not the articles.

On the "entire site at zero" case we handled, the scan came back with lastCrawlTime empty across the board. Once that field is empty you can skip the content anxiety and go straight to the signals.

Here Is the Culprit: The Sitemap Says A, the Canonical Says B, and B Gets 308'd Back to A

Anonymized from the real case, three lines tell the whole story:

sitemap <loc>       →  https://example.com/reviews/foo        (no extension)
page canonical      →  https://example.com/reviews/foo.html   (with .html)
actual foo.html     →  returns 308, redirecting back to /reviews/foo

Walk it from Google's point of view: follow the sitemap and crawl A, the canonical tag on A says "the official version is B", go fetch B, and get 308'd back to A. The two signals kick the ball back and forth, and Google will not guess which one counts. It defers the page, or it gives up on indexing it entirely.

This trap is especially easy to hit on static hosting platforms. Cloudflare Pages, for example, automatically 308-redirects /foo.html to /foo. The file on disk is foo.html, but the public official URL has no extension. The generator emits a canonical based on the filename with .html on it, the sitemap emits a loc without the extension, and each piece of code looks correct on its own. The error is the inconsistency.

Four Places to Align, and Missing One Means You Are Still Fighting

A page's official URL appears in more than one place on the site, and these four must match character for character:

1. <link rel="canonical">
2. <meta property="og:url">
3. The "url" on WebPage / Article nodes in your JSON-LD
4. <loc> in sitemap.xml

The fix is not opening four files and editing each one. It is defining a single "official URL" function in the generator and emitting all four places from that one value. Keeping four strings in sync by hand means they will contradict each other again eventually.

A neighboring problem worth mentioning: a sitemap loc that picked up the build directory as a path prefix and 404s in production. We hit a nastier variant, where one "helpful" fallback line in the verification script stripped the prefix before comparing, so the broken loc passed every check and stayed green for a very long run without anyone noticing. The lesson: a fallback may only absorb known and correct differences in form, such as a platform's extensionless URLs. It must never absorb errors. Before writing each fallback line, ask one question: is this tolerating a variation, or hiding a bug?

There Is Only One Acceptance Criterion: Every loc Returns 200 Directly

After the fix, "the page opens" is not enough. Browsers and curl -L both follow redirects automatically, so a 308 is invisible. Turn redirect following off to measure it:

# no -L, so you can see the real status code
curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/reviews/foo"

The standard: every <loc> in the sitemap returns 200 when requested directly. A 308 is a failure, because it means the loc is not written in the official form. A 404 needs no explanation. Then spot check a few pages to confirm the trinity: the URL you requested, the page canonical and the og:url are all identical.

The last step is the one most people skip: go back to Search Console and resubmit the sitemap. Without that, Google still holds the old file, the contradictory signals stay in its queue, and everything you just fixed counts for nothing.

Still Stuck on "Discovered" After Aligning? Check Internal Links Next

Aligning those four places solves "the signals contradict, so it does not crawl". If the signals are clean and a page still sits on "Discovered - currently not indexed" long term, the next usual suspect is thin internal linking: the page exists only in the sitemap and almost nothing on the site references it, so Google decides it is not important and never queues a crawl.

We rebalanced internal links on a content site in a high-competition industry. Before the rebalance, 49 pages had exactly 1 inbound link. After bringing all 116 pages on the site to at least 4 inbound links each, the site reached 153 of 173 pages indexed (about 88 percent). The method was automation again: treat "inbound reference count per page" as a build-time gate metric, compute it before output, and have any page that falls short automatically pull links from related pages, rather than relying on editors to remember to cross-link.

Closing: Write These Checks as a Script and Put Them in the Deploy Pipeline

The investigation order, summarized: URL Inspection API for lastCrawlTime, then if it is all empty align the canonical, og:url, JSON-LD url and sitemap loc across all four places, verify each loc returns 200 with redirect following disabled, resubmit the sitemap, and if it is still stuck go check internal links. Every step here is a programmable check, worth writing into a script that runs automatically on every deploy instead of something a human remembers after the fact. If your new site is also stuck at zero indexed, or you want to automate these checks and stop re-investigating the same thing, come talk to us. Pulling the actual URL Inspection API responses usually pinpoints which layer is fighting within minutes.

We Turned New Site Launches Into a Service

A canonical fighting the sitemap is only one way to die. A new site usually fails to get indexed for more than one reason, and you eliminate them one at a time.

• Site architecture and technical SEO: canonical tags, sitemap, robots and structured data aligned in one pass
• Index monitoring: check indexing status page by page, find the reason for anything that did not make it, and resubmit
• Content production: original content is the reason to index you in the first place, and it is the step most often skipped

Delivered in four weeks, with output every week. Specs are on iGaming SEO Site Build.