SEO Requirements for a Custom CMS: Technical Checklist for Developers

If you are building a custom CMS, SEO should be a product requirement—not a plugin added after launch. The CMS needs to give editors and developers safe control over canonical URLs, metadata, indexability, redirects, sitemaps, structured data and internal linking while preserving valid HTTP behavior and crawlable rendered content.

This checklist is designed for engineering teams defining requirements before a custom build or CMS migration. For implementation support, see SEO for custom CMS platforms.

1. Every public content item needs a stable URL

Each indexable page should have one stable, crawlable URL that does not depend on a session, fragment or temporary application state.

The CMS should:

• generate human-readable slugs;
• prevent accidental duplicate slugs;
• support nested routes only where the information architecture requires them;
• preserve historical URL mappings when a slug changes;
• return a real 404 for content that does not exist.

A custom CMS should never silently convert a missing article into a 200-status “not found” screen.

2. Slug changes must create a redirect record

When an editor changes a live URL, the system should remember the old URL and create a server-side permanent redirect to the new canonical URL.

Minimum redirect registry fields:

• old path;
• new path;
• HTTP status (normally 301/308 for a permanent move);
• content ID;
• created date;
• reason/source;
• active/inactive state.

The system should also detect loops and chains before saving a new rule.

3. Editors need first-class SEO metadata controls

At page/post level, support:

• SEO title;
• meta description;
• canonical URL override where genuinely needed;
• robots directives;
• Open Graph title, description and image;
• Twitter/X card metadata;
• primary image alt text and caption.

Default values should be sensible so a page is not broken when an editor leaves optional fields blank. But important pages should still be able to override defaults intentionally.

4. Separate publish status from indexability

A CMS should not assume that every published page is indexable or every draft is simply hidden.

Define explicit states such as:

• draft/private: not publicly accessible;
• preview: protected or noindex;
• published + indexable;
• published + noindex;
• archived/redirected;
• deleted: 404/410 according to the product rule.

This prevents common release mistakes such as staging noindex directives leaking into production or old pages remaining accessible with conflicting canonicals.

5. Canonical URLs should be generated centrally

Do not let every template invent its own canonical logic. The CMS or application layer should derive the preferred canonical from the route and content model.

Validate consistency across:

• rel="canonical";
• Open Graph URL;
• XML sitemap;
• internal links;
• redirect destination;
• structured data URL properties.

6. XML sitemaps should update automatically

The CMS should generate a sitemap from the actual set of public canonical URLs—not from a manually maintained list.

For each entry, support:

• canonical URL;
• meaningful lastmod when the public content changes;
• image references where appropriate;
• segmentation into sitemap indexes when the site grows beyond practical file limits.

Drafts, utility routes, login pages, noindex pages and redirected URLs should not appear in the sitemap.

7. robots.txt and noindex controls must do different jobs

Use robots.txt to control crawling, not to guarantee removal from the index. Use noindex when a publicly crawlable page should not be indexed. Use authentication when content should not be public at all.

The CMS admin should make these states difficult to misconfigure.

8. Render critical content in crawlable HTML

Google can render JavaScript, but a custom application should not make essential SEO depend on fragile client-side execution.

Prefer server-rendered, statically rendered or hydrated output for:

• page title and metadata;
• primary content;
• headings;
• navigation;
• internal links;
• canonical and robots directives;
• structured data.

Google describes dynamic rendering as a workaround rather than a long-term solution. Server-side or static rendering also improves compatibility with other crawlers that may not execute JavaScript.

9. Internal links should be real links

The CMS component library should generate normal <a href> links for navigation and editorial links. Avoid click handlers that behave like links without an href.

Editors should be able to search for and link to internal content by title, while the CMS stores the content relationship rather than a fragile hard-coded URL where practical.

That makes it possible to update links automatically after slug changes.

10. Structured data should be template-aware

Structured data belongs in the application/template layer, with editor-controlled fields only where human input is needed.

Examples:

• Organization/WebSite globally;
• BreadcrumbList from route hierarchy;
• Article for editorial posts;
• LocalBusiness only for real business locations;
• Product where the page is genuinely a product page.

Google’s guidelines require structured data to match visible content. Do not create a generic schema “builder” that encourages editors to mark up information the user cannot see.

11. Media needs an SEO-aware asset pipeline

For uploaded images, store:

• original file reference;
• optimized web variant;
• width and height;
• MIME type;
• alt text;
• caption/credit where needed;
• content relationships.

Automated WebP/AVIF conversion can reduce payload, but quality and dimensions should be adapted to the actual display context. The CMS should not turn every upload into an arbitrary fixed-size thumbnail.

12. Pagination, filters and facets need defined URL rules

Before shipping a listing system, decide which states deserve crawlable URLs. Infinite combinations of filters, sorting and parameters can create enormous crawl spaces.

Specify:

• which filters are indexable;
• which parameters are canonicalized or blocked from discovery;
• how pagination creates distinct URLs;
• how internal links expose paginated states;
• how ecommerce facets are controlled.

13. Internationalization needs URL and hreflang support

If multiple languages or markets are planned, make locale architecture a core CMS feature. Store relationships between equivalent content versions and generate hreflang centrally.

Do not attempt to infer alternates from titles or slugs after the fact.

14. SEO changes need validation and rollback

For high-impact fields—slug, canonical, robots status and redirects—record change history. The admin should show what changed, when and by whom.

For automated publishing systems, add pre-publish gates:

• slug collision check;
• canonical validation;
• required title/H1;
• status/indexability consistency;
• redirect-loop check;
• structured-data validation where applicable;
• internal-link sanity checks.

15. Connect publishing to discovery, but do not promise indexing

When a public page changes, the CMS can:

• refresh sitemap lastmod;
• regenerate sitemap files where needed;
• submit supported discovery notifications;
• log the publication event for QA.

Google makes clear that a sitemap helps discovery but does not guarantee indexing or ranking. The content still has to be useful, accessible and worth indexing.

16. Build AI-search readiness on top of the same foundation

You do not need a special “AI schema” field. AI-search readiness comes from clean public content, entity clarity, evidence, consistent organization data, crawlable architecture and useful pages.

For Google specifically, Search Console now includes controls and reporting for generative AI features. The CMS should make it easy to maintain accurate canonical/indexability signals so those features can reference the same stable content graph used by traditional Search.

If AI Search is a strategic channel, connect the CMS to an editorial workflow that can add source references, authorship, updated dates and supporting internal links.

Custom CMS SEO acceptance checklist

For teams planning a platform move, combine these requirements with our SEO migration checklist and web development capability.

Sources and further reading

• Google: SEO guide for web developers
• Google: JavaScript SEO basics
• Google: dynamic rendering is a workaround
• Google: canonicalization
• Google: structured data guidelines
• Google: crawlable links