Know what normal looks like
Unexpected changes are easier to spot when you have a record of what belongs on your site. Keep a list of the people and services that can publish or edit files, including your content management system, plugins, deployment tools and hosting provider. Note where site files are stored and how planned updates reach them. A small site does not need an elaborate monitoring system, but it does need a dependable point of comparison.
A recent, known-good backup or a version-controlled copy can serve as that reference. If neither is available, start a simple change log for future work: record the date, the person responsible and the area changed. File modification times can offer clues, but they are not proof of when a change was made. A restore, migration or automated update may alter many timestamps at once.
Look for changes in more than one place
A changed page may be the first visible sign: unfamiliar text, a new link, a broken layout or a form that behaves differently. Other clues may appear in your hosting file manager, deployment history or CMS activity log. Pay particular attention to new executable files, changes to configuration files and edits to pages that nobody expected to touch. Do not treat every unfamiliar filename as suspicious; software updates often add files.
Check the site as a visitor would, then compare that view with the files and CMS content behind it. If a page looks different but its file has not changed, the cause might be stored content, a template, a plugin, a cache or an external service. Conversely, a changed file may have no visible effect yet. Write down the exact page, file path and time you noticed the issue so you can investigate a specific event rather than a vague impression.
Compare first, then ask what could have caused it
Start with a copy of the affected file and compare it with a known-good version using your editor, version control or a file comparison tool. Look for the smallest meaningful difference. Was a line of text corrected, a dependency updated, or unfamiliar code added? Check nearby files as well: a legitimate deployment commonly changes a related set of files, while an isolated change may deserve closer attention. Neither pattern is conclusive on its own.
Next, match the change against ordinary activity. Ask the people who can edit the site whether they made it. Review scheduled updates, recent deployments, plugin updates and hosting notices. If logs are available, look for relevant CMS sign-ins, file uploads, deployment runs or hosting access around the same period. Logs can be incomplete, and their clocks may use different time zones, so avoid building a firm conclusion from one entry.
Preserve evidence before making repairs
If the change remains unexplained, avoid immediately deleting files or restoring a backup. First save a copy of the changed files, relevant logs and a screenshot of any visible problem. Record what you checked and what you found. This gives you something to compare after a repair and makes it easier for a host or developer to help. Keep these copies somewhere access-controlled, especially if configuration files or logs might contain sensitive information.
If the site appears to be serving harmful content, exposing information or sending visitors somewhere unexpected, limit the impact promptly. Depending on your setup, that might mean temporarily taking the affected page offline, disabling a suspect plugin or asking your host for help. Choose the least disruptive step you can take confidently. If you are unsure what a file does, do not remove it from a live site on a guess.
Fix the cause and make the next check easier
Once you understand the likely cause, apply the appropriate fix. For an authorized edit, update your change log. For a faulty deployment or update, correct or roll back the affected work and test the relevant pages and forms. If unauthorized access is a possibility, review account access, reset affected credentials, update supported software and seek help from your host or a qualified site maintainer. Restoring files alone may not address the route by which they were changed.
Afterward, confirm that the site behaves as expected and that no new unexplained changes appear. Keep reliable backups, limit publishing access to people who need it and use a repeatable update process. Even a brief monthly review of recent file changes and account activity can make the next oddity easier to explain. The goal is not to treat every difference as an emergency; it is to make differences visible, traceable and manageable.
