How to Build Multiple Static Websites with One Codex Prompt

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.