DEV Community: Noshi

What I Check When I Inherit a WordPress Site I Didn't Build

Noshi — Wed, 26 Aug 2026 06:00:20 +0000

Sometimes the site was built by another developer. Sometimes by an agency. Parts of it may also have been generated or changed with AI. But the handoff problem itself is older than AI.

However it was built, you're the one touching it now. You don't know what's actually configured under the hood. Not yet.

1. Record the current state before you change anything

Before you fix, add, or "clean up" anything, write down what you found. No one's checking your work here. But later, if something breaks, it helps to know whether it was already broken when you got there.

A quick note is enough: which plugins are active, whether the site is set to be indexed, whether debug mode is on. Later, that note gives you something to compare against when a problem shows up.

2. Look at the installed plugins

Open the plugins screen and look past the ones that are active. Look at all of them, active and inactive.

For each one, ask three questions:

Is this plugin still maintained? Check its last update date on WordPress.org. A plugin that hasn't shipped an update in a year or more is one worth reviewing before you rely on it, even if you didn't choose to install it.
Is this one inactive on purpose, or was it just never cleaned up? An inactive plugin sitting around for years may simply be a leftover, or someone may have kept it there on purpose. Either way, it's often worth asking about.
Should I keep touching a site that depends on this? Sometimes the answer is yes, and that's fine. The point is to ask that question before you start relying on the plugin.

I used to do this by opening each plugin's WordPress.org page one by one, which is tedious enough that I usually skipped the ones that "looked fine." Eventually, I automated that part of the process. I'll come back to that at the end.

3. Check the current state, not the assumed state

You assume noindex is off because "why would anyone launch a site that's hidden from Google." You assume debug mode is off because "it's a live site." Those assumptions are often right. But inherited sites are exactly where I don't want to rely on them.

Check whether the site is set to be indexed by search engines, and don't rely only on the visible setting. A theme or plugin can force noindex through code even when the visible setting looks fine. Check whether WP_DEBUG is on. Check whether the default admin username still exists. These aren't complicated checks, but they're easy to miss when you're focused on the actual task you were hired to do.

Ask yourself, for each setting: was this intentional, or is this just what came with the site? If you can't answer that, you can't safely assume it's fine.

4. Make your changes

Then you do the actual work: build the feature, fix the bug, make the requested changes. But now you're doing it against a baseline you actually understand, instead of a baseline you inherited blind.

5. Go through the site again before you hand it back

Once your work is done, circle back to the same questions from step 3. Indexing, debug mode, admin username, and anything you added along the way: test posts, temporary pages, anything meant only for your own reference during the work.

This is the same discipline you'd use before handing off a site you built yourself. The fact that you inherited the site doesn't change what you should leave behind when you're done. If anything, it's harder, because you're dealing with things you created during the job and things that were already there.

Noshi-Kanamer

This workflow is also why I added Site Check to Noshi-Kanamer. It scans every installed plugin, active or inactive, against WordPress.org and flags the ones that haven't been updated in 6 months or a year, so I don't have to open each plugin's WordPress.org page one by one. Then, before I hand the site back, I use Pre-Launch to check indexing, WP_DEBUG, debug.log, the default admin username, and a few other loose ends. It generates a plain-text report I can keep for myself or hand to whoever I'm delivering the work to.

It's free on WordPress.org. If there's something you always check on an inherited site that I'm missing, I'd like to hear it.

I built a WordPress site with AI. What should I check before launch?

Noshi — Wed, 19 Aug 2026 02:43:47 +0000

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.

The AI Blind Spot: Why "It Works" Isn't the Same as "It's Safe to Launch"

Noshi — Fri, 17 Jul 2026 09:42:41 +0000

A few months ago, a founder posted about the SaaS he'd just shipped, built entirely with an AI coding assistant, not a line of it typed by hand. He was proud of it, and he had every right to be. Within days of launch, someone found the API key sitting in plain sight in the client-side code. It got used to bypass the paywall, spam the backend, and write garbage into the database. The founder spent the next stretch rotating every key, moving secrets into environment variables, and locking down the API endpoints that should have been locked down before anyone ever saw the site.

Nothing about that story is about the AI being bad at its job. The AI did exactly what it was asked: build a working product, fast. Nobody asked it to think about what happens when a stranger opens dev tools.

