Say a client asks you to change an existing WordPress site. You copy the production site to a local or development environment, do the work there, and push the result back.
That setup is safer than editing a live site, but it creates its own cleanup problem. You have to check what you're sending back, because test posts, debug settings, temporary users, and plugins you installed to trace a bug can all travel to production with the deployment, depending on how you deploy.
Whether you make the changes yourself or hand part of the work to an AI assistant, someone still has to check what will go back to production. A finished task doesn't tell you whether a test post or a debug setting is being deployed too.
This is the process I'd suggest once the requested changes are ready. It picks up where my earlier post on what to check when you inherit a site leaves off.
1. Sort your changes into "goes back" and "stays here"
Start with a list of what you changed on the dev copy. If you kept a note while you worked, you already have most of it. If you didn't, rebuild the list from the site itself: posts and pages sorted by date, the plugins screen, the users list, the media library, and any code you pasted into a theme or a snippets plugin.
Then sort each item into one of two groups. The first is the deliverable: the changes the client asked for, which should go back to production. The second is dev-only leftovers, which should not. The second group is usually the one that gets forgotten:
- Test posts and draft pages made to check a layout
- Plugins installed to debug something
- Temporary admin users or API keys created for a one-off task
- Code snippets added while trying things out
- Settings changed for development, such as debug mode, a disabled cache, or search engines discouraged from indexing
If you catch yourself thinking "I think I made that," put it in a separate "not sure" pile. You'll deal with that pile in step 3.
2. Clean the dev copy before anything goes back
For each dev-only item you're sure you created, pick the mildest removal that works. A page can go to the trash and be restored later. Deactivate a temporary plugin and test the affected pages before deleting it. Permanent deletion is for things that are unambiguous, like test posts you generated yourself and flagged so you could find them again.
Before you deploy, take a fresh production backup so you can restore the state just before deployment. If the deployment includes database changes, check for new production content or submissions before applying them.
Also check what the deployment will do to indexing, logs, and rewrite rules.
Keep search engines discouraged on the dev copy. If the deployment includes database settings, make sure that development setting is not carried over, because it can end up asking search engines not to index the live site. After deployment, check the live site's indexing setting.
If debug logging was enabled while you worked, wp-content/debug.log may hold file paths and error details. If the deployment copies files, that log can land on the live site, and on some setups it can be fetched by URL. Read what you still need from it, then delete it.
If you registered post types or changed a URL structure, re-save the permalink settings (or flush the rewrite rules) after the deployment, so visitors don't hit 404s on pages that exist.
3. Leave alone what was already there, but write it down
This is the hard part. A client's site is full of things you would remove if you had built it: an old inactive plugin, a strange redirect, a page nobody links to. It's tempting to tidy all of it while you have the site open.
Don't, unless removing it is part of the agreed work. You can't tell whether something is a leftover or a decision someone made for a reason you can't see. If you remove it quietly, your cleanup becomes a change nobody approved, and if something breaks later, you're the last person who touched the site.
So the rule is this: if an item was already there and removing it isn't part of the agreed work, leave it in place and record why it needs a decision. The "not sure" pile from step 1 goes here too. If you can't say with confidence that you made something, treat it as not yours.
4. Write the handoff note
The note doesn't need to be long. Three sections cover most of it, plus a short record of what was checked and where:
- Changed: what you changed and why, one line each, plus how you deployed and how to roll back
- Left alone: things that were already there and that you chose not to touch, with the reason
- Worth a decision: things the client or the next developer should look at, such as a plugin that hasn't been updated in over a year, or a setting you weren't sure was intentional
A short one looks like this (an example, not a real site):
HANDOFF NOTE: example.com
Changed
- Updated the pricing page template in the theme
- Replaced the contact form plugin; recreated its settings
- Deployed theme files; applied plugin/form changes separately
- Production database not overwritten
- Production backup taken before deploy (restore point: 2026-10-08)
- Rollback: restore old theme files and plugin/form settings
Left alone
- Inactive "legacy-slider" plugin: may be used by a landing page
- Redirect from /shop to /store: looks intentional
Worth a decision
- 3 plugins not updated in over a year (list attached)
- No backup schedule found on the host
Checks
- Noshi-Kanamer summary: development copy, 2026-10-08; attached
- Production checks (2026-10-08): indexing, debug (manual)
- Changed pricing page and contact form tested on production
Two habits keep the note useful. First, keep secrets out of it: write where credentials are managed, never the credentials themselves. Second, write it in plain text, so it survives being pasted into an email, a ticket, or a project tool.
The "Worth a decision" section is where a baseline from the start of the job pays off. If you note which plugins were active, and when they were last updated on WordPress.org, at the time you copy the site, the next person can tell what was already there from what this job changed. It also turns "the site has an old plugin" into "the site had a plugin that hadn't been updated in over a year when I took it over, and here's the date."
5. Check both sides before you call it done
Before deployment, review the changes and settings that will actually be carried over. Keep development-only settings separate from the settings intended for production.
After deployment, check production directly: indexing, debug mode, the default admin username, the file editor, and XML-RPC, against the settings agreed for that site. Also test the pages and forms you changed. A check on the dev copy doesn't confirm the live site's state. When both sides look right, send the note.
Noshi-Kanamer
I built Noshi-Kanamer to keep the repeatable cleanup and checks in one place. On the dev copy, you can remove the test content it generated, refresh permalinks, and see which Pre-Launch items are still unfinished, without keeping that list in your head.
In detail, the Pre-Launch tab deletes the test posts that Noshi-Kanamer itself generated (and only those), moves pages that contain its Block Showcase block to the trash, refreshes permalinks, and removes debug.log. Its checks cover search engine visibility, WP_DEBUG, the file editor, XML-RPC, and the default admin username, the same list worth going through by hand on production after deployment. If you run Site Check at the start of the job, it uses WordPress.org's last-updated dates to flag plugins for review; those dates don't establish a vulnerability.
You can generate a plain-text summary with Generate Report and copy it into your handoff note. It includes the site's hostname, the time it was generated, and the state of each item at that moment. Unfinished items are marked, so on a dev copy that discourages indexing on purpose, that line shows as not passing. Read that as expected, and record your production checks separately in the handoff note.
Noshi-Kanamer is free on WordPress.org. You can try it on a development copy before your next handoff. It's built for the dev copy, so leave it out of the production deployment. It doesn't write the handoff note for you, and it can't know which items you added by hand. If there's something you always put in a handoff note that I left out, I'd like to hear it.
Top comments (0)