**Goal:** As a site editor on any SummerCMS application, I want search-engine optimisation built into the CMS, going further than WinterCMS, so that every site ships correct, editable SEO without per-site work. This covers:
-an SEO tab on every content record and a global SEO settings screen;
-title, meta description, canonical and meta robots fields, Open Graph and Twitter Card tags;
-structured data per page type (article, home page, service pages; no e-commerce yet);
-a pagination mechanism;
- the XML sitemap extended, plus a default HTML sitemap linked from the home page;
-301/302 redirects and robots.txt, both editable in the admin;
- a correct heading hierarchy (one H1, then nested H2/H3);
- basic hreflang;
- a noindex policy for filter pages, login and signed-in user pages;
- a server-side rendering guarantee for the headless frontends, so that Googlebot sees all content and links.
**Goal:** As a site editor on any SummerCMS application, I want per-record and global SEO in the admin, with redirects and robots.txt, all manageable through MCP, so that every site ships correct, editable SEO without per-site work. The framework gains only generic seams; the SEO code lives in a new shared plugin. This covers:
-three framework seams that name nothing SEO-specific: cross-plugin admin form extensions with `Before`/`After` field and tab placement, cabana record events, signpost content descriptors;
-`sm-seo-plugin` (Golem15.SEO): the SEO tab on registered content types, global SEO settings with per-type templates, per-URL rules;
-title, meta description, canonical, meta robots and `X-Robots-Tag`, Open Graph and Twitter Card;
-301/302/410 redirects, the 404 log, URL normalisation and strict URLs;
- the robots.txt editor, AI bot switches, verification files;
-MCP tools for all of it, with batch dry-run, CSV import/export and history with undo.
**Repos:**`summercms.go` (framework SEO seam and admin), `sm-journal-plugin`, `sm-sitemap-plugin`, a new shared plugin where the discussion decides (redirects, robots.txt, global SEO), `vue-journal-layer` and the other Nuxt layers; scope fixed in discuss-phase
**Repos:**`summercms.go` (pact, cabana, signpost seams; framework release tag at the end), new `sm-seo-plugin`, `sm-journal-plugin` (signpost descriptors), the apps that mount the plugin
**Requirements**: TBD
**Success Criteria** (what must be TRUE):
1.To be fixed in `/msd-discuss-phase 32`.
2.The new code has unit tests, delivered in the phase's last plan.
1.A plugin can add a field between two fields of another plugin's admin form (A, B plus C after A renders A, C, B), and add a tab between two existing tabs; unknown anchors, duplicate names and anchor cycles stop the boot with a clear error.
2.Journal posts, categories and tags show the SEO tab without importing `sm-seo-plugin`, and the frontend gets the effective SEO of any URL with the precedence URL rule > record > global > derived.
3. Changing a record's slug creates a 301 and flattens existing chains; redirect loops are refused from the admin, MCP and imports.
4. Every SEO operation in the admin is available as an MCP tool, and a batch change can be previewed with dry-run and undone from history.
5. The framework release with the seams is tagged, and the new code has unit tests, delivered in the phase's last plan.
**Plans:** 0 plans
Plans:
- [ ] TBD (run /msd-plan-phase 32 to break down)
### Phase 33: SEO output, audit and content
**Goal:** As a site editor and as an SEO specialist auditing a SummerCMS site, I want the rendered sites to emit complete SEO output (sitemaps, structured data, pagination, hreflang, headings, breadcrumbs) from the CMS, and an audit that finds the remaining problems, so that sites are indexed correctly and issues can be fixed through MCP. Decisions are in `.planning/phases/32-seo-foundation/32-CONTEXT.md`. This covers:
- the `sm-sitemap-plugin` rewrite to a sitemap index split by type (breaking, D-32), image/News/IndexNow options, the HTML sitemap;
- the page registry in `sm-seo-plugin`;
- JSON-LD `@graph` per page type, pagination, hreflang in head and sitemaps;
- heading rules (no H1 in content), breadcrumbs;
- a shared Nuxt SEO layer, with the SSR build guard and the layers and apps moved onto it;
- the crawler and issue report;
- internal linking, auto-links and the orphan report;
- media SEO (alt, file names, formats).
**Mode:** mvp
**Planning:** exception to the lean-planning rule approved by Jakub on 2026-10-25: about 12–15 smaller plans instead of a few large ones.
**Depends on:** Phase 32
**Repos:**`sm-sitemap-plugin`, `sm-seo-plugin`, `sm-journal-plugin`, `sm-faq-plugin`, the Nuxt layers (new SEO layer, journal, menu, FAQ), the apps (grzybyfunkcjonalne migrates its sitemap in the same delivery)
**Requirements**: TBD
**Success Criteria** (what must be TRUE):
1. Every site serves a sitemap index with per-type files of a configurable size, stable numbering and real `lastmod`, consistent with noindex and robots.txt, and grzybyfunkcjonalne.pl runs on the new format.
2. Indexable pages render server-side with head tags, one JSON-LD `@graph`, hreflang and breadcrumbs from the CMS, and a build fails when an indexable route has `ssr: false`.
3. The crawler reports SEO issues per URL, and each issue can be fixed through MCP.
4. The new code has unit tests, delivered in the phase's last plan.
- Phase 32 added: Console commands overhaul: diary logging module, bonfire global flags and Artisan-grade help, sweep of all commands, tests
- Phase 19.6.1 inserted after Phase 19.6: Backend Administrators screen: admins and roles CRUD in cabana (gap found while planning 19.7: no screen to manage backend users or set the frontend link) (URGENT)
- Phase 32 added: SEO foundation: per-record and global SEO, structured data per page type, sitemap boost and HTML sitemap, pagination, redirects, robots.txt, canonical, meta robots, social tags, headings, hreflang, noindex policy, SSR for headless frontends
- Phase 32 edited: narrowed to framework seams and sm-seo-plugin core (split decided 2026-10-25)
- Phase 33 added: SEO output, audit and content; large phase, lean-planning exception
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
