Build Website With AI
Use this when you need a real website, not just a mockup. Start by preparing ownership, project files, deployment, domain access, measurement, and monitoring. Then paste the build prompt into Codex or another coding agent so the site can be created, checked, deployed, and handed off with proof.
Start here if you have no website
Confirm who owns the domain, repo or project files, deployment host, Google account, and future website files. Do not build into an account the business will not control.
Choose a local folder and GitHub repo before generating files. Codex is strongest when it can edit the actual project, run checks, commit, and leave evidence.
Before any code, land docs/site-truth/PROJECT_BRIEF.md, SOURCE_OF_TRUTH.md, OWNER_WISHLIST_INTAKE.md, and docs/design/DESIGN_THESIS.md. These outrank mockups, remembered details, and the old site if any. The Web Builder standard treats them as load-bearing source of truth.
Use Vercel/Next.js 16 + Tailwind v4 when there is no constraint (the pinned versions the workspace builds against). If the client requires WordPress, Shopify, ASP.NET/IIS, static hosting, or a custom server, adapt the Web Builder output to that stack.
Write down the offer, target customer, service area, required pages, CTA, contact method, brand assets, proof sources, and legal or compliance needs.
Paste the prompt into Codex, Claude Code, Cowork, or your developer. If the agent can edit files and run commands, it should build directly. If not, it should produce a handoff.
Deploy the site, connect DNS, submit sitemap, set up Search Console and GA4, then attach the live URL to Site Clinic monitoring.
Which tool should I use?
The standard the website must follow: page structure, on-page SEO, accessibility, deployment handoff, Site Monitor connection, and launch proof.
Good for turning your idea into a page plan or checklist. Not enough by itself if files need to be created, deployed, committed, or verified.
Best when you want the agent to edit the repo, run checks, inspect errors, deploy, commit changes, and leave verification evidence in the workspace.
Use these when they are your working coding surface. The rule is the same: follow the Web Builder standard, edit the project, run checks, and report proof.
AI can use approved tokens for GitHub, Vercel, Stripe, or Site Clinic API work, but the customer still owns logins, billing, domain authorization, and final approvals.
Pick the right starting path
Create or confirm GitHub or the chosen repo path, make the project folder, choose Vercel or the client-required platform, gather business inputs, then use the build prompt.
Keep registrar access ready, decide whether DNS moves to the host or stays at the registrar, and do not change records until the deployment target is ready. Treat GoDaddy DNS as manual for novice onboarding.
If the client already has ASP.NET/IIS, WordPress, Shopify, Webflow, static hosting, or another approved platform, document that constraint and build the Site Clinic standard into that environment.
Inventory current URLs, preserve or redirect valuable pages, keep Search Console continuity, and connect the live site to Site Clinic before and after launch.
Use one intake per site: domain, repo owner, client label, analytics access, dashboard owner, reporting cadence, and proof requirements.
What AI can and cannot do
These can often be connected through CLI auth, API keys, or app tokens. Other hosts may be manual or client-controlled. Use least-privilege access and store secrets only in local env files or the hosting secret manager.
For this flow, GoDaddy is a browser step. Codex should write the exact A, CNAME, TXT, or nameserver instructions, but the account owner makes the change.
Codex can prepare tags and verification files when the repo is available. The owner still confirms property access and submits sitemaps in the Google account.
Copy-paste build prompt
Fill in the bracketed fields, then paste this into Codex, Claude Code, Cowork, or another implementation assistant. If you are using Codex, keep the project folder open so it can edit files, run checks, commit, and report verification evidence. If you are using a chat-only AI, use the output as a handoff for Codex or your developer.
You are helping me build and launch a small-business website using the Site Clinic Web Builder standard, fully aligned with the build-websites-template doctrine.
Goal:
Build a real, deployed, monitored, doctrine-compliant website. Do not stop at a mockup. End with a working project, the full doctrine artifact set, build-time gates passing, runtime monitoring live, and proof of what was verified.
Tooling rule:
- Site Clinic Web Builder is the workflow standard. The canonical doctrine is build-websites-template (7 numbered files: 01 discovery, 02 design direction, 03 build standard, 04 tracking and monitoring, 05 QA and release, 06 site monitor onboarding, 07 migration playbook).
- Codex, Claude Code, Cowork, or another coding agent is the execution surface.
- If you can edit files, run commands, deploy, and verify, execute the work directly.
- If you cannot edit files or access the project, produce an implementation-ready handoff and tell me exactly which tool/action is needed next.
My starting point:
- Website status: [no website / old website / rebuilding existing site]
- Business name:
- Domain registrar: [GoDaddy / Namecheap / Cloudflare / other]
- Domain name:
- GitHub account/repo owner:
- Local project folder:
- Deployment target or required stack: [Vercel preferred / WordPress / Shopify / ASP.NET/IIS / static host / custom server / other]
- Human account access ready: [GitHub or repo host / deployment host / domain registrar / Stripe if payments are needed / Google Search Console / GA4]
- Agent-access tokens available where appropriate: [GitHub token / Vercel token / Site Clinic API key / Site Clinic MCP config / other]
- Manual-only steps expected: [GoDaddy DNS / billing / account ownership / Google verification]
- Business type and service area:
- Primary offer:
- Target customer:
- Required pages:
- Contact method:
- Brand assets available:
- Existing copy/assets:
- Legal/compliance needs:
Required build standard (doctrine Phase 0 through Phase 4a):
Doctrine Phase 0 — site truth + design docs (BEFORE any code):
1. Land docs/site-truth/PROJECT_BRIEF.md — top-3 business goals, primary visitor action, must-stay items, must-remove items, approved claims list.
2. Land docs/site-truth/SOURCE_OF_TRUTH.md — verified business facts with confidence tiers (VERIFIED-REPO / VERIFIED-LIVE / NEEDS_VERIFICATION). Required: legal name, canonical domain, redirects, address, phone, email(s), hours, providers + credentials, services, social profiles, compliance-sensitive statements.
3. Land docs/site-truth/OWNER_WISHLIST_INTAKE.md — owner intake answers separated from facts.
4. Land docs/design/DESIGN_THESIS.md — one-sentence design thesis (locked), palette tokens, type system, layout principles, imagery direction, explicit anti-patterns list.
Doctrine Phase 1 — foundation skeleton (pinned versions, doctrine wiring):
5. Scaffold Next.js ^16.2.6 + React 19.2.4 + Tailwind v4 + TypeScript with --app --src-dir --import-alias '@/*'.
6. Install build-websites-tools as dev dependency (npm install -D github:drjliddy-max/build-websites-tools) and wire package.json scripts gate:ada, gate:seo, gate:all, prebuild.
7. Create initial gate.config.json: { "routes": ["/"], "baseUrl": "http://localhost:3000" }.
8. Wire fonts via next/font/google in app/layout.tsx. For ANY serif/display font that the design thesis uses for italic accents, load BOTH normal AND italic styles (avoid synthesized slant — the most subtle wiring bug).
9. Apply Tailwind v4 @theme inline tokens in src/app/globals.css using the palette from DESIGN_THESIS.md. Do NOT use Tailwind v3 tailwind.config.ts theme.extend syntax.
10. Add Organization and WebSite JSON-LD scripts to app/layout.tsx, values sourced from SOURCE_OF_TRUTH.md. Founder name uses the canonical form per workspace memory (no medical credentials on SaaS/tech surfaces).
11. Create vercel.json with security headers: X-Content-Type-Options nosniff, X-Frame-Options SAMEORIGIN, Strict-Transport-Security max-age=63072000; includeSubDomains; preload, Referrer-Policy strict-origin-when-cross-origin. Add apex/www redirects.
12. Add src/app/sitemap.ts and src/app/robots.ts as Next.js metadata routes.
13. Build 5 reusable components in src/components/: Eyebrow (default + withDot), Button (primary + secondary + text-link; export VARIANT_CLASS; refuse a 4th variant), SiteHeader (logo + nav), SiteFooter (copyright + legal links), Hero (optional).
14. Replace default app/page.tsx with a verification stub: design-thesis palette background, display font headline with italic <em> accent (visually verify REAL italic, not synthesized), body font, Eyebrow component. Run npm run gate:all — expect ADA pass and SEO pass on /.
Doctrine Phase 2 — build pages with the four-step migration unit:
15. For each required page (homepage, every page in PROJECT_BRIEF page list, plus /privacy /terms /accessibility /contact when applicable per build-websites-template/03-build-standard.md), apply the LOCKED 4-step unit per doctrine §5.1: (a) add src/app/<route>/page.tsx, (b) add to src/app/sitemap.ts, (c) add legacy redirect in next.config.ts (N/A for fresh build), (d) add route to gate.config.json. Then npm run gate:all must PASS before commit. Iterate one page per cherry-pick.
Doctrine Phase 4a — staging, Playwright, GA4, Site Clinic instrumentation:
16. Install Playwright per build-websites-template/05-qa-and-release.md. Configure desktop + mobile viewports. Write minimum E2E tests: homepage 200, all first-level nav links 200, legal pages 200, contact 200, external social links, buttons clickable, mobile viewport no horizontal overflow. Add npm script test:e2e.
17. Wire GA4 + cookie consent banner per build-websites-template/04-tracking-and-monitoring.md. Workspace-shared GA4 ID is G-CKCC40VRPH (use that for portfolio sites; for customer's own analytics, provision a separate GA4 property). Load gtag.js only AFTER consent; persist consent in localStorage; reflect actual behavior in privacy policy.
18. Provision a Site Clinic API key at https://siteclinic.io/developers/dashboard. Paste directly into the local .env.local; do NOT paste in chat. Add the same value to Vercel env vars (Production + Preview).
19. Install the Site Clinic MCP server in the AI agent per https://siteclinic.io/developers/mcp — current install commands live there. Verify by calling siteclinic_baseline against the Vercel preview URL.
20. Run final verification per build-websites-template/05-qa-and-release.md Operational Verification: npm run gate:all on every route PASS, npm run test:e2e PASS, browser load + cookie accept + GA4 real-time receives hostname traffic, Search Console domain property verified, sitemap.xml and robots.txt resolve at the deployed URL.
Definition of done:
- All 4 doctrine docs (PROJECT_BRIEF, SOURCE_OF_TRUTH, OWNER_WISHLIST_INTAKE, DESIGN_THESIS) exist as files in the repo.
- Next.js 16 + Tailwind v4 foundation skeleton wired: fonts with italic (not synthesized), JSON-LD, vercel.json security headers, sitemap.ts + robots.ts, 5 reusable components.
- gate.config.json + build-websites-tools installed; npm run gate:all PASSES on every route.
- Every page satisfies the 4-step migration unit (page + sitemap + redirect-if-applicable + gate).
- Playwright E2E gate set up + PASSING.
- GA4 + cookie consent wired; privacy policy matches behavior.
- Site Clinic API key in Vercel env; Site Clinic MCP server installed in agent.
- Site Monitor monitoring connected (trial started + URL attached at /c/<slug>) OR explicitly deferred.
- Final operational verification all green.
If you are Codex, Claude Code, Cowork, or another coding agent:
Edit the files directly, run the available checks, summarize changed files, and report verification evidence. If a step requires an external account action (Site Clinic key provision, DNS change, Google access grant), write the exact instruction for me and pause only for that action. The full doctrine source lives at build-websites-template in the workspace — fetch any of the 7 numbered docs by name if you need exact specifications.What every user must end with
A GitHub owner or repo decision, a local project folder, and a written note about who owns future changes.
docs/site-truth/PROJECT_BRIEF.md, SOURCE_OF_TRUTH.md (with VERIFIED-REPO / VERIFIED-LIVE / NEEDS_VERIFICATION tiers), OWNER_WISHLIST_INTAKE.md, and docs/design/DESIGN_THESIS.md (with locked one-sentence thesis + palette + anti-patterns) exist as files in the repo.
Next.js 16 + Tailwind v4 with next/font/google loading italic for any serif display (no synthesized slant), Organization + WebSite JSON-LD in layout.tsx, vercel.json security headers + apex/www redirects, sitemap.ts + robots.ts metadata routes, the 5 reusable components (Eyebrow, Button, SiteHeader, SiteFooter, Hero).
build-websites-tools installed, gate.config.json present with every route listed, npm run gate:all PASSES on every page, and the prebuild hook blocks Vercel deploys that violate build-websites-template/03-build-standard.md.
Per build-websites-template/05-qa-and-release.md — homepage, all first-level nav links, legal pages, contact, mobile + desktop viewports tested. Tests pass before production cutover.
A host and stack selected, Vercel preferred when unconstrained, with build command, environment variables (SITECLINIC_API_KEY), and production deployment steps known.
Registrar access confirmed, DNS strategy chosen, and exact records or nameserver steps documented before cutover.
GA4 + cookie consent banner wired (gtag loads only after consent), Search Console domain verified, conversion events named, sitemap submitted, launch-day indexing checks written down.
The live URL, scan scope, Site Clinic dashboard owner, alert expectations, and first proof notes are ready. Site Clinic MCP server installed in the AI agent for direct tool calls.
The customer knows whether the next step is build website, connect monitoring, create service pages, start blog authority, or run proof review.