Anticode Open builder

What to do if your website is hacked, or looks like it has been

If your site shows something you didn't put there, work in order: confirm what changed, check what the platform's scan already found, restore a clean version, then lock down every account that could have made the change. Because Anticode checks every publish on the server and rechecks published files, the likelier route for unwanted content is an account someone else got into, so the account steps matter as much as the restore.

Updated · By the Anticode team

Step 1: confirm what you're seeing

Before changing anything, write down exactly what's wrong and take screenshots with the time. Open the site from a different device and network. Then rule out the look-alikes:

It's not your site
A domain typo, an old address, or a search result pointing at a copy. Check the address bar letter by letter.
It's your domain, not your site
If your domain shows a different site entirely, the DNS records may have changed at your registrar. That's an account problem at the registrar, not on Anticode.
It's an edit someone in your team made
Check version history first. Each save is listed with where it came from, such as the builder, the CLI or an agent.
It's genuinely unexpected content
Carry on below.

Step 2: check the integrity result

When a site is published, Anticode records a fingerprint of every file, stored apart from the files themselves. An hourly scan works through sites in batches, so each one is checked about once a day: every file is hashed again and re-run through the publish checks. A file that changed or fails is restored automatically from the newest backup whose copy is intact and passes; if there's no clean copy, that file is taken down.

Open your site's public security report at /.well-known/anticode-security. It shows the last integrity scan's time and result, alongside the checks each page passes and what the pages load. If the scan already found and repaired a changed file, the report says so.

If the scan is clean but the content is wrong, the files are exactly what was last published. That means the unwanted content came through a publish, which points at an account rather than at the server.

Step 3: restore a clean version

  1. Open version history in the builder and preview earlier saves until you find the last one that's right.
  2. Restore it. A restore is written as a new version, so the versions in between stay in the list and you can still examine the bad ones later (history keeps the most recent versions, up to your plan's number, so look soon).
  3. Run the release checklist, then publish. The live site now matches the clean version.
  4. Don't unpublish the site to "take it offline" unless the content is dangerous to visitors. Unpublishing deletes the site's published files and their backups along with them. Restoring and republishing fixes the content and keeps the history.

Step 4: secure every account

  1. Change your Anticode password, and the password of the email account it belongs to. Whoever controls your email can reset everything else.
  2. If you sign in with Google or GitHub, secure that account instead: new password, two-factor sign-in, and a check of its recent sign-in activity.
  3. Turn on two-factor sign-in in Anticode with an authenticator app, and store the recovery codes somewhere safe, away from your laptop.
  4. Revoke CLI tokens you don't recognise or no longer use, from the dashboard.
  5. Disconnect AI clients connected through MCP that you no longer use, in the client itself.

Step 5: review who has access

In a Team or Agency workspace, list everyone with access and their role. Members can build, edit and publish; admins can also delete projects and take sites down. Remove anyone who has left or whose work is finished, and downgrade admins who don't need it. Removal takes effect immediately. If a former colleague's account was the source, removing them closes the door.

If the site collects form data, check the submissions access log too. It records the last 200 reads, exports and deletes of form data, so you can see whether anyone looked at or exported enquiries.

Step 6: tell the people who need to know

  • Your team, with what happened and the new rules.
  • Anticode, through the contact page, if you believe the change came from the platform rather than an account.
  • Customers, if their data may have been seen. Personal data breaches can carry legal duties to notify, depending on where you are; take advice.

How you know it's over

The live site matches a version you trust, the security report shows a clean integrity scan, every account with access has two-factor sign-in, nobody is in the workspace who shouldn't be, and you've written down the timeline. Check the site again the next day.

Limits

Anticode backs up the last ten published versions, rechecks files about once a day, restores changed files automatically and keeps your edit history. It can't secure your email, registrar, Google or GitHub accounts, and it doesn't offer forensic investigation. If someone reported the problem to you, see responding to a security report; for routine protection, backups and integrity and two-factor sign-in.

Questions people ask

Should I take my hacked website offline?

On Anticode, usually not: restore a clean version and republish. Unpublishing deletes the published files and their backups.

How do I restore my website to an earlier version?

Open version history, preview earlier saves, restore the right one and publish. The restore is added as a new version.

Does Anticode fix changed files automatically?

Yes. The integrity scan restores a changed file from the newest clean backup, or takes it down if there isn't one, and the result shows on the site's security report.