The prelaunch playbook

A site is ready when a check that can fail says so.

Most launches end with somebody clicking around the new site on their phone, saying it looks good, and flipping the switch. That catches the problems a person notices. The expensive ones are the problems nobody sees.

A missing redirect doesn't look like anything. A page that tells Google not to index it looks exactly like a page that doesn't. Schema with the wrong phone number is invisible. An AI assistant that can't read your site never tells you. It just recommends somebody else.

So we stopped launching on "looks good." Here is the sentence that replaced it.

Everything below comes from the first launch we ran this way: a family roofing company in Central Texas, 21 pages, replacing an old WordPress site. The numbers are that site's numbers. Where a number is our own standard rather than somebody's published guidance, hover it and it says so.

Build the checker before you fix anything.

The natural move is to open the site, find what's wrong and start fixing. Don't. Write the checks first, run them on the site as it stands, and let their output be the fix list.

Two reasons. First, once the checks exist, every fix gets a yes or a no instead of an opinion. Second, it's the only honest way to know when you're done. "Done" is when the checks pass, not when you run out of things you remember to look at.

Count it twice, two different ways

Before trusting the checker, we wrote a second, dumb script that just counted the defects on day zero: links that pointed at file paths, images with no description on record, files over the size limit, town links that opened a "coming soon" box. Then the checker had to reproduce every count. It matched 20 of 20. If the two disagree, one of them is wrong, and you find out before it matters.

Break every check on purpose

A check that has never failed hasn't been tested. It might be looking at the wrong page. It might pass everything.

So each of our 51 checks carries its own sabotage: a small, specific defect it plants into a copy of the site. A missing phone number in the schema. A link to a page that doesn't exist. A noindex tag on the wrong page. Then the check runs, and it has to go red.

On the first try, 50 of the 51 went red. The one that stayed green had actually found its defect and reported it in a way the test couldn't see. That's a small bug in a report. It's also exactly the kind of bug that lets a real problem through on launch day, and it would have gone unnoticed forever.

There are three copies of the site, and each one can prove different things.

People say "the site" as if there's one. Before launch there are three, and a check only means something on the copy that can actually answer it.

A speed score from your laptop is not a speed score. A redirect you tested in a text editor hasn't been tested. We let every check run on every copy, but it only counts on the copies it names. Everywhere else it prints a preview and says "pending" instead of pretending to pass.

Seven layers, from the bottom up.

Each layer depends on the one below it. Schema on a page Google can't index is wasted. A fast page nobody can reach is still unreachable. So we fix them in order.

1. Reach. Every link on every page lands on a real page.
2. Index. Google may index every real page, at one address, and only those.
3. Meaning. Each page says what it's for: title, description, headings, the search it answers, its photos.
4. Entity. The business facts in the code match the page and the Google Business Profile.
5. Answers. AI tools can read the site and quote it correctly.
6. Experience. It's fast on a phone and usable with a thumb and a screen reader.
7. Launch. The domain points at the right place, and nothing breaks when the switch flips.

Every link lands, clicked by a real browser.

Don't read the links out of the HTML and trust them. Load every page in a browser and follow every internal link, because that's where the surprises are.

On day zero, our roofing site had town icons on 12 pages that opened a "coming soon" box. The town pages were built. The link-writing function for that one band skipped the step that turns a page name into an address, so the links still thought the pages didn't exist. It looked fine to anybody who didn't click a town.

The rest of this layer is plain housekeeping: no links to pages you haven't built, no page that nothing links to, a real 404 for addresses that don't exist, and one anchor text for one destination.

Tell Google what to index, and where everything used to live.

The checks here are the ones people know about: a robots.txt that welcomes crawlers (AI crawlers included) and names the sitemap, a sitemap.xml with every page that should be found, a canonical tag on every page, and one host. Pick the address with or without www and send the other one to it.

The one people skip is the redirect map. Your new site is replacing an old one, and the old one has addresses that people bookmarked, that other sites link to, and that Google has already ranked. Every one of them needs to land somewhere sensible.

On the roofing site, the live sitemap listed 6 pages. The CMS export found two private pages the sitemap never showed. The Wayback Machine found 37 old addresses that had answered, including a pile of media attachment pages and an old "home-2" copy of the homepage. We ended with 23 redirect rules. We couldn't read Search Console, because the access hadn't been granted yet, so the map says that in writing instead of pretending to be complete.

One more thing for this layer: a draft must stay hidden. Every page on it carries noindex until the day you launch. There's a check for that too, and it flips on launch day, when the rule becomes "every real page is indexable."

Each page says what it's for.

Titles, descriptions, one H1, headings in order, share cards for when somebody texts the link. Our bands are 44 to 60 characters for a title and 150 to 160 for a description. Those are house standards, not Google rules. Google doesn't publish a character limit for either one. It cuts by pixel width, so we aim to fit.

Every page that is meant to be found should answer one search, and the words of that search should be in its title. We check that against the keyword research, and we write down which pages deliberately don't target anything, so the check doesn't nag about them.

We don't write a meta keywords tag. Google has ignored it for years.

Images are where the weight hides

