Canonical tags point at beamable.github.io instead of help.beamable.com

[allister-beamable]

Every published page on help.beamable.com declares a canonical URL pointing at the GitHub Pages hostname rather than the customer-facing one:

<link rel="canonical" href="https://beamable.github.io/Docs/Unity-6.0/">

So help.beamable.com tells search engines that beamable.github.io is the authoritative copy of its own content, splitting search authority between two hostnames. This is independent of the ReadMe.io situation and is a live SEO bug today.

It also undercuts the ReadMe sunset: transferring search authority away from beamable2.readme.io is much harder when the intended destination disclaims itself.

The cause is almost certainly site_url: https://beamable.github.io/Docs/ in mkdocs.yml, which Material uses to build canonical links. Present on every content branch, so the fix is a one-line change per branch — but check first whether anything else depends on site_url (sitemap generation does), and confirm help.beamable.com is the intended permanent hostname rather than a redirect that might change.

Small enough for a single session once that is confirmed, hence bite-size.

[allister-beamable]

The capitalization is the reason this survived: /Docs/ never resolved at all

The bad site_url was wrong in two independent ways, and it matters because they fail differently.

The GitHub Pages path segment for a project site is the lowercase repository name, and it is case-sensitive. The repo is beamable/docs (confirmed via gh api repos/beamable/docs --jq .name), so the served path was always /docs/, never /Docs/. On top of that, gh-pages carries a CNAME of help.beamable.com, and Pages serves a custom domain from the domain root — so there is no repo path segment in the real URL either.

Measured today:

URL	Result
beamable.github.io/	404 — no org-level Pages repo exists
beamable.github.io/Docs/	404 — "Site not found" (wrong case)
beamable.github.io/Docs/Unity-6.0/	404 (wrong case)
beamable.github.io/Unity-6.0/	404 — missing repo segment
beamable.github.io/docs/	301 → help.beamable.com/
beamable.github.io/docs/Unity-6.0/	301 → help.beamable.com/Unity-6.0/ (200)

So the canonical tags were not merely pointing at a redirecting hostname — they pointed at a URL that has never resolved, on any hosting shape this site has ever had. That is also why nobody caught it by clicking: the capitalized form fails like a routing quirk, while the lowercase form redirects cleanly and hides the mistake.

There is no redirect rule that could have caught /Docs/

GitHub Pages exposes no redirect configuration — no .htaccess, no _redirects, no netlify.toml equivalent, no API field. The /docs/ → help.beamable.com 301 above is not a rule anyone wrote; it is GitHub's automatic custom-domain enforcement.

Nor can a 404 page catch it. beamable.github.io/Docs/ returns GitHub's "Site not found" page, which is a site-level miss resolved before any repository's content is consulted — our own 404.html never runs. (It does work correctly inside the site: help.beamable.com/Unity-6.0/nope/ serves our themed "404 – Page Not Found | Beamable Docs".) And a repo literally named Docs is not an option, since repository names are case-insensitive for uniqueness within an owner.

The only theoretical lever is creating an org-level beamable/beamable.github.io site, whose 404.html would catch unclaimed paths. That is disproportionate for a URL that appeared nowhere but our own site_url, was never indexed (it 404s), and is now fixed at the source.

Fix status

site_url is now https://help.beamable.com/ on all 20 branches carrying an mkdocs.yml. The trailing slash is load-bearing: mike/mkdocs_plugin.py builds the canonical as urljoin(site_url, version), so dropping it would eat the last segment. Verified through mike's real code path with MIKE_DOCS_VERSION=Unity-6.0 mkdocs build — page canonical, deep-page canonical, and every sitemap.xml <loc> come out correct.

Retired-but-still-served lanes are included deliberately: Unity-4.0, Unity-5.0, Unreal-1.1/2.0/2.1, WebSDK-0.6, and CLI-6.0/6.1/6.2 are frozen for content but still answer on help.beamable.com, so their canonicals were fixed too.

Two stale prose references turned up in the same sweep and are fixed: the CLI guide's Unity version-table link (beamable.github.io/docs/unity/..., which 301'd but landed on a 404, since the redirect preserves a path that had no version segment — now the Unity-Latest alias), and AGENTS.md's Deployment section, which documented the non-existent /Docs/ URL and now states the real shape plus both redirect behaviors.

Nothing is live until each version is redeployed — the canonical is baked into the built HTML.