One Wrong Constant Cost Me Three Months of Indexing

My site had been live for three months. Impressions were climbing, positions were improving, and clicks were flat at almost zero. Search Console listed 33 pages with redirect problems and showed 208 of 389 sitemap URLs indexed.

The cause was one line:

export const SITE_URL = 'https://santoshpaudel.me'

Vercel was serving www. That constant said non-www. Everything downstream inherited the mistake.

Why one string did that much damage

Every SEO surface on the site derived from that constant:

• —the sitemap — all 389 URLs
• —every <link rel="canonical">
• —robots.txt's Host directive
• —every OpenGraph and JSON-LD URL

So the sitemap handed Google 389 URLs that all answered with a 308 redirect. And the page Google did reach carried a canonical tag pointing at the URL that redirected back to it.

That is the part that does the damage. A canonical pointing at a redirect gives the crawler contradictory instructions: this page says the real version lives over there, and over there says it lives here. Google resolves that by picking one itself, or by not indexing confidently at all.

The symptom list in Search Console was one bug wearing four costumes:

The symptom that gave it away

The Pages report listed the same post twice:

/blog/starting-podcast-2026...   49 impressions   position 10.22   (www)
/blog/starting-podcast-2026...   49 impressions   position 11.24   (non-www)

One post, competing with itself, at half strength on each hostname. Neither reached page one. Six other posts showed the same split.

The clearest tell was my own name: santosh paudel — 23 impressions, position 9. Google did not know which hostname was me.

The fix

export const SITE_URL = 'https://www.santoshpaudel.me'

One line, because everything routed through the constant. The only real work was finding the places that had bypassed it — the root layout had hardcoded the hostname separately, including metadataBase, which resolves relative metadata URLs for the entire app. Fixing the constant alone would have left it behind.

Worth grepping for:

grep -rn "yourdomain\.com" --include=*.ts --include=*.tsx app lib components \
  | grep -v "SITE_URL"

What I would check on any site

Three commands, two minutes:

# 1. Which hostname actually answers 200?
curl -sSI https://example.com/ | head -1
curl -sSI https://www.example.com/ | head -1

# 2. Does the sitemap agree with it?
curl -sS https://www.example.com/sitemap.xml | grep -c "<loc>https://www\."

# 3. Does the canonical point at itself?
curl -sS https://www.example.com/some-page \
  | grep -oE '<link rel="canonical" href="[^"]*"'

If the canonical does not match the URL that returns 200, stop and fix that before anything else. No amount of content or links compensates for a crawler that cannot decide what your page's address is.

The lesson I actually take from it

I spent three months reading the symptoms as a content problem. Positions were mid-page, so I assumed the content needed to be better. The content was fine. The plumbing was telling Google two different things about every page on the site.

Check that the machine is plugged in before rewriting what it prints.