← All articles
AFTERWORKS ARTICLES

How Can I Tell If My Business Website Has Been Hacked?

Recognise possible website compromise, preserve evidence and organise a safe response without assuming every error means a hack.

By afterworks.space3 min read
Layered paper illustration: A conservator discovers an unexpected hidden flap inserted into a public exhibition panel and closes that section while a colleague records the evidence.

Part of our guide: UK Website Compliance and Security: A Practical Guide for Small Businesses

Unexpected pages, redirects, administrator accounts or security warnings can indicate that a website has been compromised. They can also have other causes, so treat them as reasons to investigate rather than proof of a particular attack.

If customers may be exposed to harm or personal information may be involved, contact your hosting provider and a competent security professional promptly. Avoid experimenting on the live site while trying to diagnose a serious incident.

Look for changes you did not authorise

Warning signs include unfamiliar content, altered payment details, unexplained downloads, new accounts, changed files or messages from the host about suspicious activity.

Search-result titles that do not match your business can also be a clue. Record the exact URLs and when you first noticed the problem.

The security and compliance guide explains the account and supplier inventory that makes this investigation easier.

Thinking about your own rebuild?

Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.

Verify warnings through trusted routes

A frightening email may itself be a scam. Open your hosting or search-console account through a known address rather than a link in the message.

Confirm the issue with your normal supplier contact. Do not give passwords, payment details or remote access to someone who contacted you unexpectedly claiming to fix the problem.

The NCSC’s response and recovery guidance is a useful starting point for organising an incident response.

Preserve evidence before destructive changes

Keep screenshots, timestamps, relevant alerts and available logs. Ask the provider to preserve evidence that might otherwise expire.

Do not immediately delete unfamiliar files or reinstall everything without considering what information may be lost. A specialist may need that evidence to identify the entry point and the affected systems.

If active harm is occurring, containment may take priority. Make that decision with the provider or incident responder and record what was changed.

Consider accounts as well as website code

A compromised administrator, email account or deployment credential can affect a site even when the visible software is current.

Review access through trusted devices and follow the incident team’s instructions on credential changes, session revocation and multi-factor authentication. Check connected services rather than assuming the problem is confined to one page.

For WordPress sites, outdated software risks are one part of the picture. Static architectures also have account and integration risks, as discussed in Astro security.

Assess data and reporting duties

Establish whether personal information was accessed, changed, lost or exposed. Keep a factual incident record and obtain advice about notification obligations and deadlines.

The ICO’s personal-data breach guidance explains when reporting may be required. Do not assume that restoring the homepage resolves the data-protection issue.

Communicate verified facts to affected people where required. Avoid speculation or assurances that cannot yet be supported.

Recover from a trusted state

Use a known-good backup or clean rebuild as part of an agreed recovery plan. Fix the underlying cause and check for persistent access before reopening affected functions.

The backup and recovery guide explains why restoration needs testing. Restoring vulnerable software without addressing the weakness can lead to another incident.

Test forms, payment destinations, redirects and search-console warnings after recovery.

Improve the handover afterwards

Document the cause, response, recovery steps and preventive actions. Update the access inventory and make sure someone else can find it.

If the usual developer is unavailable, the developer continuity guide provides a practical starting point for authorised recovery.

For a routine website review, contact AfterWorks. For an active compromise, use qualified incident-response support rather than waiting for a design consultation.

  • Website compliance
  • Small business
AFTERWORKS ARTICLES
All articles ↗

Thinking about your own website?

Explore our website rebuilds and pricing and ownership. If we have already contacted you, our preview guide explains why and what happens next.