- the module registers seo-sitemap-<locale> at seo.htmlSitemap.paths
(defaults pl /mapa-strony, en /sitemap) and seo-sitemap-group-<locale>
at <path>/:group (plus <path>/:group/<segment>/:page in the path form);
a path an app page already has stays the app's
- SeoHtmlSitemapPage (global, overridable): H1, an H2 per non-empty
group, categories nested, a large group's link to its group page,
sitemap.empty; group pages with a built trail, page suffix and
<SeoPagination>; 404 for an unknown group or a page past the last,
301 for ?page=1, 503 when the sitemap API fails
- GET /api/__seo__/sitemap proxies the sitemap plugin's HTML API (only
while the CMS has the HTML sitemap on for the locale)
- <SeoSitemapLink>: the footer link while the HTML sitemap is on
- L3 default styles
- <SeoPagination> (UI-SPEC L2): previous and next (left out at the
ends), page 1, the last page and five pages around the current one with
gap items; nothing when last <= 1; props current, last, labels,
classPrefix, locale
- usePagination(): hrefs in the CMS form (resolve answer, then site
answer, then seo.pagination), other query parameters kept, page 1
unnumbered, <link rel=prev/next> in the head
- the CMS head fills %pages% in the title and description once the
listing's page count is known (seoFillPages)
- seoPaginationWindow, seoPageHref, seoPageNumber; L2 default styles
- the module writes #seo-routes (static paths and route patterns) from the
resolved pages; options seo.routeReport, seo.pagination and
seo.htmlSitemap reach the public runtime config
- seo-route-report: POST /registry/routes once per process with the
route-report token, one retry after 60 s on failure, nothing without a
token, with the layer off or with routeReport false
- seo-drift: one "[vue-seo-layer] drift:" warning per mismatch between
the CMS's site answer (URL patterns, pagination, HTML sitemap paths)
and the build
- GET /api/__seo__/site and useSeoSite()
- smoke grammar routereport and log, fixture registry route, drift run
- server/middleware/seo-root.ts proxies /robots.txt, /sitemap.xml,
/sitemap-<name>.xml, /llms.txt and the verification and IndexNow key
files the site answer lists in root_files, with the backend's status,
content type and X-Robots-Tag; a backend failure is 503 Retry-After 60
- server/lib/site.ts caches GET /_seo/api/v1/site (300 s, cleared by the
purge); a backend without it (404) keeps the v0.1.1 behaviour: no root
proxies, the verification lookup by name
- the 404 report and the verification lookup honour seo.cms and rootFiles
- smoke runs for the layer off (seo.cms and the v0.1.1 enabled switch), the
CMS down (fail open) and no 404 token; npm run purge:check
- the Nitro middleware answers redirect (301/302, Location from the answer
only, same-site targets as paths as in v0.1.1) and gone (410) before the
render and the route cache, sets X-Robots-Tag, and answers 404 for a
pagination.invalid answer; other not_found answers stay with Nuxt
- resolve answers cached in an LRU (seo.resolveCacheTtl, default 60 s,
1000 entries) with in-flight de-duplication; a clear detaches loads in
flight so no answer fetched before a purge is stored after it
- the playground route-caches /blog/** (swr 300)
- Nitro middleware resolves page requests once and hands the answer to the
render (event.context.seo); the route middleware reuses it
- useCmsSeo: html lang, hreflang links, og:locale and exactly one JSON-LD
script with one @graph (CMS nodes plus useSchemaNode nodes, merged by @id)
- local module (configKey seo): cms (alias of public.seo.enabled),
breadcrumbs, links.newTabHint, rootFiles, resolveFiles
- GET /api/__seo__/resolve for client navigation through the Nuxt server
- smoke harness: count=, exact header=, noheader=, reqheader=, repeated
options, resolves/apicalls/noreport lines, --no-site; v0.1.1 suite runs
unchanged against a backend without /site
