Your WordPress Site Was Hacked. How Do You Know It's Actually Fixed?

A website problem rarely arrives as a neat technical incident.

It may start with a customer saying your contact form sent them somewhere strange. A browser warning may appear when someone tries to visit your site. You may find pages nobody at your company created, see an unexpected drop in search traffic, or discover that visitors are being redirected somewhere they should not be.

Then your website provider says they updated a plugin, changed a password, or cleaned something up.

But how do you know the problem is actually gone?

That question came up repeatedly in a recent Catalyst for the Trades conversation with Jennifer Bagley and CI Web Group CTO Chris Heney. Contractors were reaching out after website compromises because they did not know what to ask their agencies or how to tell whether the incident had actually been resolved.

That is the part business owners need to understand.

You do not need to become a cybersecurity expert. But if your website generates leads, connects to your CRM, carries your brand, supports search visibility, and helps customers decide whether to trust your company, you should know who is responsible for protecting it and what they are doing when something goes wrong.

Why would anyone hack an HVAC or plumbing website?

One of the easiest assumptions to make is that your business is too small or too ordinary to attract a hacker.

But attackers do not always care who owns the website.

They may be searching automatically for outdated software, vulnerable plugins, exposed login pages, weak credentials, or other known openings. Your company may simply be running the software they know how to exploit. WordPress publishes its own guidance on hardening a site against exactly these openings.

Once they get access, your website becomes useful to them.

A compromised site could be used to:

• Publish spam or unwanted pages under your domain.
• Redirect customers somewhere else.
• Alter or interfere with lead forms.
• Display fake login or phishing pages.
• Send unwanted email.
• Gain additional access to website or hosting accounts.
• Damage search visibility or customer trust.

A hacked marketing site matters even if customers never enter a credit card number on it.

If someone searching for an AC repair company lands on your domain and sees a browser warning, a gambling page, a fake bank login, or a form that no longer reaches your team, the technical cause quickly becomes a business problem.

WordPress is not just one piece of software

This is one reason WordPress security can become difficult for business owners to understand.

A WordPress website is usually made up of several layers.

There is WordPress core, which is the main platform. Then there may be a theme controlling the design, plugins adding features such as forms or SEO tools, a hosting environment, user accounts, analytics, CRM connections, tracking systems, and other integrations.

Those components may come from entirely different developers and companies.

Some may be actively maintained. Others may no longer be supported. Some may have been installed years ago and forgotten. Each additional component creates something else your website provider needs to know is there and manage appropriately.

That is why saying, “We keep WordPress updated,” does not fully answer the security question.

Your provider should know:

• What WordPress version is running.
• Which themes and plugins are installed.
• Which components are still needed.
• Who has access.
• How quickly security issues are reviewed and addressed.
• Where backups are stored.
• What happens if something is compromised.

A security plugin may be part of that process. It is not the entire process.

A vulnerability does not automatically mean your website was hacked

You may hear your website company mention a vulnerability, CVE, patch, exploit, or severity score.

The terminology can make the situation sound more complicated than it needs to be.

A vulnerability is a weakness that could potentially be used to make software behave in a way it should not. An exploit is a method for taking advantage of that weakness. Publicly known weaknesses are catalogued by the CVE Program, and their severity is scored using the Common Vulnerability Scoring System maintained by NIST. One common example, cross-site scripting, lets an attacker inject content into pages your customers see.

A vulnerability announcement does not automatically mean someone has compromised your website.

It means your provider should determine whether the issue applies to you. When a weakness is being actively used against real sites, it typically lands in CISA's Known Exploited Vulnerabilities catalog — a useful signal that an issue needs immediate attention rather than routine scheduling.

They should be able to answer:

• Is the affected software installed on our site?
• Is the vulnerable feature accessible?
• Is a fix available?
• Has that fix been applied?
• Is there any evidence the vulnerability was actually exploited?
• What was checked afterward?

The important part is not whether your provider can quote a technical severity score. It is whether they can tell you what the issue means for your website.

What can actually happen when a website is compromised?

The technical names for attacks matter to security teams. Business owners need to understand the outcomes.

Someone can add or change things on your website

A vulnerability may allow an attacker to add files, publish pages, modify content, change redirects, or alter how part of the site behaves.

That can create obvious problems, such as spam pages appearing in search results.

It can also create less obvious problems if the homepage still looks completely normal.

Someone can gain access they were never supposed to have

WordPress gives different users different permission levels.

A person who edits a page should not necessarily be able to install software, add administrators, or change the entire site.

Some vulnerabilities can allow a user or program with limited permissions to gain more access. An attacker may also create another account or another route back into the site so they can return later.

That is why a provider should regularly review who has access.

Former employees, old agencies, unused test accounts, and abandoned integrations should not retain access simply because nobody remembered to remove them.

Someone can use your domain to deceive customers

A compromised website may also be used to display fake forms, redirects, or login screens that appear trustworthy because they are being served from a legitimate business domain.

For a home service company, this could mean a visitor sees something completely unrelated to your business or is sent to a page designed to collect information.

Your website does not have to process payments for that to matter.

Your domain carries your company’s name and credibility. Someone else using it for malicious activity can create a customer trust problem very quickly.

“We changed the password” is not the same as “the site is clean”

This is one of the most important distinctions for an owner to understand after a compromise.

Changing administrator passwords is sensible.

Updating WordPress, themes, and plugins is sensible.

Neither one proves the incident is over.

Once an attacker gets access, they may try to keep it. They could create another user, change files, alter the database, gain access to hosting credentials, or leave behind another way to return.

