Website Content Architecture Standard

Canonical internal record: SYS-077 v1.0.

Adoption: Effective only upon the publisher's attributable approval of this exact version. Core retains the controlling decision, identifier and version. Preparing a repository copy or public mirror does not adopt the standard or authorise publication.

Purpose

Give each website page a deliberate content home, stable address and understandable place in the reader's journey. Authors and publishing assistants must be able to decide these before drafting, rather than repairing inconsistent URLs and breadcrumbs after release.

Scope

This standard governs Digital Sanctum's public marketing and knowledge website: content classification, canonical routes, navigation relationships, breadcrumbs, article structure, metadata and discovery. Client websites may adopt it through their own commission. It does not change Sanctum application routes, internal Core KB naming, security permissions, editorial evidence requirements or publication authority.

The sitemap-planning process applies these rules when designing a hierarchy. The academic and journalistic article processes apply them when commissioning and releasing content. Core's article standard continues to govern internal KB records. The UX/UI standard governs presentation within its own recorded adoption scope; this document does not adopt a pending UX/UI proposal.

Content Types and Canonical Homes

Classify the page by its primary reader purpose. A source date or a link from the timeline does not alone determine its type.

Do not move an established evergreen article merely because its historical address contains /blog/. Record a legacy exception and assess any move separately. Existing benchmark archives likewise retain their commissioned addresses. The matrix is a decision rule for new content, not an instruction to rename every existing page.

The AI Timeline is a chronological discovery surface. It may link to evergreen guides, dated reports and external evidence without turning them into one content type. A Knowledge Hub route must not be invented as a breadcrumb link unless that destination actually exists and helps the reader. The current guide collection's AI Timeline parent is an explicit legacy arrangement, not a claim that the URL folders contain an /ai-timeline/ directory.

Addresses and Identity

• Give each page one canonical public URL. Use readable lowercase, hyphen-separated path segments and the site's established trailing-slash convention. Avoid changing slugs when only a headline changes.
• Keep a stable content identity separate from the title, short breadcrumb label, publication date and collection membership. A page can have several discovery links while retaining one canonical address.
• Record the primary content home and any topic parent explicitly. A child guide links back to the topic that owns its question; the topic links to its published children.
• Record a deliberate exception with its reason, owner, affected routes and review trigger. An exception does not authorise a new layout or release route.
• Distinguish publication, substantive update, source-check and template-change dates. A navigation correction does not refresh an incident's research date.

Breadcrumb Contract

Each in-scope article or standard has one understandable, server-rendered breadcrumb trail before its main heading. Begin with Home, include the actual parent journey, and end with a concise current-page label. The full heading remains visible and identifies the article precisely.

Use a navigation landmark labelled Breadcrumb and an ordered list. Parent items are normal keyboard-accessible links; the current item is plain text marked aria-current="page". Hide decorative separators from assistive technology. Allow wrapping on narrow screens rather than hiding the current label or forcing document-wide horizontal scrolling. Verify actual keyboard and small-screen behaviour; semantic markup alone does not establish accessibility conformance.

A breadcrumb represents a reader path and need not repeat URL folders. A contextual path different from the content home requires an explicit reason in the content record. For example, a dated security report can keep its /blog/ address and Insights listing while using the approved Home / AI Timeline / Security trail as a timeline companion. This is deliberate cross-collection navigation, not a second canonical page.

For new focused guides, prefer a short subject label that distinguishes siblings. Existing parent / Focused guide labels may remain as recorded legacy exceptions where the parent and full heading supply the missing specificity; do not silently treat them as the default for new work. Never copy a breadcrumb from an unrelated layout simply because it looks similar.

Where breadcrumb structured data is present, derive it from the same ordered items as the visible trail, with matching labels, destinations and positions. Structured data is optional unless the destination's requirements demand it; its presence does not guarantee a search feature.

Required Content Record

The publishing system must retain the following once, then derive route, navigation and discovery checks from it where supported:

