How to tell if your website has been hacked

A website compromise can affect its pages, user accounts, server or external content. Malware is software designed to cause harm. Phishing is an attempt to trick someone into handing over information such as a password. A compromised site can be used for either without the owner realising.

Google's Security Issues guidance describes injected pages, hidden spam and redirects that depend on how someone arrives. That is why your own visit is not enough to dismiss a customer's report. Ask for the address, warning and time, but do not ask the customer to revisit a dangerous page.

• A browser warns that the site is dangerous, deceptive or distributing malware.
• Customers are sent to an unrelated site or offered downloads you did not add.
• Search results show unfamiliar pages under your domain, such as unrelated offers or spam.
• Your website contains changed text, payment details, adverts or links that nobody authorised.
• An unfamiliar administrator account appears, or an existing account's details change unexpectedly.
• Your host reports malicious files, suspicious activity or spam being sent from the site.

A slow page, a server error or a broken layout does not prove a hack. A certificate error can be a separate connection problem. Equally, a working homepage and HTTPS do not prove that a site is clean. Treat unexpected behaviour as evidence to check, not a reason to guess.

If you or your maintainer already have access to Google Search Console, open its Security Issues report through Google's own website. Search Console is Google's tool for website owners. It can show detected hacked content, malware and deceptive pages, with example addresses where available. Its examples do not cover every affected page.

An empty report or a clean result from one scanner is not a guarantee. Ask the host or maintainer to inspect the site's files, accounts and logs too. Do not bypass a browser warning, download a suspicious file or enter a password on the affected page to see what happens.

Write down when you first noticed the issue, including the time zone. Keep the exact affected addresses, warning text and any messages from your host. Save screenshots only where you can do so without opening a harmful page. Keep personal information out of anything you share publicly.

Tell your maintainer about recent updates, new accounts and unexpected emails. Ask the host to preserve relevant logs and a copy of the compromised site before cleaning or restoring it. Logs are records of activity that can help establish how someone got in. Label an infected copy clearly and keep it private, separate from backups intended for recovery.

Do not delete the whole website in a panic. Doing so can remove evidence without fixing access to the hosting account. Keep a short record of each action and who took it.

Contact your hosting provider and website maintainer using details you already trust. Give them the evidence and ask them to check whether the compromise extends beyond the website. WordPress.org notes that a host can help distinguish a hack from a service failure and investigate effects on shared hosting.

If the site is exposing visitors to malicious content or collecting information through altered forms, ask the host to restrict access or serve a clean holding page from an unaffected system. Simply removing one suspicious page may leave others active. Agree how to stop the harmful activity while preserving evidence.

Use a separate, trusted channel to explain any interruption to customers and provide a safe way to contact you. Tell staff not to use the affected website or follow unexpected login links. If payment details have changed or money may have gone to an attacker, contact your bank or payment provider using its official contact route immediately.

Check your cyber insurance policy, if you have one, and contact the insurer before commissioning work that may require its approval. For an attack that is still in progress, use the live-incident reporting route below as well as contacting your host.

From a device you trust, contact the providers to recover and secure affected accounts. The website login is not the only route in. Hosting, domain registration, file-transfer accounts and the email used for password resets may need attention too. If you suspect your computer is infected, arrange a malware check rather than using it to set new passwords.

Use new, unique passwords and turn on multi-factor authentication where available. This adds another check to signing in, such as an authenticator code. Ask the maintainer to end existing login sessions, remove unauthorised access and replace exposed access keys. Record unfamiliar accounts before removing them, and check legitimate access with the people involved.

Changing a password does not remove malicious files or stop every existing session. WordPress.org advises resetting access during the response and changing passwords again after the site is clean. Have technical credentials changed by the person responsible for them, because an uncoordinated change can stop the site working.

As at 13 October 2026, Report Fraud has replaced Action Fraud as the reporting service for fraud and cybercrime in England, Wales and Northern Ireland. Use reportfraud.police.uk or call 0300 123 2040. In Scotland, report to Police Scotland on 101. Reporting a crime does not replace the technical work needed to contain it.

The National Cyber Security Centre, or NCSC, says businesses, charities and other organisations experiencing a live cyber attack can call 0300 123 2040 immediately. Its live-attack line is available 24 hours a day, seven days a week. Follow the Scotland-specific police route if your organisation is based there.

For a significant cyber incident, NCSC guidance recommends reporting directly to the NCSC. If you are unsure which route applies, use GOV.UK's Report a cyber incident service at gov.uk/report-cyber. It directs you to the appropriate reporting route. The NCSC handles the most critical UK incidents; do not assume it will personally clean a small business website.

Keep your report reference and incident notes. Any report required by the Information Commissioner's Office is separate. GOV.UK explicitly says information submitted through its cyber reporting service is not passed to the ICO.

Personal data includes information that identifies people, such as customer contact details and account records. A breach can involve unauthorised access, disclosure, alteration or loss. Ask what data the site held, what the attacker could reach and what evidence supports the assessment. Do not wait for proof that a database was downloaded before considering the risk.

The ICO says a personal data breach must be reported unless it is unlikely to result in a risk to people's rights and freedoms. Where reporting is required, notify the ICO without undue delay and within 72 hours of becoming aware of the breach, where feasible. You can provide further information in stages if the investigation is incomplete. Record any delay and its reasons.

If the breach is likely to create a high risk to affected people, they must also be told directly without undue delay. Keep a record of the breach and your reasoning even if you decide it does not need reporting. Use the ICO's guidance and seek advice for your own circumstances, especially where sensitive records or payment information may be involved.

Ask the person doing the recovery to establish how the attacker gained access and remove any way they could return. A backup is useful only if it predates the compromise and has been checked. Restoring an infected copy or leaving a stolen hosting login active can bring the problem back.

The recovery should address affected files, database content, accounts and vulnerable software, not just the visible spam. Agree how newer orders or enquiries will be preserved if older data is restored. Once the site is clean, apply appropriate updates and recheck access.

Check the pages and customer actions that were affected. If Google flagged security issues, the owner or maintainer should request a review in Search Console after fixing every reported issue across the site. Warnings may remain while the review takes place. Do not tell customers that a successful login or one clean scan proves complete recovery.

After recovery, agree who handles updates, backup checks and security alerts. Keep the incident record and record any changes to how the website is maintained.