Fixing the visible symptom without determining how the attacker got in can leave the underlying problem unresolved. WordPress’s own “My site was hacked” documentation walks through what a real cleanup involves.

A responsible recovery should answer five questions.

1. What happened?

Document suspicious URLs, strange pages, browser warnings, unauthorized users, customer reports, unexpected redirects, recent site changes, and anything else that may help establish what occurred.

2. Has the problem been contained?

Your provider should limit further unauthorized activity while preserving enough information to investigate what happened.

Depending on the situation, that may mean restricting access, disabling a vulnerable component, or temporarily replacing the affected site with a clean page.

3. How did they get in, and what did they change?

The investigation should look beyond the obvious page or plugin.

It may need to include website files, user accounts, hosting access, administrator devices, connected services, and other systems that could have been affected.

4. What was repaired or restored?

The vulnerable component may need to be updated, replaced, or removed. Credentials may need to be reset. The site may need to be restored from a verified clean backup or rebuilt from a known-good source.

5. How was the result verified?

Afterward, someone should test the things that actually matter to the business.

Do your forms work? Do calls route correctly? Are redirects behaving normally? Are analytics and tracking intact? Can search engines still access the site? Are there unexpected users or changed files?

“Everything is updated” is not the same as identifying the cause, removing hidden access, and testing the result.

Do you actually control your own website?

Security is not only about keeping outsiders out.

Business owners should also know who controls the systems their company depends on.

Can you access your own domain account?

Do you know where the website is hosted?

Does your company have administrative access, or does only your agency?

Who owns the website files and database?

What happens if you decide to change marketing providers?

Could your team recover or move the site without relying entirely on one vendor?

These questions become especially important during a security incident, agency transition, or website rebuild.

A contractor should not discover during a crisis that the company cannot access its own domain, hosting account, website files, or other critical assets.

Document who owns what and who has access before you need that information.

If you rebuild after a hack, do not create a new problem

A security incident often leads to a larger conversation about whether the existing site should be repaired or replaced.

That can make sense.

But a replacement website still has to do the job the business needs it to do.

A new site may be secure and visually impressive while still creating problems with search visibility, lead capture, CRM connections, tracking, or other critical functions.

This is particularly worth watching as more businesses experiment with AI website builders.

AI can help create a polished front end quickly. That does not automatically mean the underlying website has been built, configured, tested, and connected correctly for a home service company.

JavaScript itself is not inherently bad for SEO, and an AI-generated website is not automatically bad for SEO either. The implementation matters — Google’s own JavaScript SEO basics and its notes on dynamic rendering as a workaround spell out where script-heavy sites tend to go wrong.

If you replace a compromised site, make sure someone verifies that the live version:

• Gives search engines access to your important service and location content.
• Uses links that can be discovered and followed.
• Has accurate titles, descriptions, preferred URLs, and structured data where appropriate.
• Returns the correct response when pages exist, move, or disappear.
• Works when scripts are slow or fail.
• Sends forms and calls where they are supposed to go.
• Preserves analytics, tracking, CRM connections, and other business-critical systems.
• Has been tested after launch rather than judged only by how it looks.

The goal is not simply to leave one website platform for another.

The goal is to build and maintain an environment your company can rely on.

Questions your website provider should be able to answer

You do not have to know how to patch a plugin, investigate server files, or configure hosting security yourself.

You should be able to ask clear questions and get clear answers.

Ask this question	What a useful answer should address
What WordPress version, theme, and plugins are installed?	A current inventory, including components that are no longer needed.
How quickly are security updates evaluated and applied?	The normal timeframe, testing process, and any exceptions.
What happens when a new vulnerability is announced?	Who determines whether it affects your site, who addresses it, and how you are informed.
Are backups stored separately and tested?	Where they are stored, how often they run, and whether anyone has verified that they can actually be restored.
Who can access WordPress, hosting, the domain, email, and connected systems?	Named users, appropriate permissions, and a process for removing access when someone no longer needs it.
If our site were hacked, how would you determine that it was clean afterward?	The investigation, scans, file and account reviews, remediation, and testing involved.
Who owns our domain, hosting account, content, files, and database?	Documented ownership and access that do not depend entirely on one vendor relationship.
Can search engines and customers access the important parts of the live site correctly?	Evidence from the live environment, including search testing, forms, redirects, tracking, and other critical functions.

A provider does not need to promise that a website can never be compromised.

No responsible security program works that way.

They should be able to show that the environment is being actively managed, that someone knows what is installed and who has access, and that there is a plan for detecting, responding to, and recovering from a problem.

Your website is part of the business

The technical details belong to the people responsible for maintaining the technology.

The responsibility to ask questions still belongs to the business owner.

Your website may be one of your company’s primary lead-generation systems. It carries your brand, your search visibility, your forms, your tracking, your service information, and often connections to other parts of the business.

You should know who is watching it.

You should know what happens when something breaks.

And if someone tells you a compromised site has been fixed, you should be able to ask what they did to prove it.

Continue the conversation

This article was developed from a Catalyst for the Trades conversation with Jennifer Bagley and CI Web Group CTO Chris Heney on WordPress core security and vulnerabilities.

Watch the full conversation for the deeper technical discussion behind these issues, then use the questions above to start a conversation with whoever manages your website.

You do not need to know everything Chris knows.

You need to know enough to ask whether the people responsible for your website are doing what your business depends on them to do.

Editorial note: This article provides general educational information, not a forensic security assessment, legal opinion, or guarantee that any particular website is secure.