You've launched. Google has found your pages. But instead of ranking, they sit in Search Console under “Discovered - currently not indexed” and nothing moves. The site looks fine. No errors. No penalties. Just silence. Here's what's actually happening.

What “Discovered - currently not indexed” really means

Google found your page, queued it, then decided not to index it. On a new or low-authority site, Google is cautious with its crawl budget. If anything about a page looks ambiguous, it postpones rather than commits. The most common ambiguity we see: the page tells Google two different addresses for itself at the same time.

The mismatch pattern

Every page should have a canonical tag - a line in the <head> that says “this is the definitive address for this content.” It looks like this:

<link rel="canonical" href="https://www.example.com/your-page/" />

Your sitemap also lists a URL for the same page:

<loc>https://example.com/your-page/</loc>

Spot the difference? One says www.example.com, the other says example.com. If your server 301-redirects one to the other (which is correct server behaviour), Google follows the canonical tag, hits a redirect, and on a low-authority site it often just backs off. Dont index it, try again later - except later never quite comes.

We audited four live BBL client sites recently - badboylabs.com, swas.org.uk, Walk on the Wild Side, and Raise the Flag Store. The root cause on two of them was an Astro config where the site URL string was hardcoded in one place but the server was serving a different variant. The canonical tag was pointing at the www. address; the real served domain was the apex. One 301 redirect sitting silently between Google and your page is enough to stall indexing.

A separate site had the same symptom from a different cause: the canonical URLs didn't match the server's trailing-slash behaviour. Pages were canonicalising to /about/ but serving at /about (no slash), triggering another 301. Same result in Search Console.

How to check it right now - for free

You need three values for any affected page. Pull them manually in under two minutes.

1. The canonical tag on the live page. Open the page in Chrome, right-click, View Page Source, then Ctrl+F for canonical. You'll see something like:

<link rel="canonical" href="https://www.example.com/about/" />

2. The URL in your sitemap. Visit https://yourdomain.com/sitemap.xml and find the same page's <loc> entry.

3. The actual URL your browser lands on. Click the link or type it in - note the exact address in the bar after any redirects settle.

All three should be identical. If any one of them differs - www vs no www, trailing slash vs no trailing slash, http vs https - you have a mismatch worth investigating. Then go to Search Console, open the Page Indexing report, click through to the “Discovered - currently not indexed” group, and inspect a specific URL. The “Canonical” field in the detail panel will show you what Google thinks the canonical is - and whether it matches what you intended.

The fix

The one-line principle: canonical URLs must come from a single source of truth at build time. Not two config values, not a hardcoded string in one template and a different string in another.

In an Astro project, that means one site value in astro.config.mjs, and every canonical tag, every sitemap <loc>, and every OG URL generated from Astro.site - not from a separate env variable or a manually typed string elsewhere.

// astro.config.mjs - one value, used everywhere
export default defineConfig({
  site: 'https://example.com', // no trailing slash, no www unless that's your canonical host
});

Then in your page templates:

<link rel="canonical" href={new URL(Astro.url.pathname, Astro.site).href} />

Thats it. Every canonical now matches your sitemap and your served URL because they all read the same value.

The second layer: add a post-build check that reads your generated sitemap and confirms every <loc> starts with your canonical host. If it doesnt, fail the build before you deploy. Catching it at build time means it never reaches Google.

After the fix

Once you've deployed, go back to Search Console, inspect the affected URLs, and hit “Request Indexing.” On the two sites we fixed during the audit, the mismatch was gone immediately after deploy. Re-indexing still takes days to weeks depending on your site's authority - but at least Google is no longer hitting a redirect when it tries to confirm your canonical.

A canonical mismatch isn't dramatic. No red warnings, no manual penalties. It just quietly stops your pages from ever getting off the ground. Fix the source of truth, verify the three values match, and the blocker is gone.

If you want us to run the same audit across your site - canonical tags, sitemap consistency, redirect chains, and the Page Indexing report - start with a conversation here. We'll tell you what's blocking indexing before we talk about anything else.