fix(seo)!: canonical and sitemap point at weekndlabs.com/design - #29
Merged
Conversation
The proxy path wins. Every inbound link and every internal link already pointed
there, and one domain is easier to grow than two.
BREAKING for anything reading the canonical: it was design.weekndlabs.com and is
now weekndlabs.com/design. The subdomain stays fully crawlable on purpose, because
blocking a duplicate stops Google reading the canonical tag that deduplicates it.
An origin with a path breaks the obvious join. `new URL('/guide/', '…/design/')`
resolves to weekndlabs.com/guide: a leading slash replaces the whole path. So
`site` ends in a slash and the route is joined relatively, in both places that
build a URL, with a test on each.
@astrojs/sitemap was added for this and is now removed. It joins with a leading
slash internally, so it emitted weekndlabs.com/guide/ and a sitemap index at
weekndlabs.com/sitemap-0.xml, neither of which exists. Astro's `base` would fix
the join and break the subdomain, where /design/_astro/… is a 404. Three URLs did
not justify configuring around that, so src/pages/sitemap.xml.js emits them and
reads the routes from the pages directory, so a new page is never forgotten.
One thing this cannot finish: robots.txt is read from an origin root, never from a
path, so Google reads weekndlabs.com/robots.txt for the canonical host and that
file lives in the main site's repo. The Sitemap directive has to be added there
too, or the sitemap submitted in Search Console. The comment in
docs/public/robots.txt says so.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Settles the question #28 deliberately left open. The proxy path wins: every
inbound link and every internal link already pointed there, and one domain is
easier to grow than two.
BREAKING for anything reading the canonical. It was
design.weekndlabs.comand isnow
weekndlabs.com/design.What changed
sitehttps://design.weekndlabs.comhttps://weekndlabs.com/design/design.weekndlabs.com/guide/weekndlabs.com/design/guide/@astrojs/sitemapsrc/pages/sitemap.xml.jsThe subdomain stays fully crawlable. Disallowing it would stop Google reading the
canonical tag that does the deduplicating, which is the opposite of what blocking
a duplicate achieves. There is a comment in
robots.txtsaying so, because itlooks like an oversight otherwise.
The trap this ran into
An origin with a path does not survive the obvious join:
A leading slash replaces the entire path. So
siteends in a slash and the routeis joined relatively, in both places that build a URL. Each has its own assertion,
because the failure is silent: the build succeeds and every canonical points at a
page that does not exist.
Why @astrojs/sitemap was removed
It was added in #28 and lasted one commit. It joins routes with a leading slash
internally, so with the new
siteit emitted:Astro's
base: '/design'would fix the join and break everything else: this samebuild is also served at the subdomain root, where
/design/_astro/…is a 404.Three URLs did not justify configuring around that.
src/pages/sitemap.xml.jsemits them directly and reads the routes from the pages directory via
import.meta.glob, so adding a page adds it to the sitemap. One fewer dependencythan before #28.
What this cannot finish, and it matters
robots.txtis read from an origin root and never from a path. Google readsweekndlabs.com/robots.txtfor the canonical host, and that file belongs to themain site's repo, injected in part by Cloudflare. The
Sitemap:directive has tobe added there too, or the sitemap submitted in Search Console. Until then the
sitemap exists and is correct but is not discoverable from robots.txt.
The directive in
docs/public/robots.txtstill points at the right URL and onlyever answers at
design.weekndlabs.com/robots.txt, which is the non-canonicalhost. The comment in the file says all of this.
Verification
dist/reproducesweekndlabs.com/design/,/design/guide/,/design/components//designintact on eachcurl -s https://design.weekndlabs.com/sitemap.xmlshould list the three
weekndlabs.com/design/…URLs, and every page's canonicalshould match its own sitemap entry
Still not claimed
No Search Console data has been seen, so no page is known to be failing to index.
This fixes a structural defect found by measurement. It also fixes discovery, not
traffic; those remain separate problems.