Existing sources need not be rewritten into another CMS. A registry can reference an authoritative native or protected page. It must not duplicate that page's article body or weaken its independent publishing controls.

Article Structure

Use the established reading system: full heading, useful introduction, meaningful section headings, accessible body and figures, contents/progress enhancements where supported, and relevant next reading. Preserve readable core content without JavaScript. Reuse the canonical article layout for new articles; existing specialised layouts require named exceptions rather than uncontrolled copies.

• Reporting/explainers: answer the reader's question early; distinguish verified facts, interpretation, practical implications, uncertainty and commercial interest. Retain citations, as-of limits, accountable attribution and a correction path.
• Research: include the question, method, results, discussion, limitations, data/code availability and applicable conflicts/contributions. Follow the research process for evidence and review.
• Standards/processes: state purpose, scope, adoption/version, rules or procedure, enforcement/verification and maintenance. A public mirror identifies its canonical version and preserves substantive parity; public visibility does not establish adoption.
• Topic guides: own the broad question, explain boundaries and link to the focused guides. Focused guides solve one narrower question and link to the parent rather than repeating it in full.

Assess whether a table, diagram or other visual helps the reader. Choose purposeful visuals and accessible equivalents, or record why text is sufficient. Apply the existing contextual CTA guidance: an article's next step follows its reader purpose; this standard does not prescribe a sales CTA above the fold.

Discovery and Change Control

Before release, verify that intended collection, series and parent/child links resolve; canonical and social URL metadata agree; indexability, sitemap and search inclusion match the content's state. Drafts, previews and private evidence must not leak into public discovery. Do not count a timeline link as proof that an article appears in its canonical collection.

A URL change needs an old-to-new map, an appropriate permanent server redirect, updated internal/discovery links, canonical/social URLs, sitemap and search outputs, and live checks of old and new destinations. Do not leave two competing indexable copies or redirect an unrelated article to a generic hub. Retain the decision and recovery plan, then monitor the change through the commissioned window. A source merge alone proves no deployment or indexing outcome.

Changes to protected or independently managed pages must use their existing governed route or a separately accepted exact correction package. Identify every allowed changed output and retain the prior page. Navigation-only work must preserve the article body, evidence, byline, dates and claim qualifications; verify that boundary by comparing bytes or equivalent exact regions. Never relax protected-page validation merely to obtain a green build.

Enforcement Status

Adoption and implementation are separate. The Core decision establishes whether this version is adopted; the release receipt establishes which implementation is live. Each application records its actual enforcement coverage and retained exceptions. No general compliance claim follows from this standard's existence.

Automated checks should reject duplicate/invalid routes, absent required records for new in-scope content, missing parents, cycles, unexplained contextual trails, inconsistent visible/structured breadcrumbs and canonical/discovery drift. Human review still decides classification, meaningful labels, hierarchy, evidence quality and justified exceptions. Protected content remains subject to its own hash and release guards.

The initial implementation may cover the audited timeline collection and standards first. Record the exact route inventory and remaining coverage rather than implying a whole-site migration. A new article in an in-scope family must be registered or produce an explicit build failure; exemptions require a named, reviewable record.

Ownership and Maintenance

Digital Sanctum owns the standard. The accountable publisher records reviewers and the release/maintenance owner for each application. Search existing guidance before changing it; update overlapping rules and relate the canonical records rather than creating competing standards. Version substantive changes and preserve decisions and earlier evidence.

Review the content map when commissioning an article, adding a topic/series, changing its purpose or route, finding a broken parent, changing templates or receiving a reader correction. The release owner defines proportionate follow-up. This document schedules no automation and grants no publishing authority.

Reference Guidance

These external references inform implementation; the choices of content families and exceptions above are Digital Sanctum's proposed policy.

• Google: URL structure guidance.
• Google: breadcrumb guidance.
• Google: changing URLs.
• W3C WAI: breadcrumb pattern.

Examples on this website

These applications come from the current content map. Existing focused-guide labels are recorded legacy exceptions; the dated report keeps its canonical home and contextual timeline path. The examples sit outside the canonical Core body above.