The WordPress pre-launch checklist (so you don't ship invisible)

Launch day is loud. There is a domain to point, a cache to clear, a client or a boss refreshing the homepage, and a dozen small fires to put out before anyone notices them. It is the worst possible moment to be careful, which is exactly why the embarrassing misses happen then. The site goes live, everyone celebrates, and a setting that should have been flipped weeks ago sits quietly doing the wrong thing for the next two months.

Most pre-launch failures are not dramatic. They are not hacks or crashes. They are defaults left at their factory position, the ones that are correct while you build and wrong the instant you go public. This is the short list worth walking before you announce anything, ordered roughly by how much each one costs when you miss it.

The one that costs you months: search engines blocked

Start here, because it is the most expensive mistake on the list and the easiest to make. Under Settings, Reading, WordPress has a checkbox labeled "Discourage search engines from indexing this site." You almost certainly checked it on purpose while the site was under construction, which was the right call. The problem is that nothing reminds you to uncheck it on launch day.

Left on, that box tells Google and everyone else to stay away. The site is live, the content is good, the links are shared, and none of it gets indexed. There is no error, no warning banner, no broken page. Everything looks perfect. You simply do not exist in search, and the usual way people discover this is months later, when someone asks why the site never shows up for its own name.

RecapWP flags this as critical, the loudest level it has, because the damage compounds silently for as long as it goes unnoticed. It also carries a one-click fix that re-enables visibility for you, so the gap between finding it and closing it is a single action rather than a hunt through wp-admin.

Debug mode and the file editor

Two more environment settings live in the same category: correct during development, wrong in production.

The first is debug mode. With WP_DEBUG on, WordPress is helpful in exactly the way you want while you build and dangerous in exactly the way you do not once you are public. Errors and warnings can print straight to the page, which can leak file paths and internal details to anyone who triggers them. RecapWP flags debug mode left on in production as high severity. This one is detect-only: the plugin shows you the finding rather than touching your configuration, because where and how that flag is set belongs in your environment, not in a setting a tool should silently flip.

The second is the built-in file editor, the one under Appearance and Plugins that lets you edit theme and plugin code from inside the dashboard. It is convenient and it is a liability: anyone who reaches an admin account can rewrite your site's code from a browser, no server access required. RecapWP flags an enabled file editor as medium, also detect-only, so you can decide whether to disable it as part of your launch hardening.

Close the security basics before you go public

Hardening is easier to do before launch than after, because nobody is relying on the site yet and a change that breaks something only inconveniences you. A handful of exposures show up on almost every fresh WordPress install, and each is a one-click fix in RecapWP.

XML-RPC ships enabled and is a legacy remote-access endpoint most modern sites never use. Left open, it is a standing target for brute-force attempts. The WordPress version on display sits in your page source and feed by default, which is harmless until a vulnerability is disclosed for that version and automated scanners start reading it as a targeting list. Missing security headers leave the browser without the instructions that quietly close a category of clickjacking and content-type tricks.

Then there is the housekeeping. Browsable folders and stray install files mean your uploads directory or the files WordPress leaves behind are listing themselves to anyone who visits the URL. And username enumeration, left on, confirms valid usernames through author archives and the REST API, handing an attacker the first half of every login attempt for free. All of these are deterministic configuration changes, so each carries a one-click fix that writes the change and records it, ready to reverse later if you ever need to.

Launch is the one day everything gets checked at once. It is also the one day you are too busy to check anything. A list you trust is the difference.

HTTPS and the mixed-content trap

By now a fresh site should be running on HTTPS with a valid certificate. RecapWP flags a site not using HTTPS, and a certificate that is close to expiring, as detect-only findings. That is deliberate: moving a site to HTTPS or renewing a certificate is infrastructure that you and your host control, not something a plugin should reach in and change on its own. The plugin's job here is to make sure you see it before your visitors do.

There is a subtler version of the same problem that does carry a fix. Mixed content is when an otherwise secure https:// page loads an asset, an image, a script, a stylesheet, over plain http://. The padlock breaks, browsers throw warnings, and some of those assets get blocked outright, so the page looks half-built to the people you most want to impress on day one. It is a common side effect of migrating a site or importing content, and it is easy to miss because the page often looks fine in the browser you built it in. RecapWP detects mixed content and offers a one-click fix.

The last step: scan, then clear it worst-first

Every item above is something you could check by hand if you had a quiet afternoon and a perfect memory. The point of a checklist is that launch day gives you neither. So the recommended last move before you announce anything is the dull, reliable one: run a full scan and read the findings worst-first.

Worst-first matters because it puts the critical search-engine miss at the top, ahead of the medium-severity housekeeping, so the thing that would cost you months gets your attention before the thing that costs you nothing. Detection and the fixes are deterministic, the same site returns the same findings every time, so the list is a checklist you can actually trust rather than a guess. Close the one-click fixes, note the detect-only items for your environment, and you launch knowing the doors are shut.

None of this is glamorous, and that is the point. The best launches are the ones where nothing surprising happens afterward, because the surprises were all found and dealt with the day before. The fastest way to see your own pre-launch list is to run a scan and look at what comes back.