Context
The platform separates public content from private editorial management. An entity can be published while its route, metadata and incoming links still need to change together.
The constraint
Changing a slug in isolation can leave metadata pointing at the wrong entity or old links ending at a missing page. Draft content must remain excluded from public reads and the sitemap.
The approach
The backend owns the canonical move. It validates the content identity and target route, updates the mapped entity and SEO record in a transaction, and installs a permanent redirect. Public readers check publication state before returning content.
Architecture
- 01Private CMS editor
- 02Authenticated API and permission checks
- 03Transactional identity + SEO move
- 04Permanent redirect resolution
- 05Server-rendered public page
Decisions and tradeoffs
A published slug is read-only in the normal CMS editor. The dedicated move operation requires both SEO write and content publication permissions.
Incoming redirect paths are flattened to the new target. Validation rejects loops rather than leaving them for the browser to discover.
Implementation
The implementation is in the backend CMS, SEO and redirect modules, with dashboard controls consuming those endpoints.
Evidence and outcomes
The local integration suite verifies publication visibility, route moves, redirects and exclusion of archived content. This describes verified behavior, not a claim of production SEO growth.
Stack
NestJS
PostgreSQL
Prisma
Next.js