How legal policy pages are published
Legal policy pages are published from markdown files stored in the repository. Each document in the legal system gets a public, crawlable page at /legal/:slug and an optional script embed at /legal/:slug.js. YAML frontmatter in the markdown file controls whether the page is visible, when it was last updated, and whether it carries a legal-review banner.
Currently published pages
The legal system serves the Cookie Policy and the Sub-processors list. Both carry the under-review banner described below.
Document | Standalone URL | Status |
|---|---|---|
Cookie Policy |
| under_legal_review |
Sub-processors |
| under_legal_review |
Privacy policy and terms of service
Our Privacy Policy and Terms are served from the marketing site at eventuallyticketing.com/privacy-policy and eventuallyticketing.com/terms-conditions. Those are the canonical customer-facing links. Neither document is served through the legal system, so /legal/privacy-policy and /legal/terms-of-service return 404.
Frontmatter fields
Each markdown file starts with YAML frontmatter. The following fields are recognized:
slug— the URL slug, limited to lowercase letters, numbers, and hyphens.title— the page title shown in the browser tab and the page header.last_updated— the date the content was last materially changed.last_reviewed— the date the content was last reviewed by legal.status—publishedorunder_legal_review. Anything else, including missing frontmatter, is treated asdraftand returns 404.
Under-review banner
When a document’s status is under_legal_review, the standalone page and the embed both show a banner with this exact text:
This document is currently under legal review and may change.
Canonical pages and embeds
Every standalone page includes a canonical link pointing to its own URL. The embed script also includes a link labeled Standalone version of this page that points back to the canonical URL. This lets visitors and search engines know which URL to share and index.
Sub-processors drift guard
The public sub-processors page must stay in sync with the internal vendor inventory. A continuous-integration test compares every vendor listed in VENDORS.md against the entries in docs/legal/subprocessors.md. If a vendor is missing from the public page, the build fails. The check is one-directional: it enforces that the internal inventory is reflected in the public doc, but it does not fail if the public doc lists extra vendors.
Standalone pages and embeds are cached publicly for five minutes. Unpublished or unknown slugs return 404 and are cached for one minute.
Related articles
For step-by-step embed instructions, see Embed a legal policy page on your Squarespace site. For a quick lookup of URLs and statuses, see Legal policy page reference. For more on public page indexing, see Public event page indexing and SEO.