2026 Complete Commerce Website Architecture Checklist

1. Product definition and evidence

A crawler and a buyer should identify the same product, company, outcome and next action.

One canonical product name and company entity appear on the homepage, schema and machine files.
The first server-rendered text explains what the product is, who it serves, what it delivers and how to buy.
Every public claim can be traced to a page, public URL, test or disclosed owner statement.
Internal deployments are labelled as internal cases rather than customer testimonials.
Unavailable providers or integrations are described as unavailable rather than simulated.

Identity connects orders, support, delivery and entitlements; it is not a decorative login screen.

Configured login methods share one internal user identity and documented verified fields.
OAuth provider availability follows verified callback and secret configuration.
Email codes are time-bounded, single-use and never exposed in logs or public evidence.
Password storage uses a modern slow password hash and recovery is separately verified.
Roles and privileged routes fail closed and are excluded from public indexing.

The browser presents choices; the server establishes order truth.

The server owns SKU, price, currency, quantity rules and expected amount.
One idempotent order reference survives checkout, payment provider, return, support and delivery.
A return page never marks an order paid without a trusted provider event.
Provider webhooks validate signature, timestamp, event ownership, currency and amount.
Refund, dispute and retry operations are idempotent and auditable.

A sale remains trustworthy only when support and delivery can follow the same customer context.

Robot answers identify when a case must reach an authorized human.
Support tickets retain the customer, order and category without exposing sensitive credentials.
Delivery state, notices and evidence use the same order reference.
Operators receive a runbook for retries, reconciliation, incidents and rollback.
Audit logs distinguish user action, provider event, system retry and operator override.

Canonical pages, structured data, machine files and crawler policy must describe one public entity.

Canonical, hreflang, Open Graph, sitemap and internal links use the same clean URL.
Structured data matches visible content and contains no fabricated reviews or ratings.
robots.txt allows legitimate public crawlers while private and transactional routes stay blocked.
llms.txt, product feeds and GEO manifests point to current canonical pages.
Crawler logs record user agent, requested URL, status and timestamp without sensitive payloads.

A release is complete only when the public path, machine path and operator path agree.

Desktop, mobile, keyboard, bilingual, overflow and console checks pass on the final artifact.
Every visible action navigates or opens a useful, truthful state.
Public pages return 200, legacy public URLs return 301 and private routes return authenticated/noindex or 404.
Sitemap and IndexNow notification are generated from the same canonical URL set.
The source, deployment version, evidence, owner and rollback path are registered.

These links define platform behavior or security guidance. They are sources, not endorsements of TC SiteOS.