What brokeUpdated 3 October 2026
Every canonical URL pointed at a page that redirects
Every top-level page on kokkekunst.no named a .html address as its canonical URL, and that address answers with a 308 redirect. The news articles were not affected, and they were the pages we looked at most, so nobody noticed.
The short version
What went wrongTop-level pages named .html canonical URLs that answer 308, because the layout used the build-time path, while article pages set their own and hid the bug.
How we found itThe fix commit, six days after launch with only the front page indexed, traced the canonical to the build-time path and checked the build output.
The rule nowCheck the built result, check that canonicals answer without redirect, and check shared defaults on the pages nobody opens.
This post documents something Claude got wrong. The claim rests on a commit or a file, not on memory. All of Claude's mistakes
According to the fix commit, dated 5 September 2026, the kokkekunst.no domain had been live for six days and still had only one page in Google’s index: the front page. The commit does not say how this was checked. The fix commit names one plausible reason. Every top-level page told search engines that its canonical address was a URL that does not exist as a page. That URL only redirects.
What was wrong
A canonical link tells search engines which address is the real one for a page. On the kokkekunst.no site, the top-level pages named the .html version of their own address:
- the front page claimed
/index.html /mesterskapclaimed/mesterskap.html/omclaimed/om.html
None of those addresses serve a page. Each one answers 308 and sends the visitor on to the clean URL. So every one of these pages said, in effect, “my real address is a redirect back to me.”
The fix commit puts it this way (translated from Norwegian): a canonical that points at a redirect “is a self-contradictory signal, and Google may choose not to index the page.” The commit calls this a plausible explanation for why only the front page was indexed after six days. It does not claim to have proven it, and neither do we. We have no indexing measurement from after the fix in the material for this post.
Why it happened
The site is built with Astro, and its config sets build.format: 'file'. In that mode the page at /mesterskap is written to disk as mesterskap.html. While the build runs, the path Astro reports for the page being rendered is therefore /mesterskap.html, not /mesterskap.
The shared layout built the canonical URL by taking that path and joining it to the site’s base address. A page could pass in its own canonical, and if it did not, the layout fell back to the build-time path. So every page that left the job to the layout got the .html version.
Read on its own, that line looks right: take the current path and make it absolute. The problem only shows up once you know what the path holds during a build with this output format.
Why it went unnoticed
The news article pages were never affected. The article template sets its own canonical URL. Those were the pages we looked at most.
The commit message says it directly (translated): “That is exactly why the bug was left standing so long: it hit everything except what we looked at most.”
The pages we looked at most were correct. The broken pages were the top-level pages. The commit names three of them: the front page, the championship page and the about page.
The same bug also had a second, smaller effect. The layout used the same path to mark the active link in the menu, so that comparison also ran against the .html variant. The fix covers both.
How it was fixed
The fix changes the layout so that, before building the canonical URL, it turns the build-time path back into the address a reader actually uses:
- a trailing
/index.htmlbecomes/ - a trailing
.htmlis removed - a trailing slash is removed, except on the root
Pages that pass their own canonical, like the news articles, still override this.
We checked the fix against the build output, not just the source. According to the commit, after the fix the front page reports /, the championship page reports /mesterskap and the about page reports /om. The article pages and the sitemap were unchanged.
The layout now carries a comment that explains the whole chain: the build format, the .html path during the build, the 308, and why the article pages hid the problem. The next person to edit that line, human or model, will see why it looks the way it does.
Who made the mistake
Henning writes no code himself, so the original layout line was Claude’s, and so was the mistake. The fix commit describes the bug, its cause and how it was verified.
The rule
Check the built result, not just the code. In a static site, what search engines see is the HTML that comes out of the build. Values like the current path can mean something different during the build than they appear to mean in the source.
Check that every canonical URL answers without a redirect. A canonical address should return the page directly, not a 3xx status.
When something hides the bug, look where you look least. The pages that set their own canonical were correct and drew all the attention. The top-level pages, which relied on the default, were wrong. When one part of a system overrides a shared default, the default itself needs checking on the pages nobody opens.
Corrections
- Attribution corrected: an earlier version said the material did not show who wrote the code and did not put the mistake on Claude. Henning writes no code himself; the code was written by Claude.