The roofing site carried 19 MB of images on day zero, mostly large JPGs. After the image pass it carried about 9 MB, every file WebP, none over 150 KB, with a smaller copy for phones where it helps.

The bigger fix wasn't the file size. It was the words. Every photo got one record, written by somebody who opened the photo and described what's actually in it. The alt text, the filename, the caption in the schema and the image sitemap entry all come from that one record. 61 images had no record on day zero, so 61 photos got looked at.

Icons that sit next to a text label are the exception. They get empty alt text, because a screen reader would otherwise say the same thing twice.

The business facts in the code match the page and the map.

Schema is the code that tells Google, in its own format, who the business is: name, phone, address, hours, service area, the profiles it owns. Every page carries it, and the homepage most of all. Ours had none on the homepage on day zero, only on the inner pages.

Two checks matter more than "the schema exists":

• What the code says is on the page. If the schema has a phone number, that phone number is in the visible text. If the schema lists FAQ answers, those answers are on the page word for word. Code that says something the page doesn't is the fastest way to have Google stop trusting it.
• The name and phone match the Google Business Profile. Exactly. The legal name on the profile and the name on the site are often slightly different, and you want to find that before Google does.

What AI tools can read, and how they find it.

This is the layer most sites don't have at all, and it's the one that decides whether ChatGPT, Claude, Perplexity or Google's AI answers can quote you correctly.

An AI tool reading a web page has the same problem you'd have reading one through a straw. Menus, scripts, pop-ups, a slideshow, three copies of the phone number. What it wants is the words. So we give it the words, in the places it knows to look.

We score the result with Vercel's Is Agentic scanner. The roofing draft went from 92 to 100, with all 6 of the scanner's essential checks passing. Three optional checks look for the brand in search results, and those can't pass on a preview address. They get judged on the real domain after launch.

Markdown at the same address, not a second website.

The tidy way to give a tool the words is to answer it at the page's own address. A browser asks for HTML and gets the page. A tool that asks for Markdown (the request header is Accept: text/markdown) gets the Markdown copy. Same address, same canonical, no second site for Google to find.

Three details make it work:

• Send Vary: Accept. It tells every cache between you and the reader that this address has two answers. Without it, a cache can hand the Markdown to a browser.
• A missing page gets a Markdown 404. A tool that asks for a page that doesn't exist should get a real 404 in the format it asked for, with links to real pages, not a 200 and not a wall of HTML.
• Lint the copies like client copy. An assistant will quote them word for word. Ours refuse em dashes, British spellings, relative links that go nowhere, and half-loaded interface text like "Checking availability." Customer reviews are quoted as written and skipped by the spelling check.

Answer first. The tools read the first sentence.

When an AI tool quotes an FAQ, it usually takes the first sentence of the answer. If that sentence is "It depends on a lot of factors," that's the answer your business gives the world.

So every answer opens with the answer. Here are three from the roofing site, before and after:

The facts didn't change. Only the order did. Our check rejects answers that open with "It depends," "Great question," "Every home is different," or "Call us." Changes like these touch the client's own words, so the owner reads every one before launch.

Speed on a phone, measured on the real host.

Google publishes the lines for a good experience: the biggest thing on the screen shows up within 2.5 seconds, and the layout moves no more than a Cumulative Layout Shift of 0.1. On top of that, our standard for a launch is a mobile PageSpeed score of 90 or better for performance and 100 for SEO, taking the middle of three runs, because one run bounces around too much to trust.

How we measure

Google's PageSpeed Insights first. Without a key it shares a daily allowance with everybody else who uses it without a key, and it ran out on us twice for reasons that had nothing to do with us. When that happens, we run Lighthouse, the same engine, on our own machine, with the same phone settings, and write down which one produced each number.

One adjustment on the draft: it's hidden from Google on purpose, so the one SEO audit that only checks "can Google index this" will fail. We skip that single audit on drafts and say so next to the score, so nobody mistakes it for a pass on the real thing.

What actually made it faster

• Loading order, measured and not guessed. Images below the first phone screen load when you scroll to them. The one big image at the top loads first. We don't decide that by reading the code. A script opens every page at phone size, waits for the fonts, sees where each image actually lands and sets it.
• Images the size of their slot. One page was slow because its small thumbnails were loading full-size photos, 800 pixels wide in a 120-pixel box. Lazy-loading everything didn't help. Making 240-pixel copies did.
• An intro animation that doesn't wait. The homepage's top section faded in once every image on the page had finished downloading. Starting the fade as soon as the page arrived brought the main image in on time.
• Headline text that is never invisible. On a phone, the biggest thing on the first screen is often the paragraph under the headline, not a photo. Ours faded in, and Chrome doesn't count text as shown until it can be seen, so four pages scored late with nothing slow to download. The text still slides in. It just never starts at zero.
• Nothing hidden downloads before the first paint. That fix alone wasn't enough, because Google's phone test counts everything the page downloads before the text shows. Ours was fetching a dozen menu icons nobody could see yet, a background photo halfway down the page, and a headline font carrying every weight from thin to black when the site uses two. The icons now wait until the page has loaded and are ready before anyone opens the menu. The photo waits the same way. The font was cut from 122 KB to 80 KB. The slow pages dropped to 2.3 seconds from 2.7, under the line with room to spare.
• Fonts from the site itself. Loading them from Google's font service made the browser wait on another server before showing text. Self-hosting the two files the first screen needs, and telling the browser about them early, fixed that.

