Skip to content

Point the site at carsten-bokemeyer.de - #5

Merged
carstenb merged 2 commits into
masterfrom
domain-migration
Oct 2, 2026
Merged

carstenb merged 2 commits into
masterfrom
domain-migration

Conversation

@carstenb

@carstenb carstenb commented Oct 2, 2026

Copy link
Copy Markdown
Owner

The custom domain is live with a certificate and HTTPS enforced, but the markup still named the old address. Every canonical pointed at a URL that 301-redirects to the page declaring it.

What moved

17 URLs: canonicals, og:url and og:image on all three pages, the JSON-LD url/@id/image, both sitemap entries, the Sitemap: line in robots.txt, and the ORIGIN constant in design/check.js. The OG card footer follows, with assets/og-image.png re-exported so card and site agree.

profile/build.js needed no change: it reads the site URL from the JSON-LD, so it picks the new domain up by itself. Only the visible link text in profile/README.template.md still spelled out the old host.

README

New Domain and hosting section recording two things that are not visible from the tree:

  • There is deliberately no CNAME file. GitHub only writes one for branch-published sites; with a custom Actions workflow any CNAME file is ignored and the domain lives in the Pages settings.
  • The certificate covers the apex and www together. While www had no DNS record, GitHub could not complete the challenge for that name, so no certificate was issued for either, and "Enforce HTTPS" stayed greyed out for five days with nothing in the interface explaining why.

The manual-upkeep list now names every file a future domain change touches.

Verification

Invariants, html-validate, linkinator (27 links) and Lighthouse (9 runs) pass. I also confirmed design/check.js actually catches a missed URL, by reverting one sitemap entry and watching it fail.

axe could not run locally: Chrome updated to 154 and the chromedriver bundled with the pinned @axe-core/cli 4.13.0 supports 152. This CI run will show whether the runner hits the same mismatch — if it does, that is a separate fix.

🤖 Generated with Claude Code

carstenb and others added 2 commits October 2, 2026 16:44
The custom domain is live with a certificate and HTTPS enforced, but the
markup still named the old address, so every canonical pointed at a URL
that 301-redirects to the page declaring it.

17 URLs moved across canonicals, og:url, og:image, the JSON-LD url/@id/
image, both sitemap entries, the Sitemap line in robots.txt and the ORIGIN
constant in design/check.js. The OG card footer follows, with the image
re-exported so card and site agree.

profile/build.js needed no change: it reads the site URL from the JSON-LD,
so it picks the new domain up on its own. Only the visible link text in
profile/README.template.md still spelled out the old host.

README gains a "Domain and hosting" section recording what is not obvious
from the tree: that there is deliberately no CNAME file, because GitHub
only writes one for branch-published sites and ignores it for Actions
workflows, and that the certificate covers the apex and www together.
While www had no DNS record, no certificate was issued for either name and
"Enforce HTTPS" stayed greyed out for five days with nothing explaining
why. The manual-upkeep list now names every place a future domain change
touches.

Verified: invariants, html-validate, linkinator (27 links) and Lighthouse
(9 runs) pass. Also confirmed design/check.js actually catches a missed
URL by reverting one sitemap entry and watching it fail.

axe could not run locally: Chrome updated to 154 and the chromedriver
bundled with the pinned @axe-core/cli 4.13.0 supports 152. CI will show
whether the runner hits the same mismatch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The axe step failed: ChromeDriver 152 against Chrome 154, on the runner
and locally alike.

Pinning everything was right for the analysis tools, but wrong for this
one dependency. chromedriver is a shim for whatever Chrome is installed,
and both GitHub's runners and a developer laptop update Chrome on their
own. @axe-core/cli declares it as "latest" for exactly that reason; adding
package-lock.json froze it at 152.0.3 and turned a self-correcting
dependency into a time bomb that went off at the next Chrome release.

CI now reads the runner's Chrome major version and installs a matching
chromedriver with --no-save, leaving the lockfile untouched. Everything
that decides pass or fail stays pinned, axe-core 4.13.0 included; only the
protocol shim follows the browser.

Verified locally: with chromedriver 154 against Chrome 154, axe runs over
all four pages with 0 violations.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@carstenb
carstenb merged commit ef1c8b4 into master Oct 2, 2026
2 checks passed
@carstenb
carstenb deleted the domain-migration branch October 2, 2026 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant