Launched a new site two days ago and Google Search Console showed
zero indexing. Spent longer than I'd like to admit assuming it was
just "new domain, be patient" — until I actually checked the live HTML.
The bug
My server correctly redirects uxtion.ai → www.uxtion.ai (301/308).
Standard setup. But every canonical tag on the page — and the JSON-LD
schema, and the sitemap — still pointed back to the non-www version.
So Google was getting two contradicting signals on the same page:
- "The real URL is www" (from the redirect)
- "No wait, the real URL is non-www" (from the canonical tag)
Classic case of shipping the redirect and forgetting the metadata
has to agree with it.
The fix
Pulled every hardcoded domain reference into a single shared constant
tied to the actual production env var, instead of a string typed out
in six different files. Once that shipped and the sitemap re-read
correctly, the homepage went from "not indexed" to "URL is on Google"
within a few days.
Why I'm writing this
I'm building UXtion — a tool that audits Lovable
and Cursor-built sites and hands back paste-ready fixes instead of
another report to interpret. Ironically, this bug was in my own
marketing site, not a customer's. Turns out "diagnose the problem vs.
actually fix it" applies to your own infrastructure too.
If you're running a Next.js App Router site with a www/apex split,
worth checking alternates.canonical and any JSON-LD @id/url
fields aren't hardcoded to the wrong domain — tsc and your test
suite won't catch this, only a live view-source will.
Top comments (2)
Canonical bugs are painful because everything can look fine at the page level while discovery is quietly broken. This is a good reminder that SEO debugging needs source inspection, not just dashboard watching.
The brutal part of this class of bug is that Google fails completely silently. No error, no warning, it just quietly doesn't index and you sit there telling yourself "new domain, be patient" for two weeks. The 5-minute check that catches it: run URL Inspection on a couple of key pages right after launch and compare "user-declared canonical" against "Google-selected canonical." If they don't match, you've got exactly this. And 90% of the time the root cause is what you hit, a base URL hardcoded in the canonical and JSON-LD that drifted from whatever the redirect or env actually resolves to. Nice writeup, this will save someone their two days.