At the end, every one of the 21 pages on the roofing draft scored 98 or better for performance and 100 for accessibility, best practices and SEO, and the slowest page showed its main content at 2.3 seconds.

Accessibility lives in this layer too

The speed audit reports accessibility at the same time, and it caught two things a person clicking around missed. Four buttons all said "Learn More," which tells a screen reader user nothing, so each one now carries the service name in text only a screen reader hears. And the new privacy and terms pages had borrowed a style name from the dark footer bar, so both pages showed up nearly black. Look at every new page at phone size and desktop size the day you add it.

When your own testing gets you blocked.

Running three speed tests on every page of a 21-page site is about 63 page loads in a few minutes from one computer. Vercel's protection read that as an attack and started answering every address with a security check page instead of the site.

Spacing the tests 20 seconds apart wasn't enough. It tripped again. What held was telling the host's firewall that our testing computer is allowed through, on that one project only. Two other changes stay in place anyway: a check that gets the security page back says "pending" instead of scoring a zero, because a zero there measures nothing, and every finished page's score is saved as it lands, so a run that gets cut off picks up where it stopped. A full run takes about 45 minutes.

It's worth knowing for launch day as well. A burst of real traffic can trip the same protection.

Prove the deploy didn't change a word.

Between the approved build and the draft, a deploy script does real work. It rewrites links to clean addresses, adds version numbers to files so they can be cached for a year, and adds the Markdown pointer to each page's head. Any one of those can go wrong in a way nobody notices.

So before anything leaves the machine, a test compares the body of every page in the deploy to the body of the same page in the approved build, with every link and image address blanked out on both sides. Then it checks separately that every link and image still points at the same file. One changed word or one changed link fails it, and the deploy stops. On the roofing site: 21 of 21 identical, every time.

The point of this test is that nobody has to remember what the deploy script does. It's allowed to touch addresses and the head. It isn't allowed to touch anything a visitor reads.

Launch day.

By launch day, every check in the first six layers has passed on the draft, and somebody who didn't build the site has run them again and signed off. The builder doesn't grade their own work. Then:

1. Write down the current live version so you can roll back to it in one step.
2. Point the domain. The owner keeps their domain and their DNS provider. They add two records: an A record for the bare domain and a CNAME for www. Nothing else about their email or other services changes.
3. Flip noindex off on every real page. The thank-you page and anything else private keeps it.
4. Send a real form submission from the live site and confirm it reached the owner, not a test inbox.
5. Compare live to the draft, page by page.
6. Submit the sitemap in Search Console.

All of that runs as the seventh layer of checks within an hour of the switch. If any of it fails, roll back first and figure it out second.

The roofing site hasn't launched yet. It's waiting on the owner's go. The first six layers are proven. This one is a plan until it has run for real, and when it has, this section changes.

The stop doing list.

• Launching on "looks good on my phone." It catches what you notice. The expensive problems are the ones you don't.
• Trusting a check you've never seen fail.
• Measuring speed on your laptop. Measure on the real host, middle of three.
• Building the redirect map from the sitemap alone.
• Fixing the built pages by hand. Fix whatever generates them, or the next rebuild undoes it.
• Letting the builder sign off.
• Answering an FAQ with "it depends."
• Hammering the draft with tests. Space them out, or the host blocks you and every score is a lie.
• Writing a meta keywords tag.

Two ways in, and what we still don't know.

If you build the site

1. Audit day zero, read only. Produces the list, written as what a customer would hit. Trap: fixing as you go.
2. Build the checks and break each one. Produces a checker that has proven it can fail.
3. Deploy a hidden draft on the real host. Produces the copy that can answer speed, redirect and AI questions.
4. Fix layers one to four, in order, in the generator. Trap: skipping the image records.
5. Add the AI layer and fix speed. Trap: guessing which images are below the fold.
6. Hand it to somebody else to verify.
7. Launch, run layer seven within the hour, keep the rollback ready.

If you own the trucks

Three questions for whoever is launching your site. You don't need to know how any of it works to ask them.

1. Where did the old site's addresses go? The answer should be a list, and it should name more than one source.
2. What does ChatGPT get when it reads my site? Ask them to show you the plain-text copy of your homepage. If there isn't one, that's the answer.
3. Who checked it besides the person who built it?

What we don't know yet

Most of the numbers on this page are ours: the title and description bands, the speed floor, the image sizes, the twenty-second spacing. The Core Web Vitals lines are Google's. Hover any number to see which kind it is.

We're not claiming that a site launched this way ranks faster or gets named by AI tools more often. We don't have that evidence yet. The Markdown copies and the AI catalog are new enough that nobody outside the tools' makers can say how much weight they carry today. We build them because they're cheap, they're correct, and a tool that can read your site can't be worse off than one that can't. When we have a before and after from Search Console and from AI answer tracking, it goes here, and if the numbers don't move, this section is what changes.