Canonical URL QA for Lovable and Headless Website Launches

Canonical problems at launch are quiet. The site looks right, every page loads, the client is happy, and three weeks later the wrong URL is in the index, a section has thinned out, and nobody can point at what broke because nothing did. The signals simply disagreed, and Google resolved the disagreement without asking.

This is the QA we run before a headless or Lovable-built site goes live, written against current Google Search Central guidance on canonical selection and on JavaScript sites. It contains no ranking data, traffic figures or crawl totals: fresh Search Console metrics were unavailable when this was written and older measurements were not reused as current.

What the canonical tag does and does not do

Google Search Central describes canonical selection as a process Google performs using several signals, of which your declared canonical is one. Redirects, internal linking patterns, sitemap inclusion and the content itself all feed the same decision.

The practical reading is that a canonical tag expresses a preference and the rest of your implementation either supports or contradicts it. QA is therefore not "is the tag present" but "does everything else agree with it". A site can have a perfect canonical on every page and still lose the argument because its internal links all point at a different form.

Decide the canonical form before you test anything

Write the rules down as a short specification, because a tester cannot verify an undocumented intention.

The parameter row is where tracking and SEO collide most often. Campaign links should resolve to a page whose canonical points at the clean URL, not at the parameter-laden variant; the reporting side of that is covered in our UTM parameters and canonicals guide.

The seven-step release gate

Run these in order on a staging or preview build before launch, and record the result. A gate that is not recorded gets skipped under deadline pressure.

One: raw HTML canonical. Request the page without executing JavaScript and read the canonical from the response body. Confirm it is present, absolute, and in the chosen form. Every page type gets checked, not just the home page: templates differ, and dynamic routes are where absent canonicals hide.

Two: rendered HTML canonical. Render the page and read the canonical again. It must be identical to the raw value. A difference means client-side code is modifying it, which is a defect even when the rendered value looks correct.

Three: one canonical per page. Count the canonical link elements. Two canonicals on a page is a self-contradiction and Google may ignore both. This happens most often when a layout and a page component each emit one.

Four: self-reference. Each page's canonical points at itself in the chosen form, except where a variant deliberately points at a consolidated target. A canonical pointing at the home page from every page is the classic catastrophic version of this bug, and it renders every per-page title and description irrelevant.

Five: redirect alignment. Every non-canonical variant returns a single permanent redirect to the canonical form. Check for chains, loops, and variants that return 200 instead of redirecting. Two reachable forms of the same page is duplication regardless of what the tag says.

Six: internal links. Site navigation, in-content links and footer links all use the canonical form. Internal linking is a canonical signal, so a site that declares one form and links to another is arguing with itself.

Seven: sitemap alignment. The sitemap contains only canonical, indexable, 200-returning URLs in the chosen form. No redirect sources, no noindex pages, no variants. A sitemap that lists redirecting URLs actively undermines the canonical it is supposed to support.

Raw versus rendered, in practice

Google's JavaScript SEO documentation separates crawling from rendering, which is why the distinction matters operationally rather than theoretically. A canonical present only after hydration depends on rendering happening, succeeding, and being read.

Three checks catch most of it. Compare the canonical, title and meta description between the raw response and the rendered page for one URL of every template. Confirm that a route reached by client-side navigation produces the same head values as the same URL loaded directly, because framework head handling sometimes differs between those two paths. And confirm the canonical is an absolute URL, since a relative canonical resolves against whatever URL the page was served at, which reintroduces the variant problem you were trying to remove.

Cross-domain canonicals, carefully

Cross-domain canonicals are legitimate for syndicated content and for consolidating a retired domain, and they are a decision with consequences on a property you may not control.

Search Engine Journal reported a cross-domain canonical case on September 18. That is third-party reporting of a particular situation, not a confirmed Google algorithm update, and it should not be read as new guidance. The durable practice is unchanged: document the intent, confirm the target page exists and is indexable, verify the receiving domain is not itself canonicalising elsewhere, and re-check after launch rather than assuming the consolidation took.

Failure modes we see repeatedly

Post-launch verification

The gate does not end at go-live. In the days after launch, check in Search Console which URL Google selected as canonical for a sample of pages across templates, watch for variants appearing in coverage reports, and confirm the sitemap is being read without errors. Where Google's selection differs from your declaration, treat it as a signal conflict to find rather than as something to argue with.

We had no access to fresh Search Console data while writing this, so no figures, timelines or recovery expectations are offered. How quickly a correction is reflected depends on crawling of your specific site, which only your own property data can show. Our SEO audit covers this checking as part of a launch review, our SEO services keep the rules enforced as the site grows, and our Vancouver team handles the relaunch cases where redirects and canonicals have to be untangled together. For a quick first look at one page, run our free SEO audit tool.

What this QA cannot tell you

It cannot predict rankings, traffic or recovery timelines, and it contains no crawl or index totals. What it does is remove the most common class of launch defect, the one that is invisible on the day and expensive a month later.