The site works. The forms submit. The pages look right. Is it ready to publish?
That's usually the point where I stop and do a separate launch check.
Is a vibe coded WordPress site safe to publish?
A vibe coded WordPress site can be safe to publish. A working site can still have launch settings or leftover development files that need attention.
For client work, there's another question too: can someone else run the site after you hand it over?
Why these get missed
Those checks often aren't part of the build request, so they can easily be missed at the end.
What to check before you publish
These aren't every pre-launch check a WordPress site needs. They're the WordPress-specific ones that are easy to miss in AI-assisted builds, the kind that don't show up when you're just clicking through the site to see if it works.
Search engine visibility. Settings → Reading has a checkbox that tells search engines not to index the site. If you're using it to keep the site out of search during development, it needs to go back off before launch. It's easy not to notice until someone asks why the site isn't appearing in search.
The default admin username. If an account named admin still exists, an attacker trying to log in doesn't have to guess the username, only the password. Create another administrator account, then remove the old admin account, rather than leaving both in place.
WP_DEBUG left on. In wp-config.php, this should be false in production unless you've set up deliberate logging. Left on, it can print warnings, including file paths, straight onto the page for anyone to see. Setting WP_DEBUG_DISPLAY to false prevents those messages from being shown on the page.
A leftover debug.log file. Turning debug mode off doesn't delete the log it already wrote. Depending on your server configuration, /wp-content/debug.log may be publicly reachable. Check whether it's still there and delete it if it is.
DISALLOW_FILE_EDIT not set. One line in wp-config.php removes the built-in theme and plugin code editor from wp-admin. Most production sites don't need it enabled.
XML-RPC left enabled. Some setups need it (Jetpack, certain mobile apps). If your setup doesn't use it, turning it off removes an endpoint you don't need to expose.
Keeping track of all of it
Most of these checks take less than a minute. Checking the Reading setting takes ten seconds. Deleting a debug.log takes one click.
The hard part is remembering them consistently, especially the ones that don't cause visible problems. A site accidentally left noindexed doesn't crash. A stray debug.log doesn't show up in a screenshot. The site can look finished either way, so these checks are easy to skip.
My launch routine is simple: check, clean up what needs cleaning, and keep a record of what you checked. A record is useful later when a client asks what was verified. "I'm pretty sure I did" is a weaker answer than a dated note that says so.
Where Noshi-Kanamer fits in
That's basically the workflow I ended up building into a small WordPress plugin.
Noshi-Kanamer is free, and its Pre-Launch tab checks the status of all six items above automatically. For XML-RPC, it flags whether the interface is left open. Whether you actually need it on is still a call only you can make. It can also generate a plain-text report, which I use as a record of the launch checks.
It doesn't replace the judgment calls: whether your permalink structure makes sense for the site, whether a page's copy is proofread, whether XML-RPC is actually needed for your setup. Noshi-Kanamer can't decide those for you. I use it for the boring checks and cleanup I don't want to keep in my head.
For the full picture, this article covers 6 items out of a longer list. I keep a 25-point WordPress launch checklist covering content, SEO, security, cleanup, and client handoff, if you want the complete version.
