How to Build Multiple Static Websites with One Codex Prompt

## 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.