Magnolia ships a powerful content repository, but no SEO layer. Every project rebuilds the same five things by hand: metadata fields that differ per template and are missing entirely on content-app items, a sitemap that goes stale or silently skips the thousands of URLs a detail template renders through a selector, a robots.txt that needs a deployment to change one line, a redirect layer living outside the CMS where the content team cannot see or audit it, and nothing at all for AI search - even though ChatGPT, Claude, Perplexity and Gemini now read llms.txt to decide how to cite a site. Headless doubles the work, because the same data has to be served as JSON and as a rendered file, and the day the two drift apart nobody notices. Multi-brand and multilingual sites get it worst: each brand needs its own set of everything, and one wrong language prefix produces duplicate content across every channel at once. 

H1 SEO Pack replaces all of that with one installable module. Both delivery channels come from the same service - JSON under /.rest/v1/seo/* for a decoupled - headless front end, and the standard artifacts (/sitemap.xml, /robots.txt, /llms.txt) rendered by Magnolia - so they cannot disagree. Every feature can be scoped to a brand subtree, giving each brand its own metadata, sitemap, robots file, llms.txt and redirect set on a single instance. Language prefixes and hreflang are handled centrally instead of in every template. Authors do the day-to-day work themselves, in the page dialog, in the content app and in the Redirects app: no ticket, no deployment, no restart. Nothing is mandatory - every empty field falls back sensibly, so the module adds value on an existing site before any content work happens. 

It is one JAR that installs itself on first start, bundling five independent features as five light modules, so they can be adopted one at a time. Metadata arrives as a reusable field include you decorate your own dialogs and content apps with; the values persist as flat, prefixed properties on the node, and one service serves both pages and content items in any workspace. The sitemap, robots and llms pages are created by an author, and where the page lives is what defines its scope. Redirects live in their own JCR workspace, cached with a short TTL and invalidated by JCR observation. Five MCP tools let an AI assistant read and write SEO metadata, inspect the generated files and manage redirects.

Most important features: 

1. SEO and GEO metadata as a reusable field set, for pages and for content-app items alike: title, description, summary, indexing flags, Open Graph card, Schema.org type, topics, FAQ and a raw JSON-LD override, per language, with canonical URL, og tags, dates and publisher block derived automatically. 
2. A sitemap that expands dynamic collections: auto-generated from published pages, with per-page exclusion, priority and change frequency - and one entry per item for detail templates, so a catalog of thousands of URLs stays indexed with nothing to maintain. 
3. Auto-generated llms.txt for AI search (GEO): a curated, readable index of the site for AI assistants, built entirely from metadata the team already entered and honouring the same no-index decisions as search engines. Very few platforms offer this today. 
4. A managed redirect engine: exact, prefix and regex rules with 301/302, precedence computed rather than configured (no priority field to get wrong), resolved identically on the server-rendered and headless channels, with CSV bulk import and export and a per-row error report instead of an all-or-nothing failure. 

5. Author-editable robots.txt with the Sitemap line appended automatically, using the correct scheme, host and context path.