“Is the site ready to launch?” is usually answered by a feeling. It should be answered by evidence. Turn the launch checklist into a short set of gates a script can verify the same way every time, and “ready” stops being an opinion.
robots.txt and the sitemap resolve, no site-wide noindex), legal (privacy, about, and contact pages are published and linked), navigation (every menu link resolves – no 404s), content (enough real articles, no leftover theme demo content or orphaned widgets), ad-readiness (ads.txt resolves and names your account, and the ad network’s crawler can reach the site), and render (the homepage returns 200 with real content and a made-up URL returns a real 404). Run each as an anonymous probe, emit a GO / NO-GO with the evidence per line, and never mark an operator-only item (backups, analytics, catalog correctness) as passed just because a script can’t see it.Wall returns 503, never a bare 200.
robots + sitemap ok, no site noindex.
Privacy, about, contact published.
Every menu link resolves (no 404).
Real articles, no demo or widget residue.
ads.txt resolves, crawler can review.
Homepage 200, 404 is a real 404.
Verify every public-facing gate anonymously – a maintenance plugin exempts the logged-in admin.
Table of Contents
Why a method beats a feeling
A launch has too many preconditions to hold in your head, and the failures are quiet: a maintenance wall that returns 200 gets the placeholder indexed; a menu link that 404s after a permalink change sits broken for weeks; a missing privacy page fails an ad-network review with no obvious reason. A method – the same probes, run the same way, emitting evidence – catches these before a visitor or a reviewer does, and catches them again on every re-check after you fix something.
A launch checklist you tick by feel is a checklist you will skip a line on. One a script runs is one you can trust twice.
Gate A – maintenance returns 503, not 200
While a “coming soon” wall is up, the page it serves must return HTTP 503 (Service Unavailable) with a Retry-After header, not a 200. A 200 tells search engines the placeholder is the real content, and they will index “Site under maintenance.” This is the single most common launch-hygiene miss – enough that it deserves its own deep dive on the 503 status. A wall also covers only what the theme renders; if the site must stay private until launch, close the REST API too.
Gate B – the site is indexable at launch
Flip the corollary at go-live: robots.txt resolves and doesn’t block the whole site, the sitemap is declared and reachable, no page carries a site-wide noindex meta or X-Robots-Tag header, and WordPress Reading settings have “discourage search engines” off. One stale checkbox here keeps a finished site invisible for months.
Gate C – the legal and trust pages exist
Publish and link, at minimum, a privacy policy, an about page, and a contact page; an ad-supported site also needs an advertising or affiliate disclosure. Set WordPress’s designated privacy page so the core links resolve, and confirm the footer actually links to each one. This gate is binary – the page either returns 200 or it doesn’t – but the adequacy of the text is a human review, not a script’s call. (For what those pages should contain on a directory or comparison site, see the legal dos and don’ts.)
Gate D – every navigation link resolves
Pull each item from the menu and request its URL. Custom-link menu items hardcode a path and rot silently after a permalink or category-base change, so a menu that looked fine at build time can be full of 404s at launch. Any menu link that doesn’t resolve is a blocker: it is the first thing a visitor clicks.
Verify every public-facing gate while logged out. A maintenance plugin exempts the admin, so an authenticated check can show you a clean site the public never sees.
Gate E – real content, no demo residue
Two things here. First, a content floor: enough published articles that the homepage isn’t padded and an ad network sees a real site. Second, no theme demo content – the demo posts, placeholder menus, and builder banners that shipped with the theme must be gone. That cleanup is a whole audit of its own. Sweep up the quieter leftovers too: orphaned widgets the theme registered but no longer displays, and surplus menus no location uses. They don’t render, so they never show up in a visual check, but they clutter the admin and confuse the next cleanup – list them as a hygiene warning, not a launch blocker. While you’re counting, watch for repetition: if the homepage has more article “slots” than you have articles, the same posts repeat across blocks – trim blocks or publish more. Fast pages help the launch land too – see WordPress speed optimization – and confirm featured images carry their full size ladder.
Gate F – the ad network can verify you
If the site launches to carry ads, the network has to confirm the inventory is yours before it will serve them. The checkable part is ads.txt: it must resolve at the domain root (/ads.txt), return 200, and carry the authorized-seller line the network gave you. A missing or 404ing ads.txt, or one that still lists a previous owner, quietly blocks monetization. The other half is reachability: the ad network’s crawler has to be able to fetch your pages, so a site-wide noindex or a maintenance wall that 503s everything will also stall the ad review – which is why this gate runs after the wall comes down. Whether the account is actually approved is an operator-only check; the script can only confirm the file resolves and the pages are reachable.
Gate G – the homepage and 404 both render
Two quick anonymous probes catch the embarrassing basics. First, the homepage returns 200 with real content – not an empty page-builder frame, a redirect loop, or a white screen. Second, request a URL that cannot exist (append a random string) and confirm it returns a real 404: the HTTP status is 404 and a usable “not found” page renders. A soft-404 – a missing page that returns 200 – lets search engines index your error page, and a broken 404 template greets every mistyped link with a blank screen.
A site can pass every content and legal gate and still greet a mistyped URL with a blank page. The cheapest gate just asks each page to load.
What the audit will not do
The audit is read-only and honest about its edges. It won’t remove the wall, publish pages, or change settings – those stay operator-gated. And it can’t verify operator-only items: backup restores, cache configuration, analytics actually firing, catalog correctness, or whether the legal text is any good. List those as operator-only, never as passed – silence must never read as “done.”
The short version
Make the launch decision from evidence, not a feeling. Run seven anonymous gates: the maintenance wall returns 503 (not 200), the site is indexable (robots, sitemap, no noindex), the legal pages exist and link, every menu link resolves, there is enough real content with no theme demo residue, orphaned widgets, or homepage repetition, ads.txt resolves for the ad network, and the homepage and 404 page both render. Emit a GO / NO-GO with the evidence on each line, verify every public-facing gate while logged out, and list operator-only items (backups, analytics, catalog) as operator-only rather than passed.
Frequently Asked Questions
What is a go-live audit for a WordPress site?
It is a repeatable, evidence-based check of a site’s launch preconditions – maintenance response, indexing, legal pages, navigation, and content – run the same way every time so “ready to launch” is a verified state rather than an opinion. Each gate records the URL, status, or count it checked.
Which launch checks can be automated and which can’t?
Anything with an observable signal can be automated: HTTP status, headers, page existence, menu URLs, post counts. Operator-only items – backup restores, cache pinning, analytics firing, catalog correctness, and the adequacy of legal text – can’t be verified by a probe and should be listed as operator-only, never marked passed.
Why run the checks anonymously instead of logged in?
Many maintenance and membership plugins exempt logged-in administrators. An authenticated request can return the finished page while anonymous visitors and crawlers still get the wall or a demo view. Verify every public-facing gate logged out so you see what the public sees.
How many articles should a site have before launch?
There’s no universal number, but the practical floor is “enough that the homepage looks full without repeating posts, and an ad network sees a real site rather than a template.” If your homepage has more article slots than published posts, either publish more or trim the layout.
Does the maintenance page really need to return 503?
Yes. A 200 tells search engines the “under maintenance” placeholder is the page’s real content, so it can be indexed. A 503 with a Retry-After header tells them to come back later, protecting your rankings while the wall is up.
What is ads.txt and why check it at launch?
ads.txt is a plain text file at your domain root that lists which accounts are authorized to sell your ad inventory. If a site launches to carry ads, the network needs that file to resolve and to name your account before it will serve or pay for anything. The gate confirms /ads.txt returns 200 with the right line; whether the account is approved is a separate operator check.
