What does this usually mean?
Exposed files are often left behind after migrations, plugin debugging, hosting moves, or emergency fixes. A signal does not prove compromise, but it can justify fast cleanup and review.
Guide
WordPress exposed files checklist
What to check when backup, debug, log, or configuration-adjacent files may be publicly reachable on a WordPress site.
Problem
Exposed files are often left behind after migrations, plugin debugging, hosting moves, or emergency fixes. A signal does not prove compromise, but it can justify fast cleanup and review.
Common causes
- Old backups, exports, or zip files were left in public web directories.
- Debug logs or temporary files were created during troubleshooting and never removed.
- Server rules do not block access to sensitive file extensions or common WordPress paths.
- A staging or migration process copied operational files into the public site root.
What to check
- Look for publicly reachable debug, log, backup, archive, SQL, and environment-like filenames.
- Review hosting file manager or deployment artifacts for files that should not be web-accessible.
- Check whether web server rules block common sensitive extensions.
- Remove exposed files and rotate secrets if any sensitive values were exposed.
Next steps
- Run the free diagnostic to collect evidence before changing live orders or payment settings.
- Request a Payment Rescue Review if the evidence is unclear or the risk affects customers, fulfilment, or support.
- Custom setup or fix work is quoted after review, once the likely cause and scope are clear.
Quick answer
What should be checked first?
Look for publicly reachable debug, log, backup, archive, SQL, and environment-like filenames.
Need help checking this on a live store?
Use the free scanner as a first signal. If exposed files, backups or config-adjacent paths matter commercially, Security Snapshot gives an authorised public exposure review with evidence, limitations, fixes and retest proof.