In the replies, someone made a simple point: AI is a great research aid, but shipping a large application still means understanding the code. Copying and pasting isn't programming. The founder didn't push back. He agreed: he'd learned it the hard way.

The same story, over and over

Swap the platform and the same shape of story repeats. Here's the WordPress version: three separate, ordinary launches, three separate silent failures.

A site goes live and Google never finds it. Somewhere in Settings → Reading, "Discourage search engines from indexing this site" got left checked. It's a setting every staging environment needs and every production site must not have. Nobody notices until weeks later, when someone asks why the brand-new site isn't showing up in search at all.

A debug log sits in a predictable place, readable by anyone. wp-content/debug.log collects whatever errors WordPress throws (database credentials, API keys, fragments of user data) in plain text, at a URL automated scanners check within hours of a new site going live. Turning debug mode off doesn't delete the file it already wrote.

The admin username is still admin. It's the default nobody bothered to change, and it happens to be exactly half of every credential-stuffing attempt a bot will throw at the login page. Overnight, login attempts against a fresh install can climb into five figures.

None of these are exotic. Every WordPress developer has heard of all three. And yet they keep happening, on hand-coded sites, on AI-assisted ones, on both.

Why this keeps happening

Here's the pattern underneath all four stories: AI does what you ask. Launch safety is made of the things nobody asks for.

Nobody prompts "change the default admin username." Nobody prompts "make sure debug logging is off in production," or "double-check the noindex setting before this goes live." These aren't features. They're the absence of problems. Absence produces no visible change on the screen, so it never occurs to anyone to ask for it, so it never happens.

This isn't a hunch. An industry study on AI-generated code found that nearly half of the samples it examined contained security weaknesses, not because the models are careless, but because the safety constraints were never part of the request in the first place. The gap isn't in what AI can do. It's in what nobody thought to ask.

The same blind spot exists whether a human typed every line or an AI generated all of it. AI just means more code gets shipped by more people, faster, with fewer of them stopping to ask the questions an experienced reviewer would ask automatically.

What actually helps

You can't prompt your way out of a blind spot you don't know you have. The real fix isn't a cleverer prompt. It's not handing everything over in the first place.

When the work is new (a payment flow you've never wired up before, an auth pattern you're trying for the first time), a human should look at every line before it ships. That's supposed to be slow. Once the same kind of check has been run enough times that the pattern is settled and well understood, then it's reasonable to let a tool take it over. Trust in automation gets earned through repetition. It isn't something you assume on day one.

That's exactly where automation fits, and where it doesn't. A good checking tool isn't a substitute for a human looking hard at something unfamiliar, and it doesn't claim to catch everything an AI-assisted build might get wrong. What it does is stand at the end of every stage, checking the things that are already well understood and no longer need someone's full attention, and confirming, one more time, that they're actually clean before the site goes live.

The tool catches what's routine. Building the habit of checking, especially the parts that aren't routine yet, is still on you.

One more thing

I'll be honest about why I wrote this one: I keep seeing the same shape of story, on different platforms, with different tools, and it always comes down to the same gap: the things nobody thought to ask for. On the WordPress side, that's what Noshi-Kanamer is for. It started as a way to stop making these mistakes myself. It auto-detects the things that tend to slip through (WP_DEBUG left on, noindex still set, the default admin username, a stray debug.log, and more), then generates a shareable proof report of every check. It's free, it's WordPress-specific, and it's not the whole answer to AI-assisted development. It's just the part of the checklist that's easy to automate, so the parts that need a human get your full attention instead.

Whatever built your site, don't skip the human check before you hand over the keys, and leave a note that proves you did.

WordPress Pre-Launch Checklist for Client Handoff: What to Check, Clean Up, and Prove Before Delivery

Noshi — Fri, 03 Jul 2026 02:12:02 +0000

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, and 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, but 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_EDIT in wp-config.php disables 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.log file left web-accessible is a quiet information leak. Delete it and confirm logging is off.
The 'admin' username: a default admin account 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

Prefer clicking checkboxes over copy-pasting markdown? Here's the same 25 items as an interactive web checklist you can walk through in your browser.

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.

Want this as an interactive checklist you can walk through step by step? I turned this list into a free web checklist with all 25 items in one place, and a peek at what's coming next: an AI Site Safety Report for client handoff, now taking early access signups.