BuildWithHumza Go Live Check

A common launch slip is easy to miss. A site is built on staging with “Discourage search engines from indexing this site” ticked, it goes live, and nobody unticks it. The site looks normal to visitors, but it asks search engines not to index it, and the only sign is a short line in the dashboard’s At a Glance box.

BuildWithHumza Go Live Check adds one page under Tools that looks for that and nineteen other launch leftovers, scores the site out of 100, and tells you exactly where to fix each one.

It changes nothing. It only reports.

What it checks

Search engines

• Search engine visibility – whether the site is still asking search engines not to index it
• robots.txt file – whether a real file in the site root blocks every crawler, which overrides the Reading setting and is invisible in the dashboard
• Permalinks – still set to plain, so URLs look like ?p=123

Security

• Secure connection – whether the site address is still plain http
• Debug mode – whether WP_DEBUG is on, and whether errors are being printed to visitors along with your file paths
• Guessable usernames – accounts called admin, administrator, root, test and the rest of the list bots try first
• Open registration – anyone can register, and what role they are handed when they do
• Built in file editor – whether DISALLOW_FILE_EDIT is set

Configuration

• Site address – whether WordPress still thinks it lives on a staging, local or IP address
• Site title – empty or still a placeholder
• Site tagline – still “Just another WordPress site”, which many themes print in the header
• Site icon – missing, so browser tabs show a blank placeholder
• Administration email – still a placeholder address, so password resets and update notices go nowhere
• Timezone – never set, so scheduled posts fire at the wrong local time

Leftover content

• Default post – the “Hello world!” post still published
• Default page – the “Sample Page” still published
• Default category – posts still filed under “Uncategorized”
• Privacy policy – not set, or set to a page that was never published
• Comment moderation – comments open with nothing held for approval, so the first spam run publishes itself

Maintenance

• Pending updates – core, plugin or theme updates already waiting at handover

A score, and a report you can send

Every run produces a score out of 100. Critical checks weigh three times a recommendation, so the number moves for the things that actually matter.

Copy report puts a plain text summary on your clipboard, ready to paste into an email. Download report saves a standalone HTML page named after the site and dated: it opens in any browser with no stylesheet to fetch, and printing it saves a tidy PDF. Both are written for somebody who does not have a login.

Set a check aside

Some findings are deliberate. A brochure site with no comments does not need a privacy policy warning forever. Set aside removes a row from the score and parks it at the bottom of the report, marked as a decision rather than an oversight, and one click brings it back.

In the places you already look

The findings also appear in Tools > Site Health, and as a dashboard widget with the score and the three worst rows. If a check fails at the critical level, administrators see one notice with a link to the report, which can be dismissed for good.

For developers

wp go-live-check run
wp go-live-check run --format=json
wp go-live-check run --failures-only

The command exits with an error when a critical check fails, so it can gate a deploy script. Add --format=markdown or --format=html for the same report the browser produces.

Two filters are available. bwh_glc_checks registers or removes a check, and bwh_glc_capability changes who may see the report.

Why not just use a checklist

A written checklist relies on you remembering to open it, and on being honest about ticking items you did not actually verify. This reads the site’s real configuration every time you open the page, so it reports what is actually set, not what someone remembers setting.

It is also useful on sites you did not build. Open it on an inherited site and you will know in a few seconds whether the previous developer left anything behind.

Accurate about debug mode

WP_DEBUG on with `WP_DEBUG_DISPLAY` off is a normal production setup for sites that log errors to a file. That combination is reported as a recommendation, not a failure. Only errors visible to visitors are treated as critical, because that is what leaks file paths and stack traces.

Careful about false alarms

The default post check matches the exact title, so a real article that happens to contain the words “Hello world!” is not reported. Drafts are ignored, because nobody can see them. The staging address check matches whole labels in the hostname, so dev-site.example.com is flagged and devonplumbing.co.uk is not. A robots.txt that blocks one directory or one scraper is left alone; only a blanket block aimed at every crawler counts.

Privacy

This plugin makes no external requests, loads no remote scripts and includes no tracking. The update check reads the data WordPress already keeps rather than asking wordpress.org anything. It stores one option holding the checks you set aside, and one user setting when you dismiss the notice. Both are removed when you delete the plugin.