How to Build Multiple Static Websites with One Codex Prompt

Public field comparison

How to Build Multiple Static Websites with One Codex Prompt

How to Build Multiple Static Websites with One Codex Prompt

Use one reusable Codex prompt to build a lightweight static website system for multiple domains, with unique landing pages, domain-specific content, SEO-friendly metadata, contact buttons, robots.txt, safe fallback pages, and simple deployment through Cloudflare Workers.

A Codex coding prompt for proposing and, when authorized, implementing one metadata-driven static site system that serves distinct sale, ecosystem, active-destination, and fallback pages by hostname. It includes Cloudflare Workers controls, domain-inventory reconciliation, SEO checks, active-domain safeguards, and evidence-based reporting without assuming deployment or provider access.

Building multiple static websites or domain landing pages from one reusable codebase using a single Codex prompt.

Build or safely update a single-codebase, multi-domain static website system in Codex while protecting active domains, keeping public metadata free of secrets, and requiring evidence for implementation and verification claims.

Building one static website system for many domains
Creating SEO-friendly landing pages for parked or premium domains
Managing a domain portfolio without creating separate projects for each domain
Building Cloudflare Workers static sites with custom domain routing
Creating domain-specific pages with unique copy and metadata
Protecting active production domains from being overwritten
Adding robots.txt
canonical URLs and basic technical SEO to static sites
Helping founders and domain investors launch many simple websites quickly

Building one metadata-driven static website codebase for multiple approved domains
Creating distinct sale landers and ecosystem pages with host-specific content and SEO metadata
Implementing or updating hostname routing in an existing Cloudflare Workers static-site repository
Protecting active product domains from sale language and unauthorized route changes
Reconciling a domain portfolio against routing metadata and verification tests
Preparing evidence-based local changes and a human-approved deployment handoff

COMPANY_NAME
PUBLIC_ENTITY_NAME
PRIMARY_BRAND_NAME
PRIMARY_WEBSITE_URL
CONTACT_EMAIL
PROJECT_NAME
DEPLOYMENT_PLATFORM
STATIC_ASSETS_DIRECTORY
DOMAIN_METADATA_FILE
DOMAIN_LIST
SALE_DOMAINS
ACTIVE_DOMAINS
ECOSYSTEM_DOMAINS
BRAND_LINKS
MAIN_CTA_TEXT
SECONDARY_CTA_TEXT
DESIGN_STYLE
SEO_REQUIREMENTS
TECHNICAL_CONSTRAINTS
DEFINITION_OF_DONE

Repository context
Domain inventory
Public identity
Brand links
Deployment settings
Approval boundaries
Acceptance criteria

1. Open Codex or your preferred AI coding agent inside the repository where you want to build the multi-domain static website system.
2. Replace the placeholders with your real company name, contact email, domain list, active domains, sale domains, and brand links.
3. Be very clear about which domains are for sale, which are active products, and which are ecosystem or personal pages.
4. Run the prompt and allow Codex to inspect the existing file structure before editing.
5. Review the changed files, especially the metadata file, robots.txt, deployment config, and README.
6. Deploy the project to Cloudflare Workers or your chosen static hosting platform.
7. Add your custom domains to the Worker or hosting project.
8. Test each domain in the browser.
9. Check that sale pages show a purchase CTA, active pages do not show sale language, and unknown domains use a safe fallback page.
10. Add future domains by editing the metadata file instead of creating a new website from scratch.

Open Codex in the target repository. Replace every variable in the prompt with the requested repository context, authoritative domain inventory, approved public content, hosting configuration, action boundaries, and acceptance evidence. Include relevant source files or permit Codex to inspect the workspace; provide sanitized Wrangler or hosting configuration, existing tests, and approved domain records without credentials. Run the prompt, review the inspection and change plan, approve only the intended local edits, then evaluate the patch and verification matrix before any separate human-controlled deployment, DNS, route, or custom-domain action.

A founder owns 25 unused domains and wants to show a different static landing page on each one. Some domains are available for purchase, one domain points to an active product, and another domain should be a personal founder page. Instead of creating 25 different websites, the founder uses this prompt in Codex to build one Cloudflare Workers project with a shared layout, a domain metadata file, SEO-friendly page content, contact buttons, robots.txt, and safe fallback handling. After deployment, each custom domain shows the correct page based on its hostname.

A founder has 25 domains and an existing Cloudflare Workers repository. Twelve domains are approved sale landers, three are ecosystem pages, eight must remain on active products, and two are not ready for publication. The founder supplies Codex with the repository, a reconciled domain inventory, approved public copy and links, current Wrangler configuration, and authority limited to local edits and tests. Codex is asked to inspect the project, propose and implement a metadata-driven hostname router, prove that active and ecosystem hosts never show sale CTAs, test an unknown-host fallback, document unresolved provider checks, and prepare—but not execute—a deployment handoff.

Expert

