A step by step guide to building a business website with Claude Code and putting it live: the plan, the design, the checks, the hosting, the domain and the search setup. Each step gives you what to do, a prompt to copy into Claude Code, what to check before you move on, and the mistake that caught a real build. You finish with a site you planned, checked and approved yourself, and a loop you can run for every change after it.
FreeRead on the pagePDF with your emailProgress kept in your browserAdvanced
Before you start
What you need, and the rules Claude Code works under.
What you need
Claude Code, installed and signed in.
A sandbox folder on your computer for the new site, apart from anything live.
The accounts you choose to use, such as hosting, a domain and email. You sign in to each one yourself.
Your facts: what the business does, who it serves, the prices you are happy to publish, and photos you have the rights to.
The rules Claude Code works under
Claude Code drafts, builds and checks. You approve, sign in and deploy. Paste this at the start of every session, then use the prompt in each step as it stands.
For this whole session, work only in [SANDBOX PATH]. Do not sign in to any account, change a live site or account, deploy or publish. Show me what you plan to change and wait for my yes before you change files. If a task would touch anything live, stop and tell me the exact action, so I can approve it and do it myself.
You do every sign in, every verification and every permanent delete yourself.
One yes covers one action. A new change needs a new yes.
Keep passwords, keys and customer details out of prompts, screenshots and project files.
How each step reads
What to do: the actions, in order.
Prompt to copy: paste it into Claude Code and fill in the [BRACKETS].
Skill: the Claude Code skill I used. Skills differ between setups, so the line also says what to ask without it.
Check before moving on: tick each one before the next step.
Where it caught me: the mistake from a site I built, so you can skip it.
Links to official guides were checked on 3 November 2026.
Step 1 · Plan and design
Plan the structure before anything is built
What to do
Write down who the site is for, what a visitor should do next, and the facts you are happy to publish.
Ask Claude Code for a page map and plain grey wireframes. No colour and no styling yet.
Ask for more than one structure, and compare them side by side.
Choose one, and write down the questions still open.
Prompt to copy
Help me plan a website for [BUSINESS] that serves [AUDIENCE]. The main thing a visitor should do is [TASK]. Use only these facts: [FACTS]. Draft a page map and grey wireframes for [PAGES], showing for each page the visitor's question, the sections in reading order and the next step. Give me [NUMBER] different structures to compare, and list the questions I still need to answer. Do not invent claims.
Skill
/goal sets the business goal Claude Code works toward. /website-design:web-review reviews the structure and lists what to fix. Without them, ask Claude Code to restate your goal in one sentence, then judge each structure against it.
Make a new folder for the site, apart from anything live.
Have Claude Code set up a local preview server for it.
Open the preview and check that full size images load completely.
Keep every account and live setting out of the sandbox.
Prompt to copy
Set up a new website project in [SANDBOX PATH], separate from [LIVE SITE FOLDER]. Do not read or change the live site. List the files you plan to create and wait for my yes. Recommend a local preview server for this project and check that full size images load completely in it.
Agree the type, colours, spacing, buttons and repeated parts before any page is built.
Keep them as tokens in one shared CSS file.
Write the same rules down in a short DESIGN-SYSTEM.md.
Measure text contrast on the real backgrounds.
When a rule changes, change the token, never a single page.
Prompt to copy
In [SANDBOX PATH], read the current shared styles, then propose a design system: tokens for [BRAND COLOURS], [FONTS], spacing and repeated controls, and a matching DESIGN-SYSTEM.md. Measure the contrast of every text colour on the background it sits on. Flag anything in the document that no longer matches the CSS. Do not edit files until I approve.
List the logo, photos, illustrations and fonts each page needs.
Decide where a real photo of you or your team helps a visitor trust the page.
Check you have the right to publish every file.
Crop names, other chats and anything private out of screenshots.
Keep full resolution originals outside the site folder.
Save each picture at the size it is shown, with alt text, or an empty alt when it is only decoration.
Prompt to copy
In [SANDBOX PATH], make an asset list for [PAGES]: each file's use, rights, privacy check, display size and alt text. Ask me which photos of me or my team go where. Keep originals in [MASTERS FOLDER], outside the site folder. Do not invent assets or copy anything private.
Skill
/goal helped me decide which sections get a photo of me. Without it, ask Claude Code where a real photo would help a visitor trust the page, and list the choices for you to approve.
Build each page from the approved map and the shared styles.
After every real change, have Claude Code render the page at desktop width and at 390 px.
Look at the pictures yourself: the words, images, forms and page edges.
Check that nothing scrolls sideways and the browser shows no errors.
A page is done when you have seen it, not when the code is written.
Prompt to copy
In [SANDBOX PATH], build [PAGE] from the brief [BRIEF], the page map [MAP] and the design system [DESIGN SYSTEM]. Use only approved facts and write plainly for [AUDIENCE]. After each change, render the page at desktop width and at 390 px, show me both pictures, and report any browser errors, missing content or sideways scrolling.
Skill
website-design:landing-page built my home page in the sandbox. /anti-ai-writing:anti-ai-writing rewrote the copy so it read like a real service. /design put pages side by side to compare. Without them, ask Claude Code to build from the plan, rewrite stiff wording in plain words, and show the rendered pages side by side.
Give every page a Skip to content link and a visible focus ring.
Move through each page with the keyboard alone: menus, tabs and buttons.
Enlarge the text to 200% and check that nothing overlaps.
Give pictures useful alt text, and an empty alt when they are only decoration.
Respect a visitor’s setting for less motion, and keep content visible with JavaScript switched off.
Run an accessibility scan, then check its findings yourself.
Prompt to copy
Review [PAGE] in [SANDBOX PATH] for accessibility: keyboard use and visible focus, a skip to content link, names on controls, alt text, text contrast, 200% text size, reduced motion, and what remains with JavaScript off. Run an accessibility scan and tell me what it cannot check. List each issue with the element and a proposed fix, and wait for my yes before changing files.
Skill
/a11y-enforcer:a11y-enforcer scanned my pages and tested them at phone width. Without it, ask Claude Code for the checks in the prompt above.
Never lock zoom. People with poor eyesight need to pinch.
Check at 360 px and 375 px that every card, table cell and figure ends inside the screen.
Make tap targets at least 44 px.
Keep anything pinned to the screen clear of the notch and home bar with the safe area insets, such as env(safe-area-inset-bottom).
On phones, stack tall cards instead of sliding them sideways.
Check on a real phone before you trust a browser picture.
Prompt to copy
In [SANDBOX PATH], review [PAGE] for iPhone and Android at 360 px and 375 px. Confirm zoom is not locked, check every table cell and figure for content hidden off the screen, check tap targets are at least 44 px, and check fixed buttons keep clear of the notch and home bar using the safe area insets. Propose fixes and wait for my yes.
Skill
The same /a11y-enforcer:a11y-enforcer run tested my phone display. Without it, ask Claude Code for the checks in the prompt.
Save pictures at the size they are shown, with a width and height on every image.
Add loading="lazy" to images further down the page, never to the first picture a visitor sees.
Preload only the fonts the page needs straight away, with font-display: swap.
Let heavy films load a poster picture only, until they are on screen.
Keep outside scripts to a minimum, and load them in the background.
Run a phone speed test on the sandbox, such as Lighthouse in Chrome, and read it before changing anything.
Prompt to copy
In [SANDBOX PATH], review [PAGES] for speed: image sizes and dimensions, lazy loading below the first screen, font preloads with font-display swap, heavy films and outside scripts. Find any section that waits for an image before it shows itself. Run a phone speed check on the sandbox only and explain it in plain words. Propose the smallest useful fixes and wait for my yes.
Skill
searchfit-seo:ai-visibility measured my page weight. Without it, ask Claude Code to add up what each page loads and name the heaviest files.
Install the Netlify command line tool: npm install -g netlify-cli.
Run netlify login and sign in yourself, in the browser that opens.
From then on Claude Code can create the site, deploy and change settings, each on your yes.
Name the site ID in every deploy command, so the right site is changed.
If PowerShell strips the quotes from the JSON in a netlify api command, run it from Git Bash.
Prompt to copy
Prepare the Netlify setup for [SITE]. Read the current Netlify CLI documentation, tell me which commands you plan to run and what each one changes, and wait for my yes before running any. I will run netlify login and sign in myself.
Skill
None for the setup. The Netlify connector (MCP) in Claude Code can also change site settings; I used it to switch on form handling.
Install AWS CLI version 2, and check it supports aws login (version 2.32.0 or later).
Run aws login and sign in yourself. A session lasts 12 hours.
Give Claude Code an IAM user that can change only what the task needs, such as Route 53. Never the root account.
Put your AWS rules in the project’s CLAUDE.md, so every session follows them.
Before any DNS change, have Claude Code read the live records first.
Prompt to copy
Prepare an AWS plan for [TASK]. Check the installed AWS CLI version and whether it supports aws login. Tell me the narrowest IAM permissions this task needs. Never ask for or use root credentials. For any DNS change, show me the full live record set and the full record set after the change, and wait for my yes.
Skill
None for the setup. The AWS Agent Toolkit adds AWS skills and the AWS MCP server to Claude Code.
Put the security headers in a _headers file in that folder.
Send retired addresses on with a _redirects file, such as /old-page /new-page 301!.
Use the ! when you mean it: it makes the redirect win over a file still sitting at the old address.
Wire up the contact form’s email notification only once that address can receive mail.
Prompt to copy
In [SANDBOX PATH], prepare hosting for [HOST] with the publish folder [FOLDER]. Draft _headers with the security headers I approve, and _redirects for these old and new addresses: [LIST]. Flag every forced 301! rule and what it overrides. Check that [NOTIFICATION ADDRESS] can receive mail before you wire up form notifications. Show me the changes and wait for my yes.
Decide where the DNS lives and keep it there. You do not have to hand the nameservers to the host.
Take the record values from the host’s current instructions: usually an A record for the bare domain and a CNAME for www.
Read every existing record before a change. A Route 53 UPSERT replaces the whole record set, so include every value that must stay.
Add www at the host only once www has its DNS record.
Delete any old DNS zone at the host that nothing uses, then let the host issue the HTTPS certificate.
Prompt to copy
Prepare a DNS plan for [DOMAIN] on [HOST], using the host's current instructions. Read the full live record sets first. Show the exact A and CNAME records and, for any Route 53 UPSERT, the complete record set after the change, keeping every existing value that must stay. Explain any effect on email. Wait for my yes before any change.
Take every record value from your email provider’s own instructions.
Add them in the provider’s order, typically the verification TXT record, then MX, SPF, DKIM and autodiscover.
Read the existing records first, so nothing is overwritten.
Send and receive a test message before any website form uses the address.
Prompt to copy
Make an email DNS checklist for [DOMAIN] and [EMAIL PROVIDER]. Use placeholders until I give you the provider's exact values. List the records it needs, check them against the existing records, and flag any conflict. Wait for my yes before any change.
Decide what you want to count before you choose a service.
Update the privacy policy to say what is counted, before the script goes on.
Sign up yourself, and use the script the service gives for your site.
Name each event, then create a goal under exactly the same name in the dashboard.
Test each event. Read the counts as a little low, since ad blockers hide some visits.
Prompt to copy
Compare [ANALYTICS SERVICE]'s current documentation with what I want to measure: [EVENTS]. List what data it collects and where it goes, and draft the privacy policy wording for me to review. Draft the event names and a test plan for the sandbox. Do not add the script until I approve.
Give every page its own title and description, and one main heading.
Point the canonical tag at the address the site actually serves.
Add an Open Graph picture for link previews.
Publish a sitemap.xml, and a robots.txt that points to it.
Keep canonicals, redirects and internal links on the same addresses.
Prompt to copy
In [SANDBOX PATH], check every page for its own title and description, one h1, alt text, a canonical address that matches the address served on [DOMAIN], an Open Graph picture, the sitemap and robots.txt. Report every mismatch and wait for my yes before changing anything.
Describe only what a visitor can see on the page: the business, its FAQ, its courses or prices.
Generate the JSON-LD with a script from the page content, never by hand.
Add a gate that fails the release when the data goes missing or claims something the page does not show.
Prompt to copy
In [SANDBOX PATH], draft JSON-LD for [PAGES] from the facts visible on each page only. Generate it with a script, and add a check that fails when data is missing or claims anything the page does not show. Do not invent ratings, prices or answers.
Write FAQ answers to the questions people actually type into AI tools.
Put an llms.txt at the root listing your pages and prices, served as plain text.
Decide in robots.txt which AI crawlers may read the site.
Audit the draft, then audit again once the site is live.
Prompt to copy
Review [PAGES] in [SANDBOX PATH] for clear answers to the real questions my visitors ask, and check that the business details match everywhere. Check robots.txt and llms.txt. List the questions the site does not answer yet.
Skill
searchfit-seo:ai-visibility checked whether my site came up for its own name and read its local signals. /ai-seo:ai-seo-audit audited the draft, and again once it was live. Without them, ask Claude Code to check the same signals and list the questions the site leaves unanswered.
Generate the FAQ data, then the main structured data, then the sitemap last, so its dates are right.
Run the site audit and the SEO gate.
Compare the release with the last approved one, so nothing goes out you did not approve.
Scan for client names, private details and keys.
Copy the result into a dated release folder, which is also your rollback.
Prompt to copy
Prepare a release from [SANDBOX PATH]. In this order: generate the FAQ data, the structured data, then the sitemap. Run [AUDIT] and [SEO GATE]. Compare every file with [LAST RELEASE] and list each difference. Scan for private details, keys and client names. Then copy the result to a dated release folder and stop for my review.
Skill
None. Claude Code wrote the scripts for this chain; ask it to run them in order.
Deploy only the release you approved, from its release folder.
Name the site ID in the deploy command.
Check the live site with plain page requests only: the home page and the pages that changed.
Run no tests, scans or load checks against the live site.
If something is wrong, restore the previous release.
Prompt to copy
Show me the exact deploy command for [RELEASE FOLDER] to [SITE ID] and what it will change. Wait for my yes. After the deploy, open [PAGES] with plain requests only and report what you see. Run no tests against the live site.
Sign in at search.google.com/search-console with the Google account that should own the site.
Add a URL prefix property and choose HTML file verification. A Domain property needs a TXT record instead.
Give Claude Code the Google file to put in the site root; deploy, and check it opens live. Then click Verify.
Keep that file in the site for good. Google checks it again later.
Submit sitemap.xml, then use URL Inspection and Request indexing for the pages that matter.
Prompt to copy
Put the Google verification file [FILE] in the root of [SANDBOX PATH] and include it in the next release. After I deploy, check that it opens at [DOMAIN]/[FILE]. Then give me the steps to submit [SITEMAP] and request indexing for [PAGES].
Have Claude Code make an IndexNow key file at the site root, and a script that sends the changed addresses.
Make the script check the key file is live before it sends anything.
Run it after every deploy, then check in Bing Webmaster Tools that the addresses arrived clean.
Brave runs its own index: submit your site at search.brave.com/submit-url.
Prompt to copy
Set up IndexNow for [DOMAIN] in [SANDBOX PATH]: a key file at the root and a script that checks the key file is live, then sends the changed addresses from the sitemap. Show me the exact addresses before it sends them.
Sign in at business.google.com and look for profiles that already exist before you make one.
Keep one profile. Remove any duplicate yourself: open it in Business Profile Manager, click the three dots, choose Business Profile settings, then Remove Business Profile.
If you work at clients’ offices or online, set it up as a service area business with no street address.
Write the description from facts on your website, list the services, set the hours and check the website address.
Verify the profile yourself, by video or phone. Add a booking link once it is verified.
Ask people you have worked with for real reviews.
Prompt to copy
Draft my Google Business Profile from the facts on [SITE]: a description in plain words, the services and the categories. Use only what the site says. I will enter it, verify the profile and handle any removal myself.
Write a fixed set of questions your customers would ask an AI tool.
Run them in the same tools each month, in a fresh chat, in the same week.
Log whether your site is named or cited, and which sources were.
Where you are missing, add a section to the site that answers that question.
Prompt to copy
Build a monthly AI answers sheet for [SITE] and [AUDIENCE]: questions drawn from what my visitors need, one wording each, with columns for tool, date, named or cited, and sources shown. Leave the results empty for me to fill in.
Skill
/ai-seo:ai-seo-audit built my question sheet. ai-seo:ai-answer-gap compared one AI answer with my page and found the missing passage. Without them, ask Claude Code to draft the sheet, and to compare an answer you paste with your page.
Look at it as a picture, on desktop and on a phone.
Run the release checks and compare with the last release.
Get your own yes, then deploy.
Check the live pages with plain requests, and send the IndexNow ping.
Keep the previous release for rollback.
Prompt to copy
For [CHANGE], work in [SANDBOX PATH]: make the change, show me desktop and phone pictures, run the release checks, compare with [LAST RELEASE] and list the differences. Stop for my yes before anything goes live.
