Run a pre-send gate

Sending the link is the one step you can't take back. Once the client has it, what's on the page is what they saw, and anything a search engine found is already found.

So before any build leaves you, it goes through a gate. A gate is a fixed checklist, the same every time, that the build has to pass before you send it. The fixed part matters. A list you make up on the day catches what you happen to be worried about that day, and what goes wrong is usually the thing you weren't worried about.

Here's the shape of mine. Each line is a check with a clear pass or fail, and almost every one points at a skill you've already met. Placeholders and claims come from never inventing a fact. The sweep is the responsive lesson. Keyboard and contrast come from accessibility. Then search and indexing, then forms, and a sign-off line that records who ran it and on which commit, so a pass still means something next month. Both of the incidents you've just heard about would have been stopped by a line on this list.

Placeholders get their own step, because your eyes will slide straight past them. You've read that page twenty times. So search for them instead of looking. Run a search across the built site, the files that actually get served, for your placeholder marker and for anything in square brackets. If it returns a single line, the build doesn't go. Fill it with a confirmed fact, or take the sentence out.

Search checks belong in the gate too, and a launch build has its own set. Every page has its own title and description. Each page lives at one address. The sitemap lists the real pages. Structured data states only what you've verified, because schema is a claim like any other. And the noindex you used on review builds is gone, which is an easy one to forget. For the mechanics behind each of these, Google's SEO Starter Guide is the place to learn them.

A review build is the opposite case. It has to stay out of search, and you check that on the live address, not in your code. Two facts make the difference. Google says that if robots.txt blocks a page, its crawler never sees the noindex, and the page can still turn up in results. And on Vercel, preview deployments get a noindex header automatically, but the current production address ending in vercel dot app doesn't. If your review link is a production deployment, nothing has been added for you.

This is the whole check. Ask the live address for its headers and look for the robots header. Then fetch the page itself and look for the robots meta tag. My gate asks for both. Two lines of output, and if either one is missing, the build isn't ready to send.

When a line fails, the build doesn't go. Fix the failure where it started. Then run the whole gate again, from the top. A fix in one place can break something in another, and a gate you only half re-run has stopped being a gate. Then sign it, with the commit it passed on.

You can ask an agent to run every command on this list, and you should, because it's faster and it doesn't get bored on line seven. But the sign-off is yours. Read what each check returned before you tick it. An agent that reports all clear without showing you the output is telling you a story about a pass.

Nothing leaves without passing the same list. Search for placeholders, check noindex on the live address, and send only on a pass.