Canonical domain mismatch: CNAME uses www, every URL in the site uses the bare domain #14

The problem

CNAME contains www.gfpricechecker.com, but all 51 absolute URLs in the site's markup and config point at the bare gfpricechecker.com. The two disagree, and the bare domain is the one that redirects.

Verified live (2026-08-12):

$ curl -sI https://gfpricechecker.com/
HTTP/2 301
location: https://www.gfpricechecker.com/

$ curl -sI https://www.gfpricechecker.com/
HTTP/2 200

So www is the real host, and every self-referencing canonical tag on the site points at a URL that 301-redirects. Same for the sitemap: all 8 listed URLs redirect, and robots.txt points crawlers at a sitemap URL that redirects too.

Why it matters

• Self-referencing canonicals should resolve directly. Pointing them at a redirect is a well-known SEO smell — search engines usually follow it, but it wastes crawl budget and leaves the canonical signal weaker than it should be, especially on a small site that has no authority to spare.
• The sitemap is worse than the canonicals. A sitemap whose entries all redirect is a signal to search engines that the sitemap is not maintained. lastmod accuracy was just fixed in Align website content with app unit-pricing and receipt verification (#11) #13; this undercuts the benefit.
• Open Graph and Twitter url tags point at the redirecting host, so shared links take an extra hop and social scrapers may cache the pre-redirect URL.
• It's also just confusing for anyone editing the site — there's no single stated answer to "what is this site's address?"

Affected

CNAME is the sole outlier. Everything else uses the bare domain:

• <link rel="canonical"> — all 8 pages
• og:url and twitter:url — all 8 pages
• og:image and twitter:image — all 8 pages
• JSON-LD: url and logo in the Organization block (index.html), and the description/URL fields in the MobileApplication block (features.html)
• sitemap.xml — all 8 <loc> values
• robots.txt — the Sitemap: line

$ grep -rn "www.gfpricechecker.com" --include='*.html' --include='*.xml' --include='*.txt' --include='*.json' . | wc -l
0
$ grep -rn "https://gfpricechecker.com" --include='*.html' --include='*.xml' --include='*.txt' --include='*.json' . | wc -l
51

Which way to fix it

Two options, and it needs a decision before anyone starts editing.

Option A — align the site to www (recommended). Matches how the site actually resolves today, so nothing about live behaviour changes. CNAME was deliberately changed to www on 2026-06-11 (42bfec4), which suggests this was intentional. Work is a mechanical sweep of the 51 references.

Option B — switch to the bare domain. Arguably the nicer address, and matches how the site is written about everywhere else. But it means changing CNAME, confirming GitHub Pages and Cloudflare both serve the apex correctly, and re-checking that www then redirects to the apex rather than the other way round. More moving parts, and a window where the site could be unreachable if the DNS is wrong.

Either way the redirect should keep working in the non-canonical direction — this is about making the stated canonical match the actual one, not about dropping a hostname.

Acceptance criteria

• Canonical host decided and recorded in Claude.md
• All canonical, og:url, twitter:url, and image URLs use it
• All JSON-LD URLs use it
• All sitemap.xml <loc> values use it, and robots.txt points at the matching sitemap URL
• curl -sI on a canonical URL returns 200, not 301
• The non-canonical host still redirects to the canonical one
• Cloudflare Web Analytics still reporting after the change

Context

Found while working #11. Flagged there and deliberately left out of #13, since it needs a decision on the canonical host and touches DNS rather than content.