Knowledge Base
What should I do if I think my website has been hacked?
If your website shows unexpected changes, redirects or a malware warning, stop making routine changes and contact us through Support → New Ticket → Tech/Server. Include the domain, affected page, exact warning and the time you first noticed it. Ask us to help contain the problem while you preserve evidence. Do not delete suspicious files or restore a backup over a live shop before agreeing a recovery plan; either action can destroy evidence or replace newer orders and customer data.
Record what happened and limit exposure
- Write down the domain, affected page addresses, exact browser warning or unexpected change, and when you first saw it, including your time zone. Note recent website updates or new administrator accounts you know about. A warning is a reason to investigate, not proof of the cause.
- Take screenshots without exposing customer data, passwords, tokens or private configuration. Do not dismiss a browser warning, sign in through a suspicious page or download a file that the affected site unexpectedly offers.
- Pause routine deployments and content changes so you do not overwrite useful evidence. If the site is serving harmful content or collecting customer information unexpectedly, ask us and your developer to help restrict public access promptly. Do not guess at a file or server change that could disrupt other websites or email.
Contact our technical team
- Open your account, choose Support and check for an existing ticket about the incident. Reply there to keep the evidence together. For a new issue, choose New Ticket and set Department to Tech/Server.
- Choose a Priority, enter a specific Subject such as Suspected compromise of my website, and put the affected domain, page addresses, symptoms and times in Message. Explain whether the site takes orders or handles customer information, so recovery can account for data created since the last backup.
- Review the message and attachments, then choose Open ticket once. Check your ticket list before trying again if submission is uncertain. If you cannot sign in, use our contact page.
- Never send passwords, one-time codes, recovery codes, private keys or a complete database or website backup in the ticket. Backups and logs can contain private information; ask us how to share the specific evidence needed securely.
Secure access and preserve a copy
- From a device you trust, secure the email account used for account recovery and change compromised or reused passwords. Review access with your developer and remove access that is confirmed to be unauthorised. Use unique passwords and keep a record of what you change and when.
- Your website administrator login, our account sign-in and cPanel can have different passwords. Changing one does not necessarily secure the others. Use our cPanel password guide for the hosting login and our authenticator guide to protect password sign-in to your account with us.
- Ask us or your developer to preserve the affected files, database and relevant logs before cleanup. Mark a copy taken after the incident as evidence of the suspected compromise, rather than treating it as a clean recovery backup. Store it securely and do not upload it to another public website.
- Do not delete files because their names look unusual, apply broad permission changes or disable security checks across the account. Those actions can break the site or hide the route used to gain access.
Plan recovery before restoring the website
- Work with us and your developer to identify how access was gained, which parts were affected and which backup can be trusted. A backup from before you noticed the problem can still contain the original weakness or an earlier compromise.
- Before restoring, check the backup date and scope against newer orders, payments, messages and other customer data. Agree how to preserve that newer data. Our backup and restore guide explains why a restore can replace current files and database contents.
- Review the restored or cleaned site in a separate, restricted location before replacing the public site. Correct the identified access problem, update affected software and replace exposed credentials as part of that plan.
- After recovery, check the affected pages, redirects, administrator access and important functions such as checkout or forms. Keep monitoring for the original symptoms and reply to the incident ticket if they return. A restore or one clean scan alone does not prove that every cause has been removed.
