v0.1.0-next.47

Three changes you will see in the output rather than in your config, and all of them are corrections rather than features. A split page stops sharing one title with all of its parts, a noindex you set in the seo namespace stops being ignored, and heading anchors stop turning page.translations into pagetranslations.

Nothing here needs a change on your end, and each of the three says what to look for.

Two more, further down. If you put a metadata tag below the <baseline-head> placeholder, it now lands inside the head in your built file rather than just in the browser's view of it. And if you declare two theme-color metas scoped by media query, you get both now instead of one.

Breaking

Heading anchors changed for headings containing punctuation or symbols.

A heading id is now slugified for reading rather than for filing. Dots, slashes and underscores become word boundaries instead of disappearing, and symbols are dropped rather than spelled out as words.

Heading	Was	Now
`page.translations`	`pagetranslations`	`page-translations`
`Add a schema.js file`	`add-a-schemajs-file`	`add-a-schema-js-file`
`The <head> placeholder`	`the-lessheadgreater-placeholder`	`the-head-placeholder`

Ordinary prose headings are unaffected, and so are accents and camelCase: Le fossé pédagogique still gives le-fosse-pedagogique, and inlineESbuild still gives inlineesbuild.

On the site this was found on, 28 of 634 headings changed, or 4.4%. Internal links and tables of contents follow automatically, because they read the same id. What does not follow is a link somebody else wrote to one of your anchors, or one you wrote by hand in a template.

Symptom: a deep link from outside that used to land on a heading now lands at the top of the page. Search your content for hand-written #fragment links if you have headings that name an API.
A split page's parts no longer share the first part's title.

A page split with  now qualifies each part's <title> and og:title with the part label, which leads so that truncation eats the tail rather than the label.

Previously every part carried page one's title verbatim. On the site this was found on, that was eighteen URLs with duplicate titles.
- Symptom: titles change in Search Console for any split page. This is the fix, not a regression, but it is the kind of thing that shows up there before it shows up in a changelog.

Fixed

seo.noindex is read. It was accepted by the page schema and looked at by nothing, so a page that set it was silently indexed anyway. Three readers honour it now: the robots meta tag, canonical suppression, and sitemap inclusion.

It resolves as seo.noindex ?? noindex, which also means a page can opt back in against a noindex: true it inherited from a directory data file.
- Symptom: pages you thought were excluded leave your sitemap and gain a robots directive on the next build. Worth a look at your sitemap diff if you use the key.
Later parts of a split page are in the sitemap. They were being written to disk and served while appearing in no sitemap at all. A part inherits lastmod, changefreq and priority structurally, because it is emitted in the same branch that decided page one was includable. Parts deliberately get no hreflang, since an alternate has to name the equivalent page and page one is not it.

On the site this was found on, that added eighteen URLs, 71 to 89.
A metadata tag below the placeholder now lands inside <head> in your built file.

Baseline documents an escape hatch: put a tag below <baseline-head>, as a sibling, and it reaches the output untouched by dedupe or sorting. Browsers fold such a tag back into the head, so the page has always rendered correctly. Your built HTML did not, and still showed the tag sitting outside </head>.

Baseline folds it now, in the same transform that builds the head. A base, link, meta, noscript, script, style, template or title element between the head and the body is appended to the head. Anything else stays exactly where you put it, because an element outside that list means the body has started.

Two things worth knowing. Folded tags are appended, so they land after everything Baseline composed, which is right for metadata and wrong for anything whose position carries meaning: a <style> block or an ordered script belongs in settings.head, which sorts. And this is cosmetic in the browser and real in the file: nothing renders differently, but your dist/ now matches the DOM, so output diffs stop showing phantom tags outside the head.
- Symptom: markup moves on every page that strands a tag, and nothing looks different in a browser. On the docs site that was 102 of 103 pages. If you diff built output as part of your release process, expect one large, boring diff.
Two theme-color metas that differ only by media query both survive. Declaring a light one and a dark one in settings.head.meta is the canonical use of the attribute, and one of them was being discarded before it reached the head module.

Baseline deduplicates head tags twice: once when your settings and your front matter are merged, and once in the head module itself. The second pass has treated media as part of a tag's identity for a while. The first did not, so it folded the pair into one and the fix in the pass below it never got the chance to run.
```
meta: [
    { name: 'theme-color', content: '#e8f7ff', media: '(prefers-color-scheme: light)' },
    { name: 'theme-color', content: '#1c2128', media: '(prefers-color-scheme: dark)' }
]
```
Tags carrying no media behave exactly as they always did, including collapsing to the last one when they genuinely repeat.
- Symptom: a second meta tag appears where one used to, on any page whose settings declare a media-scoped pair. If you gave up on scoped theme-color because it did not work, it works.
The relative-image warning covers every image URL you author, not just og:image. Baseline does not rewrite image URLs, because the JSON-LD graph sits inside a <script> that HtmlBasePlugin never walks, so a relative URL there ships exactly as you wrote it. The warning that says so was only looking at og:image.

It now also checks seo.twitterImage and your organisation's logo. The logo is the one that mattered: it goes straight into the graph, which is the very place the warning exists for.

Each message names the offending field, and still fires once per URL rather than once per page.
The same commit now builds the same bytes. The content graph walked pages in the order Eleventy's toJSON() handed them over, which is an order it does not promise. Node order, edge order, the backlink index and the hreflang sets all inherited it, so two builds of unchanged content could differ, and a change to anything near graph construction reshuffled output that had nothing to do with it.

Everything is now ordered: pages by URL, hreflang alternates by language. Verified across repeat builds, across a cleared cache, and across a configuration change that moves graph construction.

Two files still differ between builds and always will, because both record when they were made: the navigator's debug page and Pagefind's index entry. Neither is your content.
- Symptom: a one-off reorder. Pages that render a backlinks panel list their sources in a different order, and hreflang links are emitted alphabetically by language code. hreflang is an unordered set so nothing about it changes meaning. After this build, a diff of your output is worth trusting.
buildBacklinkIndex's JSDoc described the wrong parameters and a field the function never reads. No behaviour change.

Internal

applyPartLabel gained seven tests, and mutation-testing them turned up a dead type guard that the line below it already covered. Dropped.
Heading anchors moved to their own slugifier, core/utils/slugify-anchor.js, which wraps the identity one. Wikilink target slugs, page slugs and the organisation @id fragment are unchanged: for a key, deleting anything odd is the right behaviour, and that is what they still do.
The sitemap and head modules no longer register during the content-graph pre-pass, which renders only so the graph can extract from your page content and has no use for either. Output is byte-identical with and without, which is checkable now that the build is reproducible. No measurable build-time difference on this site, whose pre-pass is a small share of the whole; a site with a slow pre-pass may see more. The other three modules stay, because each registers something a template can reach.