# Pathrule Pattern: Technical SEO and Structured Data (1.0.0)
# ::pathrule:package:technical-seo-structured-data

### [RULE] Return a complete indexable response for public pages  (path: /src/pages)
<!-- scope: folder | priority: high | strict -->

A crawler or unfurl client may not execute the application like a long-lived browser session. An indexable URL that initially returns an empty shell, generic metadata, or an error hidden behind status 200 sends weak or misleading signals.

- Render the page's unique primary content and metadata in the initial response or a crawler-accessible server-rendered path.
- Return accurate HTTP status for missing, removed, redirected, unauthorized, and temporarily unavailable content instead of rendering every state as a successful page.
- Keep essential navigation and discovery links as real URLs in the document; do not require pointer events or client state to reveal every crawl path.
- Ensure robots directives, authentication gates, and bot protection do not block assets or content required to understand an intentionally public page.

See /src/seo for the adjacent decision or procedure that completes this constraint.

---

### [RULE] Emit one consistent canonical identity  (path: /src/seo)
<!-- scope: folder | priority: high | strict -->

Canonicalization is a cluster of signals, not a single tag. If the page redirects one way, links another, and names a third canonical, crawlers must guess which URL owns the content.

- Choose policy for scheme, host, path casing, trailing slash, default locale, and removable query parameters, then generate URLs from one canonical builder.
- Redirect permanent duplicates to the canonical URL where possible and make internal links point directly at it.
- Include only canonical, indexable URLs in sitemaps and update modification signals from meaningful content change rather than every build.
- Make locale alternates reciprocal and self-referential where used, and do not label machine-translated or unrelated pages as equivalent regional versions.

See /public for the adjacent decision or procedure that completes this constraint.

---

### [MEMORY] Structured data mirrors visible, attributable content  (path: /src/seo)

Structured data is not a place to add keywords or claims that are absent from the page. Divergence between visible content and machine markup makes maintenance harder and can invalidate enhanced-result eligibility.

- Choose the most specific supported type that describes the page's primary entity rather than attaching several unrelated top-level entities.
- Generate names, descriptions, authorship, dates, prices, availability, ratings, and breadcrumbs from the same authoritative data used in the rendered page.
- Use stable absolute identifiers and URLs and keep organization or product identity consistent across pages.
- Validate generated JSON syntax and semantic requirements on real routes, then monitor deployed pages because template-valid markup can still contain missing production data.

See /src/pages for the rule or workflow that puts this decision into practice.

---

### [MEMORY] Metadata is owned by the route's primary entity  (path: /src/pages)

A global template cannot express every page, while arbitrary component-level mutation creates duplicate or race-prone tags. The route that resolves the primary entity has the information and lifecycle to own metadata.

- Compose a concise unique title and description from authoritative fields and fall back to a truthful section-level page, never empty strings or copied placeholder text.
- Use one metadata owner so nested components cannot emit competing canonical, robots, or social tags.
- Keep social image, title, description, and canonical URL aligned with the page users reach when the preview is opened.
- Exclude search, filter, preview, error, and private states from indexing according to product policy instead of letting generic metadata make them look canonical.

See /src/seo for the rule or workflow that puts this decision into practice.