Skip to content

🐛 Write sitemap entries as <url> - #15

Merged
taras merged 2 commits into
mainfrom
sitemap-url-element
Sep 26, 2026
Merged

taras merged 2 commits into
mainfrom
sitemap-url-element

Conversation

@taras

@taras taras commented Sep 26, 2026

Copy link
Copy Markdown
Member

Motivation

Closes #14.

The sitemap staticalize writes wraps every <loc> in <urls> rather than <url>, so it is invalid per the sitemaps.org schema — the deployed Effection sitemap hands crawlers 519 malformed entries.

It went unnoticed because our own reader accepts either spelling (xml.urlset.url ?? xml.urlset.urls), so a site staticalized twice round-trips its own invalid output.

Approach

The entry key passed to stringify in staticalize.ts is now url.

The reader keeps accepting urls — sitemaps that earlier versions already deployed should stay crawlable by staticalize itself.

The test asserted the malformed spelling (xml.urlset.urls), which is what let this ship; it now reads xml.urlset.url and also asserts the raw body contains no <urls>.

Separate first commit: the test server bound Deno's default port 8000, so the whole suite failed with AddrInUse whenever anything else on the machine was listening there. It now passes port: 0 and takes the port the OS hands back.

The suite bound deno's default port 8000, so it failed with `AddrInUse`
whenever anything else on the machine was already listening there.
The sitemap writer passed `urls` as the entry key, so every generated
sitemap wrapped its `<loc>` in `<urls>` and was invalid per
https://www.sitemaps.org/protocol.html. It went unnoticed because our own
reader accepts either spelling, so a site staticalized twice round-trips
its own invalid output.

The reader keeps accepting `urls` so sitemaps already deployed by earlier
versions can still be crawled.

Closes #14

@cowboyd cowboyd left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will this require fixes of our current deployments?

@taras

taras commented Sep 26, 2026

Copy link
Copy Markdown
Member Author

@cowboyd yes, I think so

@taras
taras merged commit c6c20dd into main Sep 26, 2026
1 check passed
@taras
taras deleted the sitemap-url-element branch September 26, 2026 13:39
taras added a commit to thefrontside/frontside.com that referenced this pull request Sep 30, 2026
Every sitemap this site has deployed wraps each `<loc>` in `<urls>` rather
than `<url>`, which is not the sitemaps.org schema. Crawlers are handed a
document whose entries they have no reason to understand.

It went unnoticed because staticalize's own reader accepts either spelling,
so a site staticalized twice round-trips its own invalid output.
thefrontside/staticalize#15 fixes the writer; 0.3.0 was the first release
with it, and 0.3.1 adds the fixes that came out of adopting it.

The task takes staticalize from npm rather than jsr. Deno's minimum
dependency age refuses a jsr version for its first 24 hours, which would
block the task on the day of every staticalize release; npm resolution is
not subject to it. The package publishes a `bin` rather than a `/cli`
export, so the specifier loses its subpath, and the jsr entry the lockfile
was carrying for it goes away with nothing referencing it.

0.3.1 restored the default for `--retries`, so the task does not need to
pass it. The workflow keeps its explicit `--concurrency=25` and
`--retries=5`, which predate all of this.

This site is the one the others name as canonical, so it needs no
`--canonical` of its own.
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.

Generated sitemap uses <urls> instead of <url>

2 participants