You’d be surprised what attackers still find on small business websites.
Not fancy zero-day stuff. Not movie hacker nonsense. Just forgotten junk sitting there in plain sight - an old installer folder, a staging plugin’s setup page, a public phpinfo.php file, a “coming soon” page that was never fully locked down. Boring little leftovers. And yes, they can absolutely turn into a real security problem.
I’ve seen sites where the homepage looked polished and normal, but hidden two clicks away was a setup wizard from 2021 still accessible to anyone. That’s the kind of thing bots love. They don’t get tired, they don’t get distracted, and they scan thousands of sites a day looking for exactly this mess.
If your WordPress site was built quickly, rebuilt by three different people, or migrated from one host to another, there’s a decent chance you’ve got a few scraps lying around too.
What these leftover files actually are
Let’s make this simple.
These are files or pages that were useful during setup, testing, or development, but should’ve been removed or blocked before the site went live. Sometimes they come from WordPress tools. Sometimes from themes, plugins, custom code, or random developer habits that nobody cleaned up after.
Common examples:
phpinfo.phporinfo.phpfiles- Old installer folders from themes, plugins, or site clones
- Public staging or temporary subdomains
- Coming-soon pages that still expose admin paths or plugin details
- Backup ZIP files sitting in the web root
- Test scripts like
test.php,db-check.php, ormail.php
Individually, some of these don’t seem dramatic. That’s the trap. They leak information, expose weak spots, or leave behind entry points. And attackers don’t need your whole life story. Just one loose thread.
The weird danger of phpinfo files
A public phpinfo() file is a classic. Developers use it to check server settings, PHP version, loaded modules, file paths, memory limits, and a bunch of other technical details. Fair enough during setup. But after launch? Delete it. No hesitation.
Why? Because it tells attackers what kind of environment they’re dealing with. Your exact PHP version. Server paths. Extensions. Sometimes even bits of configuration that help them narrow down an exploit path. If you’re running PHP 7.4 from 2019 and the whole world can see it, that’s not just messy. It’s an invitation.
This is especially bad on older sites where nobody has touched the server setup in years. A florist, dentist, local repair shop - doesn’t matter. Bots aren’t judging your business size. They’re matching known weaknesses against exposed details.
If you want a rough check, try visiting:
yourdomain.com/phpinfo.phpyourdomain.com/info.phpyourdomain.com/test.php
If any of those load a technical page full of server details, that’s a problem. Remove the file right away.
Coming-soon pages are not always harmless
This one catches people off guard.
A coming-soon page sounds innocent because it feels temporary. You put up a placeholder, finish the real site later, job done. But some coming-soon or maintenance plugins leave the actual site structure exposed underneath. Search engines may still find pages. Bots may still hit admin endpoints. Plugin assets can reveal what tools you’re using. Sometimes the page itself leaks theme names, JavaScript paths, or debug clues.
And sometimes the “coming soon” page never really goes away. The business owner thinks the developer removed it. The developer thinks the owner handled it. Six months later the main site is live, but the old staging directory is still public on /new or /beta.
Big mistake.
That hidden copy often has weaker passwords, old plugins, and zero maintenance. Honestly, it’s sometimes easier to break into the abandoned test version than the real site. Then the attacker uses that foothold to poke around the rest.
If this sounds familiar, have a read of Build for maintenance, not just launch. It explains why launch-day thinking causes all sorts of dumb long-term problems.
Installers and setup pages are worse than they look
Some plugins, migration tools, and site copy tools use installer scripts. They’re meant to run once. Then disappear. But disappear is the part people skip.
Let’s say your site was cloned from an old host using a migration package. If the installer file or archive is still accessible, an attacker may learn how the site was structured, what files were moved, or in some cases try to rerun setup steps. Same story with abandoned CMS installer folders and old database import tools.
And no, you probably won’t notice this by casually clicking around your homepage.
This is why basic hardening matters. Things like locking down public access to setup leftovers, hiding version clues, and disabling features you don’t use. If you want the easy route, a tool like one-click hardening helps knock out a bunch of these low-effort risks without you needing to fiddle with server files all afternoon.
How attackers usually find this stuff
Mostly? Automation.
They’re not sitting there admiring your logo. Bots try common filenames, common folders, common plugin paths. They request hundreds of URLs in seconds. /backup.zip. /installer.php. /old. /dev. /phpinfo.php. Boring, repetitive, effective.
That’s also why small businesses get hit so often. Not because you’re special. Because you’re available. If you want a better picture of how random this really is, read How Attackers Find Your WordPress Site in the First Place. It clears up the whole “why would anyone target my little site?” question pretty fast.
What you should check on your own site
You don’t need to turn into a sysadmin. But you should do a proper sweep.
- Check obvious filenames
Try common leftovers in your browser:/phpinfo.php,/info.php,/installer.php,/test.php,/backup.zip. - Look for old folders
Things like/old,/new,/dev,/backup,/staging, or a forgotten subdomain. - Review plugins used during setup
Migration plugins, coming-soon tools, database managers, temporary file managers. If they’re no longer needed, remove them. - Ask your developer bluntly
“Are there any public staging copies, installer files, or test scripts left on the server?” Don’t ask vaguely. Be annoyingly specific. - Scan for known issues
A proper vulnerability scanner won’t magically find every stray file, but it can flag outdated plugins and publicly known weaknesses that often go hand in hand with this kind of neglect.
And if you’re managing the site yourself, don’t just deactivate junk. Delete what you don’t need. Deactivated plugins still sit on the server. Forgotten files still exist. That’s the part people miss.
What to do if you find leftovers
First, don’t panic. Most of this is fixable pretty quickly.
Delete unused files. Remove abandoned plugins. Kill off public staging copies. If a file was needed for a one-time test, it has no business hanging around now. Then update WordPress, themes, plugins, and PHP if they’re behind. Because leftover files and outdated software tend to travel in packs.
If you find something sketchy and you’re not sure whether it’s already been abused, check your logs and file timestamps. Or get help. Fast. The annoying truth is that once a site has been poked at through a forgotten setup file, you can’t safely assume “nothing happened.” Maybe nothing did. Maybe.
If your site has a long history of patchy updates, mystery plugins, and old developer leftovers, this is where ongoing WordPress maintenance pays for itself. Not because maintenance sounds fancy. Because somebody actually checks this stuff before it becomes a bigger bill later.
This is housekeeping, but the kind that matters
People hear “website security” and imagine firewalls, malware scans, and scary dashboards full of alerts. Sure, those have their place. But a lot of hacks start with plain old neglect. Forgotten files. Half-removed tools. Temporary pages that became permanent by accident.
Not glamorous. Still dangerous.
So take 20 minutes this week and look for the leftovers. Ask awkward questions. Open weird URLs. Clean up the rubbish. Your site doesn’t need to be perfect, but it shouldn’t look like a renovation site where somebody left the back door open and wandered off for lunch.
I’ve seen worse. Probably you will too.