A few years ago, at an agency I worked at, we launched a corporate WordPress site by migrating the whole database from our development environment to production. The demo had looked perfect. The client had signed off.
The reports started coming in almost immediately — first from our own post-launch review, then from the client's side as they clicked through their brand-new site. Buttons that led nowhere. Images that wouldn't load. Our local dev URLs were hardcoded all over the site: pasted into button links, baked into image paths. Nothing had looked wrong, because on our machines, those URLs worked fine.
Three of us spent the rest of that day clicking through every single page, hunting for leftovers. We fixed what we found and quietly hoped we'd found them all. No one yelled at us. The consequence was quieter than that, and heavier: the string of post-launch defects was treated as a formal incident, with a permanent entry in the company's internal incident list. That entry doesn't expire. As far as I know, it's still there.
The handoff problem
Handoff is the moment responsibility changes hands — the most dangerous, and the most important, moment in the entire project.
Clients trust the agency. They take it for granted — as they should — that the site they're receiving is solid. But that trust is easier to betray than anyone likes to admit. The moment a client finds a defect, doubt creeps in. However hard the team worked, a single careless leftover is enough to make them wonder: what does the quality of this site really look like?
There's a structural reason this happens. While you're building, you're in the admin every day — you'd notice a stray test post, a debug flag, a weird setting. After handoff, the person in the admin is your client. They edit content, upload images, and take everything at face value. The leftovers that were invisible in the demo are now their discoveries.
Most launch checklists focus on whether the site works. A handoff checklist asks a different question: what will the client find that I should have found first?
Here's the list I wish I'd had back then. Every item includes how to check it manually — no tools required.
1. Content cleanup
Test posts. About an hour after one delivery, a chat message arrived from the client: "What is this 'test test' page?" Chat messages don't carry tone, but I could feel the reaction through the screen. Test content is harmless to the site and terrible for trust.
How to check: In the admin, go to Posts and Pages, sort by date, and scan for anything you created as filler — "test", lorem ipsum, placeholder drafts. Don't forget custom post types and the trash.
Unused media. On another project, a stock photo was still carrying the vendor's watermark — we had never replaced it with the licensed version. The client spotted it right before delivery, which is one step better than after delivery, and still one step worse than us spotting it ourselves.
How to check: Open Media Library, switch to list view, and go through everything uploaded during development. Look for placeholders, duplicates, screenshots, and anything watermarked.
Temporary pages. Style-guide pages, block catalogs, layout sandboxes — anything you built for your own reference.
How to check: Pages → All Pages, review anything the client never asked for.
2. Launch settings
Search engine visibility (the noindex trap). This one has two layers, and the second one almost got me. The obvious layer is Settings → Reading → "Discourage search engines from indexing this site" — staging environments have it on, production must not. The sneaky layer is your SEO plugin: on one site, the Reading setting was fine, but a noindex rule was still sitting in the SEO plugin's configuration from the staging days. Weeks of indexing time are lost this way, silently.
How to check: Verify the Reading setting, then open your SEO plugin's settings and check its index rules. Finally, view the page source of the live homepage and search for noindex in the <meta name="robots"> tag — that's the ground truth.
WP_DEBUG. Debug mode on a production site can print warnings — with file paths — right onto the page for every visitor.
How to check: Open wp-config.php and confirm WP_DEBUG is false.
Admin email. If the site's admin address is still yours, the client's password resets and system notices go to you forever.
How to check: Settings → General → Administration Email Address.
Permalinks / rewrite rules. After a migration, stale rewrite rules are a classic source of unexplained 404s.
How to check: Settings → Permalinks → Save Changes (yes, just re-saving flushes the rules), then click through a few posts and archive pages.
3. Security loose ends
Four small things that take five minutes total and are exactly the kind of leftovers a security scan (or a curious visitor) finds later:
-
File editor —
DISALLOW_FILE_EDITinwp-config.phpdisables the built-in theme/plugin code editor. A client account clicking around in there is a risk nobody needs. - XML-RPC — if nothing uses it (Jetpack, some mobile apps), it's an open door for brute-force amplification. Disable it via filter or plugin.
-
debug.log — a
wp-content/debug.logfile left web-accessible is a quiet information leak. Delete it and confirm logging is off. -
The 'admin' username — a default
adminaccount is half of a credential-stuffing attempt already solved. Rename or replace it.
4. Site health before delivery
Outdated plugins. Taking over or delivering a site with plugins that haven't been updated on WordPress.org in over a year means handing the client a maintenance liability without telling them.
How to check: For each installed plugin — including inactive ones — check its "Last updated" date on its WordPress.org page. Flag anything past 6 months; treat anything past a year as a conversation you need to have with the client before handoff, not after.
Inactive plugins. They still ship code. If it's not needed, it shouldn't ship.
How to check: Plugins → Inactive, and delete what has no reason to stay.
5. Beyond the basics
Depending on the hosting stack, a few more things deserve a look — these are harder to automate, which is exactly why you want the basics above done quickly and reliably:
- Cache purge after the final content change. A page cache that never got purged will serve the old price, the old phone number, the old everything — with zero errors logged.
- Leftover staging credentials. Test admin accounts and staging logins have a talent for surviving into production.
- Hardcoded dev URLs in the database. My opening story. A search-replace pass over the database (with a proper serialized-data-aware tool) before launch would have saved us an afternoon of page-by-page hunting — and a permanent line in an incident log. How to check: Don't trust the search-replace tool alone. Click through the primary navigation, footer links, and CTA buttons on the live site — and open a few image-heavy pages — right after migration.
6. The missing step: prove what you checked
Here's the part almost no checklist talks about.
Running the checks protects the site. Showing the checks protects the relationship. A client can't see the noindex flag you flipped back or the debug log you deleted — to them, a clean launch and a lucky launch look identical. The difference only becomes visible when something breaks.
So make the invisible work visible. Before handoff, write a short plain-text delivery note:
Pre-launch verification — example.com — 2026-07-02
✓ Test content removed (posts, pages, media)
✓ Search engine indexing enabled (Reading settings + SEO plugin + meta verified)
✓ WP_DEBUG disabled
✓ Admin email set to client
✓ File editor locked, XML-RPC disabled, no debug.log present
✓ Default 'admin' username: not present
✓ Plugin update status reviewed (2 flagged, listed below)
Attach it to your delivery email. It takes ten minutes, it reads as professionalism, and months later — when someone asks "was this checked?" — you have an answer with a date on it.
7. The checklist (copy-paste version)
## Content cleanup
- [ ] Test posts/pages deleted (incl. custom post types & trash)
- [ ] Unused media removed (placeholders, duplicates, watermarked images)
- [ ] Temporary/reference pages removed
## Launch settings
- [ ] Reading settings: search engine indexing allowed
- [ ] SEO plugin: no leftover noindex rules
- [ ] Live page source: no unexpected noindex meta tag
- [ ] WP_DEBUG = false
- [ ] Admin email = client's address
- [ ] Permalinks re-saved (rewrite rules flushed)
## Security
- [ ] DISALLOW_FILE_EDIT set
- [ ] XML-RPC disabled (if unused)
- [ ] debug.log deleted, logging off
- [ ] No default 'admin' username
## Site health
- [ ] All plugins (incl. inactive) checked for last-updated date
- [ ] Unneeded inactive plugins deleted
## Beyond the basics
- [ ] Cache purged after final changes
- [ ] Staging/test credentials removed
- [ ] Database search-replace for dev URLs done
- [ ] Site clicked through (nav, footer, CTAs, image-heavy pages) — no broken links or images
## Prove it
- [ ] Plain-text delivery note written and attached
One more thing
You can run this whole list manually — copy the markdown above into your project notes and it's yours.
I'll be honest about why I wrote this: I kept making these mistakes myself, so I also built a free WordPress plugin called Noshi-Kanamer that automates a good chunk of this list — it detects leftover test content, noindex (including SEO-plugin and code-level rules), WP_DEBUG, debug.log, the default admin username and more, then generates a plain-text handoff report you can paste straight into your delivery email. The checklist above works fine without it. The plugin just makes the boring parts fast.
Either way — check before you hand over the keys, and leave a note that proves you did.
Top comments (0)