Expert

Codex

Codex

coding

coding

codex
cloudflare-workers
static-sites
multiple-websites
domain-landers
domain-parking
landing-pages
html-css
javascript
seo
robots-txt
custom-domains
metadata-driven-sites
web-development
automation

codex
cloudflare-workers
static-sites
domain-landers
custom-domains
metadata-driven-sites
technical-seo
web-security

How to Build Multiple Static Websites with One Codex Prompt

Build Multi-Domain Static Sites with One Codex Prompt

Copy this Codex prompt to build a reusable static website system for multiple domains, with domain-specific landing pages, SEO metadata, robots.txt, contact CTAs, active-domain protection, and Cloudflare Workers deployment.

Use Codex to build and verify one secure, SEO-aware static site system for many domains with Cloudflare Workers and active-domain safeguards.

Prompt-body line comparison

Removed Added Unchanged context

−Act as an expert full-stack engineer, Cloudflare Workers specialist, static-site architect, SEO-aware frontend developer, and technical product builder.
−
−I want you to build a reusable static website system that can serve multiple domains from one codebase. Each domain should show the correct page based on the hostname. The goal is to avoid creating separate projects, separate repositories, or separate websites for every domain.
−
−Context
−
−I own multiple domains and want one lightweight static site system that can serve different domain landing pages from a shared codebase.
−
−Some domains should show public landing pages. Some domains may be available for purchase. Some domains may belong to an existing product or active destination and must not be replaced. Some domains may be ecosystem or personal-brand pages rather than sale pages.
−
−Use the details below as the source of truth:
−
−Company or owner name: [COMPANY_NAME]
−Primary website: [PRIMARY_WEBSITE_URL]
−Contact email: [CONTACT_EMAIL]
−Deployment platform: [DEPLOYMENT_PLATFORM]
−Project or Worker name: [PROJECT_NAME]
−Static assets directory: [STATIC_ASSETS_DIRECTORY]
−Domain metadata file: [DOMAIN_METADATA_FILE]
−Domain list: [DOMAIN_LIST]
−Sale domains: [SALE_DOMAINS]
−Active domains: [ACTIVE_DOMAINS]
−Ecosystem or personal domains: [ECOSYSTEM_DOMAINS]
−Brand links: [BRAND_LINKS]
−Public entity name for footer: [PUBLIC_ENTITY_NAME]
−Main CTA wording: [MAIN_CTA_TEXT]
−Secondary CTA wording: [SECONDARY_CTA_TEXT]
−Design style: [DESIGN_STYLE]
−SEO requirements: [SEO_REQUIREMENTS]
−Technical constraints: [TECHNICAL_CONSTRAINTS]
−Definition of done: [DEFINITION_OF_DONE]
−
−Important constraints
−
−1. Keep the project lightweight.
−2. Do not add a database.
−3. Do not add a CMS.
−4. Do not add authentication.
−5. Do not add an admin panel.
−6. Do not add a backend framework unless the existing project already uses one and it is required.
−7. Do not create separate repositories or separate codebases for each domain.
−8. Do not hardcode one page per domain if a clean metadata-driven approach can be used.
−9. Do not overwrite or replace active production domains.
−10. Do not expose private account details, private emails, internal notes, credentials, API keys, or deployment secrets.
−11. Do not use placeholder filler text on final public pages.
−12. Do not allow all domains to show the same generic copy.
−13. Do not repeat the same paragraph word-for-word in multiple visible sections of the same page.
−14. Do not create unnecessary build complexity.
−15. Do not break existing deployment configuration.
−16. Do not remove existing working files unless there is a clear reason and you explain it.
−17. All external links should open in a new tab using target="_blank" and rel="noopener noreferrer".
−18. The footer should show only the public entity name provided in [PUBLIC_ENTITY_NAME].
−19. Active domains must show a safe notice or redirect-style CTA only if they accidentally hit this lander.
−20. Unknown domains must show a safe fallback page that does not damage the brand.
−
−Task
−
−Build or update the project so it can serve multiple static domain landing pages from one codebase.
−
−The system should support these domain statuses:
−
−1. sale_lander
−   Use this for domains that may be available for purchase or acquisition.
−
−A sale lander should include:
−
−* Domain name
−* Clear acquisition or purchase availability line
−* Unique domain-specific description
−* Primary CTA that opens an email inquiry
−* Secondary CTA to the primary website
−* Possible use cases
−* A “Why [domain]?” section
−* A “Who it may suit” section
−* A “Brand angles” section
−* Footer with [PUBLIC_ENTITY_NAME]
−* Bottom navigation links from [BRAND_LINKS]
−
−2. ecosystem
−   Use this for personal, brand, founder, project, or ecosystem pages that should not be presented as domains for sale.
−
−An ecosystem page should include:
−
−* Page title
−* Short positioning statement
−* Highlights
−* CTAs to relevant brand destinations
−* Footer with [PUBLIC_ENTITY_NAME]
−* No “available for purchase” or sale language
−
−3. active
−   Use this for domains that already have an active product, production website, or external destination.
−
−An active domain should not be replaced by the lander.
−
−If an active domain is accidentally served by this project, show:
−
−* Active destination notice
−* Short explanation
−* CTA to continue to the real destination
−* No purchase CTA
−
−4. fallback
−   Use this for unknown domains not yet listed in the metadata.
−
−The fallback should:
−
−* Be safe and brand-neutral
−* Avoid making false claims
−* Include a contact CTA
−* Include a primary website CTA
−* Use generic but polished copy
−* Avoid exposing internal configuration
−
−Recommended structure
−
−Use this structure unless the existing project already has a better working equivalent:
−
−* wrangler.jsonc
−* public/index.html
−* public/styles.css
−* public/script.js
−* public/domains.json
−* public/robots.txt
−* public/favicon.svg
−* README.md
−
−If the project is not using Cloudflare Workers, adapt the same idea to the current static hosting platform. However, keep the solution simple and metadata-driven.
−
−Domain metadata
−
−Create or update a metadata file such as public/domains.json.
−
−Each domain entry should support:
−
−* status
−* title
−* description
−* body
−* useCases
−* buyerTypes
−* brandAngles
−* destination
−* highlights
−
−Example structure:
−
−{
−"defaults": {
−"entityName": "[PUBLIC_ENTITY_NAME]",
−"hubName": "[PRIMARY_BRAND_NAME]",
−"hubUrl": "[PRIMARY_WEBSITE_URL]",
−"contactEmail": "[CONTACT_EMAIL]",
−"links": [
−{ "label": "[LINK_LABEL_1]", "url": "[LINK_URL_1]" },
−{ "label": "[LINK_LABEL_2]", "url": "[LINK_URL_2]" }
−]
−},
−"domains": {
−"example.com": {
−"status": "sale_lander",
−"description": "A short, memorable domain for a focused product, brand, marketplace, media property, or software tool.",
−"body": "example.com can support a clear digital product or brand because it is simple, memorable, and flexible.",
−"useCases": ["Product landing page", "Marketplace", "Media brand", "Community"],
−"buyerTypes": ["Startup founders", "Product teams", "Agencies", "Brand builders"],
−"brandAngles": ["Short brand", "Digital product", "Community", "Marketplace"]
−}
−}
−}
−
−Content requirements
−
−For each sale_lander domain, write unique content.
−
−Each domain should have:
−
−1. A short hero description.
−2. A separate “Why [domain]?” body paragraph.
−3. Four possible use cases.
−4. Four buyer types.
−5. Four brand angles.
−
−Avoid repeating the exact same sentence in the hero and the “Why [domain]?” card.
−
−The hero should be concise and commercial.
−
−The “Why [domain]?” section should explain the domain’s positioning in more detail.
−
−Example:
−
−Hero:
−“May be available for purchase. A compact domain suited to AI training, technology media, certification, tooling, or enterprise transformation programs.”
−
−Why section:
−“This domain can work for a training, technology, or transformation brand that wants a short name with strong AI and technology associations.”
−
−Do not copy this exact example unless it fits the domain. Create domain-specific copy.
−
−SEO requirements
−
−Add or preserve the following:
−
−1. Unique page title per domain.
−2. Unique meta description per domain.
−3. Self-canonical URL per domain.
−4. robots.txt.
−5. Crawlable public pages.
−6. Noindex should not be used unless specifically requested.
−7. Do not index raw metadata files such as domains.json.
−8. Avoid thin duplicated content.
−9. Add enough unique visible text to make each domain page meaningfully different.
−10. Use semantic HTML where practical.
−11. Keep headings clear and readable.
−12. Keep CTAs understandable to non-technical visitors.
−
−robots.txt should usually look like this:
−
−User-agent: *
−Allow: /
−Disallow: /domains.json
−
−If a sitemap exists, include:
−
−Sitemap: [SITEMAP_URL]
−
−Cloudflare Workers requirements
−
−If this is a Cloudflare Workers project:
−
−1. Use wrangler.jsonc.
−2. Serve static files from the configured public directory.
−3. Keep the assets directory correct.
−4. Do not switch the project to Cloudflare Pages unless explicitly requested.
−5. If the user wants the workers.dev URL disabled, set:
−
−"workers_dev": false,
−"preview_urls": false
−
−6. Do not remove custom domains.
−7. Do not break Worker deployment.
−8. Keep the project deployable with:
−
−npx wrangler deploy
−
−CTA requirements
−
−The primary CTA should open a mailto link to [CONTACT_EMAIL].
−
−The email subject should include the domain name.
−
−Example:
−Subject: Domain purchase inquiry for example.com
−
−The email body should be polite and short.
−
−Example:
−Hello [PUBLIC_ENTITY_NAME],
−
−I am interested in buying example.com.
−
−The CTA text should be clear to a layperson.
−
−Recommended CTA:
−Ask about buying this domain
−
−Avoid vague phrases such as:
−
−* Make an acquisition inquiry
−* Submit commercial interest
−* Domain acquisition request
−
−Design requirements
−
−Create a clean, responsive, premium-looking static page.
−
−The page should:
−
−1. Work on desktop and mobile.
−2. Have a strong hero section.
−3. Show the domain name clearly.
−4. Use readable typography.
−5. Use cards or sections for possible uses, buyer types, and brand angles.
−6. Avoid visual clutter.
−7. Avoid duplicated navigation blocks.
−8. Keep footer simple.
−9. Make all links clickable.
−10. Make all external links open in a new tab.
−
−Suggested page layout for sale domains:
−
−* Eyebrow: Premium domain
−* H1: domain name
−* Short purchase availability text
−* CTA buttons
−* Side card: Possible uses
−* Content cards:
−
−  * Why [domain]?
−  * Who it may suit
−  * Brand angles
−* Bottom brand links
−* Footer with [PUBLIC_ENTITY_NAME]
−
−Suggested page layout for ecosystem domains:
−
−* Eyebrow: Ecosystem or Personal ecosystem
−* H1: title
−* Description
−* CTAs
−* Side card: Highlights
−* Bottom brand links
−* Footer with [PUBLIC_ENTITY_NAME]
−
−Suggested page layout for active domains:
−
−* Eyebrow: Active destination
−* H1: domain name
−* Description
−* CTA to continue to destination
−* Status card
−* Footer with [PUBLIC_ENTITY_NAME]
−
−Technical implementation requirements
−
−1. Detect the current hostname.
−2. Normalize the hostname by removing “www.”
−3. Match the hostname against the metadata file.
−4. Render the correct page based on the domain status.
−5. If there is no match, render the fallback page.
−6. Escape HTML values before rendering user-visible metadata.
−7. Keep the code readable.
−8. Keep functions small and named clearly.
−9. Avoid fragile string duplication where a helper function is better.
−10. Make it easy to add a new domain by editing only the metadata file.
−11. Add comments only where they help future maintenance.
−12. Do not introduce unnecessary dependencies.
−
−Required verification
−
−After implementation, verify:
−
−1. The project still deploys.
−2. wrangler.jsonc exists if using Cloudflare Workers.
−3. Static files are inside the correct public directory.
−4. The metadata file exists and is valid JSON.
−5. Every domain in [SALE_DOMAINS] is present in the metadata.
−6. Every domain in [ACTIVE_DOMAINS] is marked active.
−7. Every domain in [ECOSYSTEM_DOMAINS] is marked ecosystem.
−8. Sale domains show purchase CTA.
−9. Active domains do not show purchase CTA.
−10. Ecosystem domains do not show purchase CTA.
−11. Unknown domains show safe fallback content.
−12. Footer shows only [PUBLIC_ENTITY_NAME].
−13. Generic pages do not mention private or irrelevant details.
−14. Links are clickable.
−15. External links open in a new tab.
−16. robots.txt exists.
−17. domains.json is disallowed in robots.txt.
−18. Page titles and meta descriptions are unique per known domain.
−19. No visible section repeats the exact same paragraph word-for-word.
−20. The README explains how to add a new domain.
−
−README requirements
−
−Update or create README.md with:
−
−1. What the project does.
−2. File structure.
−3. How domain routing works.
−4. How to add a new sale domain.
−5. How to add an active domain.
−6. How to add an ecosystem domain.
−7. How to deploy.
−8. How to disable workers.dev and preview URLs if needed.
−9. Definition of done checklist.
−
−Output format
−
−When you finish, provide:
−
−1. A concise summary of what changed.
−2. List of files created or modified.
−3. Any important implementation decisions.
−4. Any risks or limitations.
−5. Manual test URLs to check.
−6. Deployment command.
−7. Confirmation that the definition of done was met.
−
−Final instruction
−
−Think carefully before editing. Inspect the existing project first. Preserve anything that already works. Make the smallest complete set of changes needed to build a clean, reusable, SEO-aware, multi-domain static website system. Do not leave the project half-finished. Do not require a second prompt to complete the core implementation.
+## Objective
+
+Inspect the supplied repository and design the smallest complete change that serves multiple domain-specific static websites and pages from one codebase.
+
+When local editing is authorized and Codex has repository access, implement the approved change.
+
+Do not deploy, change DNS, attach custom domains, alter production routes, publish content, or access provider accounts unless those actions are explicitly authorized and separately confirmed by a human.
+
+## Inputs
+
+* Repository and existing architecture: [Repository context]
+* Authoritative domain records and proposed public content: [Domain inventory]
+* Public owner, contact, primary-site, and footer details: [Public identity]
+* Approved public navigation destinations: [Brand links]
+* Hosting target, asset paths, project settings, and deployment constraints: [Deployment settings]
+* Permitted actions, prohibited actions, and human approval gates: [Approval boundaries]
+* Required behavior, tests, and completion conditions: [Acceptance criteria]
+
+## Input contract
+
+The domain inventory must list every hostname and assign exactly one disposition:
+
+* `sale_lander` — approved for a public page that may present the domain as available for acquisition;
+* `ecosystem` — approved for a public founder, brand, project, product, or ecosystem page without sale language;
+* `active` — already serves a real product, website, or external destination and must be protected from sale content and unauthorized route changes;
+* `hold` — not approved for publication, generated public metadata, routing, custom-domain attachment, canonicalization, sitemap inclusion, or deployment.
+
+`fallback` is not a hostname disposition. It is the system response for an unmatched or invalid host.
+
+Exclude `hold` records from generated public metadata and the runtime known-host map, but retain them in the inventory reconciliation report so the accepted-public, held, rejected, and unresolved counts can be reconciled.
+
+A `sale_lander` record needs:
+
+* confirmed authority to present the domain as potentially available;
+* approved public wording;
+* a title and meta description;
+* concise availability wording;
+* detailed positioning copy;
+* normally three to four distinct, domain-relevant use cases;
+* normally three to four suitable audience or buyer types;
+* normally three to four defensible brand angles;
+* approved contact behavior.
+
+Use four entries where the supplied approved content or a defensible interpretation of the domain supports four genuinely distinct entries. Do not pad the lists with generic, repetitive, speculative, or unsupported claims merely to reach a fixed number.
+
+If the page design requires four items but fewer than four suitable entries can be prepared responsibly, mark the record incomplete or `hold` and request human-approved content rather than inventing filler.
+
+An `ecosystem` record needs approved positioning, highlights, and destination links without sale language.
+
+An `active` record needs its real approved HTTPS destination and must not be included in a deployment, route, or custom-domain attachment plan unless a human explicitly authorizes that routing.
+
+Public identity must contain only information approved for publication:
+
+* public entity name;
+* public contact address;
+* primary website URL;
+* approved CTA wording.
+
+Brand links must provide approved labels and HTTPS URLs.
+
+Deployment settings must state whether the repository actually targets Cloudflare Workers or another static host, identify existing configuration and asset locations, and say whether local commands may be run.
+
+Never request or place API tokens, account credentials, private contact details, internal notes, or secrets in source files, generated output, logs, or public metadata.
+
+When correcting an existing defect, trace the failure and confirm its root cause from repository evidence before editing.
+
+Before editing, report missing, ambiguous, or conflicting inputs. Treat the following as blockers:
+
+* overlaps between `sale_lander`, `ecosystem`, `active`, and `hold` dispositions;
+* unconfirmed authority to use sale language;
+* missing active destinations;
+* conflicting host mappings;
+* unclear production authority;
+* an unavailable repository where exact implementation is requested.
+
+Do not resolve blockers by guessing.
+
+If a non-critical content field is missing, identify it and offer clearly labelled draft copy for human review, but do not represent that copy as approved or published.
+
+If repository inspection or command execution is unavailable, produce a proposed patch plan rather than claiming implementation.
+
+## Repository inspection and evidence
+
+Use Codex to inspect the accessible workspace before proposing changes.
+
+Identify:
+
+* the current file tree;
+* package scripts;
+* hosting configuration;
+* routing mechanism;
+* asset directory;
+* metadata source;
+* SEO implementation;
+* tests;
+* README instructions.
+
+Cite file paths and relevant configuration keys for each architectural observation.
+
+Do not claim that a file, route, provider setting, command, or capability exists unless it was observed.
+
+Do not assume:
+
+* internet access;
+* Cloudflare account access;
+* DNS access;
+* deployment credentials;
+* custom-domain configuration;
+* current provider capabilities.
+
+Reconcile the domain inventory before implementation.
+
+Normalize hostnames conservatively:
+
+* convert them to lowercase;
+* remove a terminal dot;
+* handle a `www` alias only when the inventory explicitly says it is equivalent.
+
+Reject:
+
+* URL paths;
+* schemes;
+* ports;
+* wildcards;
+* duplicate normalized hosts;
+* malformed internationalized names;
+* conflicting dispositions.
+
+Produce separate counts for:
+
+* accepted public hosts by disposition;
+* held records;
+* rejected records;
+* unresolved records.
+
+List every rejected or unresolved record and the reason.
+
+The implemented runtime known-host set must reconcile exactly to the accepted public inventory and must exclude all `hold` records.
+
+## Architecture and routing
+
+Preserve a working architecture when it can satisfy the requirements.
+
+Use one codebase and one authoritative metadata source rather than separate projects or copied pages.
+
+Do not add a:
+
+* database;
+* CMS;
+* authentication system;
+* admin panel;
+* backend framework;
+* unnecessary dependency.
+
+For Cloudflare Workers, preserve the existing Worker model and inspect the installed Wrangler configuration before changing it.
+
+Use the repository’s supported configuration and asset-binding pattern rather than inventing keys.
+
+Do not migrate the project to Cloudflare Pages.
+
+A configuration change affecting:
+
+* `workers.dev`;
+* preview URLs;
+* routes;
+* custom domains;
+
+requires explicit approval.
+
+Keep active production hostnames out of proposed route attachments unless [Approval boundaries] specifically authorizes them.
+
+Choose rendering that meets [Acceptance criteria] and the supplied SEO requirements.
+
+If pages are rendered only after browser JavaScript fetches public metadata, disclose the crawlability and metadata limitations.
+
+Prefer a host-aware server response or pre-rendered host-specific HTML when supported by the existing platform and acceptance criteria.
+
+Any metadata delivered to a browser is public even if `robots.txt` discourages crawling. It must therefore contain no secrets, private records, or internal notes.
+
+At request time:
+
+1. Derive the hostname from the platform’s trusted request URL.
+2. Normalize it using the reconciled rules.
+3. Perform an exact metadata lookup.
+4. Render according to the matched disposition.
+
+Never trust a free-form `Host` value to construct:
+
+* redirects;
+* canonical URLs;
+* HTML;
+* mail links;
+* metadata.
+
+An unknown or invalid host must receive the safe, non-indexable behavior defined below.
+
+## Disposition behavior
+
+### `sale_lander`
+
+Render:
+
+* the approved domain name;
+* a unique title and meta description;
+* concise availability wording;
+* separate positioning copy;
+* normally three to four distinct possible use cases;
+* normally three to four suitable audience or buyer types;
+* normally three to four defensible brand angles;
+* a plain-language email CTA;
+* a primary-site CTA;
+* approved brand links;
+* the public entity footer.
+
+Generate and percent-encode the `mailto` subject and body. Include the domain in the subject.
+
+Do not imply:
+
+* a price;
+* trademark clearance;
+* guaranteed availability;
+* brokerage authority;
+* ownership beyond supplied approved facts.
+
+Do not generate generic filler merely to reach a fixed number of cards or list entries.
+
+### `ecosystem`
+
+Render:
+
+* approved positioning;
+* highlights;
+* relevant CTAs;
+* approved brand links;
+* the public entity footer.
+
+Suppress all language relating to:
+
+* purchase;
+* acquisition;
+* premium-domain status;
+* buyers;
+* availability for sale.
+
+### `active`
+
+Render only a protective destination notice and an HTTPS continuation link if the active domain accidentally reaches this project.
+
+Suppress every purchase CTA and sale claim.
+
+Treat the defensive notice as `noindex` and exclude it from the sitemap.
+
+This page does not authorize changing:
+
+* DNS;
+* Worker routes;
+* custom-domain configuration;
+* the active service.
+
+### `hold`
+
+Do not generate:
+
+* public metadata;
+* a public page;
+* a runtime known-host entry;
+* a route attachment;
+* a canonical URL;
+* a sitemap entry;
+* a deployment record.
+
+Retain the record only in the authoritative inventory and reconciliation report.
+
+If a held hostname accidentally reaches this project, treat it as an unmatched host and apply the neutral unknown-host behavior. Do not reveal that the hostname appears in a private or held inventory.
+
+### Unknown or invalid hosts
+
+Return a neutral, non-indexable fallback or error response that makes no ownership, sale, availability, endorsement, or affiliation claim.
+
+Prefer an HTTP `404` or `421` response where the platform and existing architecture support it.
+
+Do not echo the untrusted received hostname into:
+
+* visible copy;
+* HTML attributes;
+* redirects;
+* canonical URLs;
+* mail links;
+* metadata.
+
+Apply `noindex,nofollow` through page metadata or the appropriate `X-Robots-Tag` header.
+
+Do not:
+
+* include the response in a sitemap;
+* assign it a self-canonical URL;
+* infer that the hostname belongs to the organization;
+* infer that the hostname is for sale.
+
+Show an approved primary-site or support link only when [Acceptance criteria] expressly permits that behavior.
+
+## Security, privacy, and content controls
+
+Escape all metadata inserted into HTML text and attributes.
+
+Validate outbound URLs against an allowlist of required schemes.
+
+Public navigation and active destinations must use HTTPS.
+
+Build `mailto` links with encoded components.
+
+Add `target="_blank"` and `rel="noopener noreferrer"` to genuine external browser links when that behavior is required, but do not force a new tab for `mailto` links.
+
+Avoid:
+
+* unsafe HTML insertion;
+* open redirects;
+* path traversal;
+* permissive wildcard host matching;
+* client-visible private data.
+
+Use semantic, responsive HTML and maintain:
+
+* visible keyboard focus;
+* meaningful heading order;
+* descriptive link text;
+* sufficient contrast;
+* usable mobile layouts.
+
+Keep sale-page content meaningfully distinct without making unsupported claims.
+
+Do not repeat the hero paragraph as the detailed positioning paragraph.
+
+## SEO and indexability
+
+Apply indexability according to disposition:
+
+* `sale_lander` and `ecosystem` pages may be indexable only when the hostname record and public content are explicitly approved for publication;
+* an `active` defensive notice must be `noindex` and excluded from the sitemap;
+* `hold` records must never produce a public page;
+* unknown-host, invalid-host, preview, and `workers.dev` fallback responses must be `noindex` and excluded from the sitemap.
+
+For every approved, known public hostname:
+
+* provide a unique title;
+* provide a unique meta description;
+* provide crawlable HTML where required;
+* create an absolute self-canonical HTTPS URL from the validated configured hostname.
+
+Never construct a canonical URL merely from an arbitrary request hostname.
+
+Add or preserve `robots.txt`.
+
+If public metadata is exposed at a stable path, disallow that path in `robots.txt`, while stating in documentation that crawl directives are guidance rather than access control.
+
+Include a sitemap reference only when a real sitemap URL is supplied or generated and verified.
+
+Do not include:
+
+* active defensive notices;
+* held records;
+* unknown hosts;
+* invalid hosts;
+* preview URLs;
+* `workers.dev` fallback responses;
+
+in a sitemap.
+
+## Change controls and stop conditions
+
+Make the minimum reviewable file changes and preserve unrelated working code.
+
+Before:
+
+* destructive replacement;
+* route modification;
+* dependency migration;
+* file deletion;
+
+stop and request approval with the exact files and likely impact.
+
+Do not edit generated or production-only artifacts when their source is available.
+
+Do not:
+
+* commit;
+* push;
+* deploy;
+* attach domains;
+* alter DNS;
+* delete resources;
+* claim stakeholder approval;
+
+unless expressly authorized.
+
+Before edits, provide:
+
+* a change plan;
+* a rollback plan.
+
+The rollback plan must identify:
+
+* how local changes can be reverted;
+* which configuration files would need restoration;
+* which provider actions, if any, would require a separate human-controlled rollback.
+
+Do not claim that a provider rollback exists without evidence.
+
+Stop if tests reveal:
+
+* possible active-domain takeover;
+* sale language on a non-sale host;
+* unsafe HTML or redirects;
+* secret exposure;
+* inventory mismatch;
+* broken existing behavior;
+* an unapproved production change.
+
+## Implementation verification
+
+Run only commands permitted by [Approval boundaries] and supported by the repository.
+
+For every command, record:
+
+* the exact command;
+* its target;
+* its exit status;
+* a concise relevant output excerpt;
+* any limitations.
+
+Never convert a skipped, unavailable, failing, or blocked check into a pass.
+
+At minimum, verify with automated tests or reproducible local requests where the architecture permits:
+
+1. Metadata parses successfully.
+2. Every accepted public domain appears exactly once with one valid public disposition.
+3. Every `hold` record remains in the reconciliation report but is absent from generated public metadata and the runtime known-host map.
+4. Accepted public, held, rejected, and unresolved counts reconcile to the authoritative inventory.
+5. Case and terminal-dot normalization behave as specified.
+6. `www` behavior follows only explicitly declared aliases.
+7. One representative host from each populated public disposition renders the correct template.
+8. Every sale host has the required acquisition CTA and complete, distinct, approved content.
+9. A sale host that lacks enough defensible public content is treated as incomplete or `hold` rather than padded with generic filler.
+10. Every active and ecosystem host is free of sale language and purchase CTAs.
+11. A held hostname produces no public page or runtime metadata entry.
+12. An unknown host and a malformed host receive the safe non-indexable response.
+13. Unknown-host behavior does not echo the received hostname or create a self-canonical URL.
+14. Active links use their configured HTTPS destinations and cannot become open redirects.
+15. Metadata containing HTML metacharacters is escaped rather than executed.
+16. `mailto` parameters are correctly encoded and contain the relevant sale domain.
+17. Approved public hosts have unique titles, unique meta descriptions, and validated self-canonical URLs.
+18. Indexability follows the defined disposition policy.
+19. Active, held, unknown, invalid, preview, and `workers.dev` fallback responses are excluded from the sitemap.
+20. Genuine external HTTPS links use the required new-tab security attributes, while `mailto` behavior remains usable.
+21. `robots.txt` exists, has the intended directives, and disallows any exposed public metadata path when applicable.
+22. The build or platform validation command succeeds without breaking existing tests.
+23. A dry run or local Worker simulation succeeds if supported and authorized.
+24. README instructions accurately explain:
+
+    * metadata fields;
+    * disposition semantics;
+    * adding a domain;
+    * placing a domain on hold;
+    * unknown-host behavior;
+    * local verification;
+    * deployment prerequisites;
+    * production approval gates.
+
+If real DNS, custom-domain, HTTP, crawlability, or deployed-host verification is outside Codex’s access, provide exact human-run checks and mark their results unverified.
+
+Suggested production checks may include:
+
+* DNS resolution;
+* TLS validity;
+* HTTP status;
+* canonical source;
+* rendered metadata;
+* redirect destination;
+* robots response;
+* confirmation that active domains still reach their real services.
+
+Do not report deployment success based only on a local build.
+
+When deployment evidence is supplied, bind it to the exact reviewed release.
+
+Record, where available:
+
+* repository commit or revision;
+* final diff or release reference;
+* generated artifact identity or digest;
+* Cloudflare account, Worker, or hosting-project identifier without exposing credentials;
+* target environment;
+* route and custom-domain configuration;
+* deployment timestamp;
+* command or pipeline execution record;
+* post-deployment checks.
+
+A successful build, test run, deployment log, or provider screenshot from another commit, artifact, Worker, account, route configuration, or execution window is not verification of the current release unless a traceable relationship is supplied.
+
+If that relationship cannot be established:
+
+* describe the local implementation as verified only within its tested scope;
+* mark deployment, DNS, route, TLS, and public-host behavior unverified.
+
+## Output contract: multi-site implementation deliverable
+
+Return the task-specific sections below.
+
+Keep every section concise and proportional to:
+
+* the repository state;
+* the approved domain inventory;
+* the change scope;
+* the work actually performed.
+
+Do not repeat the same evidence, inventory record, or limitation across several sections unnecessarily.
+
+Where a section is genuinely not applicable, retain its heading, state `Not applicable`, and explain briefly why.
+
+Where no local edit occurred, omit the Implemented patch record or mark it `Not executed`.
+
+Where deployment or provider access was unavailable, keep those actions in the human handoff rather than filling the section with invented results.
+
+Never omit:
+
+* inventory reconciliation;
+* approval gates;
+* verification matrix;
+* active-domain protection record;
+* risks and limitations;
+* truthful work-state and deployment language.
+
+### Inspection record
+
+Report:
+
+* observed architecture;
+* relevant files;
+* available commands;
+* access limitations.
+
+### Inventory reconciliation
+
+Report:
+
+* accepted public hosts by disposition;
+* held records;
+* rejected records;
+* conflicting or unresolved records;
+* counts that must reconcile.
+
+### Proposed change set
+
+Report:
+
+* files to create or modify;
+* routing and rendering decisions;
+* SEO approach;
+* security controls;
+* why each change is necessary.
+
+### Approval gates
+
+Separate:
+
+* actions completed locally;
+* actions merely proposed;
+* provider or production actions requiring human approval.
+
+### Implemented patch record
+
+List only files actually changed, with concise behavior descriptions.
+
+Omit this section or mark it `Not executed` when no edits occurred.
+
+### Verification matrix
+
+For every requirement or check, report:
+
+* check or command;
+* target;
+* expected observation;
+* actual observation;
+* evidence;
+* status: `passed`, `failed`, `blocked`, or `not run`.
+
+### Active-domain protection record
+
+Provide evidence that:
+
+* active hosts were excluded from sale behavior;
+* active hosts were excluded from unauthorized route changes;
+* DNS, route, and provider assumptions are explicitly marked unverified where evidence is unavailable.
+
+### Risks and limitations
+
+Report unresolved concerns relating to:
+
+* SEO;
+* hosting;
+* public metadata;
+* content approval;
+* browser behavior;
+* provider access;
+* deployment;
+* DNS and routing.
+
+### Rollback instructions
+
+Provide:
+
+* repository-level reversal steps;
+* configuration files to restore;
+* separately gated provider rollback actions.
+
+Do not describe an unverified provider rollback as available.
+
+### Human test plan
+
+List:
+
+* exact local or deployed URLs only when derivable from supplied configuration;
+* expected disposition-specific observations;
+* checks that remain unverified;
+* accountable human reviewer where supplied.
+
+### Deployment handoff
+
+Provide:
+
+* the repository-supported deployment command if observed;
+* prerequisites;
+* release identity;
+* required approval steps;
+* post-deployment checks.
+
+Never execute deployment unless expressly authorized.
+
+## Completion language
+
+Use precise work-state language:
+
+* `proposed` for unmade changes;
+* `changed` for observed local edits;
+* `passed` only for successful checks with evidence;
+* `failed` for executed checks that did not meet their criteria;
+* `blocked` for checks that cannot safely proceed;
+* `unavailable` for inaccessible capabilities;
+* `unverified` for checks not performed or claims not supported by sufficient evidence;
+* `deployed` or `published` only when that action actually occurred and verifiable evidence is available.
+
+Do not claim that the multi-domain system is complete, deployed, routed, indexed, or publicly verified merely because local code or metadata was created.