This guide explains why a backup restore is not a security fix, what a proper post-hack audit and secure rebuild involves, how to evaluate whether an agency has genuine security expertise versus general web design experience, and what ongoing security infrastructure keeps a rebuilt site protected over time.
Why Your Hosting Company’s Backup Restore Did Not Actually Fix Your Security Problem
When your hosting company restored a backup of your hacked website, they performed a recovery action. They took a snapshot of your site from before the attack and replaced the compromised version with that older version. This is useful as an immediate response because it removes the malicious code the attacker injected. It is not useful as a security response because it does not tell you how the attacker got in, what they accessed during the period between the initial breach and the restore, or what vulnerabilities still exist in the restored version that will allow the same or a different attacker to breach it again.
The vulnerability that allowed the original attack is almost certainly still present in the restored version. If the attacker exploited an outdated plugin, that plugin was outdated before the backup was created and remains outdated in the restore. If the attacker used a compromised admin password obtained through a brute force attack or a credential leak, that password may still be in use. If the breach came through a misconfigured file permission or a known vulnerability in an old WordPress version, the restore brought back the same misconfiguration.
The Restore Creates a False Sense of Resolution
The most dangerous outcome of a hosting company backup restore is that it looks like the problem is solved. The site is back up. The malicious content is gone. Business resumes. Without a root cause analysis by someone with security expertise, the conditions that enabled the original breach remain in place, and the site re-enters the same risk exposure it had before the attack. According to Sucuri’s annual Website Hacked Trend Report, a significant percentage of businesses that restore from backup without addressing the underlying vulnerability are re-compromised within 30 days.
The other risk that a restore does not address is the possibility that the attacker established persistence before the backup was taken. Some attacks do not announce themselves immediately. An attacker who gained access weeks before the visible attack may have installed a backdoor, a hidden file that maintains access to the server regardless of what content is on the site, before any obvious change was visible. A backup taken after that backdoor was installed restores the backdoor along with everything else. A security audit after a restore checks for this specifically.
What Actually Gets Websites Hacked and Why Most Small Business Sites Are Vulnerable
Website compromises follow a small number of consistent patterns. Understanding the actual causes lets you evaluate whether any agency you speak to is addressing the real problem or proposing surface-level fixes that will not prevent a recurrence.The vast majority of website compromises involve one of four root causes, none of which a backup restore addresses.
Outdated WordPress Core, Themes, or Plugins
The single most common entry point for WordPress attacks is an unpatched vulnerability in an outdated plugin, theme, or WordPress core version. Plugin developers publish security patches when vulnerabilities are discovered, but those patches only protect sites that have applied the update. A site running a plugin that is two or three versions behind on updates has known, publicly documented vulnerabilities that automated attack tools scan for and exploit without any human attacker involved. Sucuri’s research consistently identifies outdated software as the leading cause of successful website compromises across all CMS platforms.
Weak or Compromised Credentials
WordPress admin passwords that are short, reused across other platforms, or never changed after the initial setup are routinely compromised through brute force attacks, credential stuffing (using username and password combinations leaked from other sites), or phishing. A compromised admin credential gives an attacker full control of your WordPress dashboard without needing to exploit any technical vulnerability. The fix requires strong unique passwords, two-factor authentication on all admin accounts, and login attempt limits that lock out repeated failed logins.
Abandoned or Nulled Plugins and Themes
Plugins and themes that are no longer maintained by their developers stop receiving security patches, which means any vulnerability discovered in them after the developer stops updating will never be fixed. Sites that continue using abandoned plugins are running software with known, unpatched vulnerabilities indefinitely. “Nulled” themes and plugins, which are premium plugins distributed for free on unofficial sites, typically contain malicious code inserted by whoever removed the license protection. Both are common on sites that prioritize reducing software costs over maintaining security standards.
Misconfigured File Permissions
WordPress installations where file and directory permissions are set too broadly allow attackers who gain any level of server access to read, modify, or execute files they should not be able to touch. The correct permission settings for WordPress files are 644 for files and 755 for directories, with wp-config.php set to 600 or 640. Sites configured with 777 permissions on files or directories, a common shortcut applied when troubleshooting access problems, give any process on the server write access to any file, which attackers can exploit to inject malicious code even through otherwise legitimate-looking channels.
Compromised Hosting Environment
On shared hosting, a compromised neighboring site on the same server can sometimes provide an attacker with enough server access to reach other sites. This attack vector is more common on low-cost shared hosting providers with insufficient account isolation. Moving to managed WordPress hosting with proper account isolation, a web application firewall at the server level, and active malware scanning eliminates this attack surface regardless of what other sites share the physical server infrastructure.
Missing Web Application Firewall
A web application firewall (WAF) sits between your site and incoming traffic, blocking known attack patterns before they reach your site’s code. Without a WAF, your site receives all traffic directly, including automated attack attempts, SQL injection attempts, cross-site scripting payloads, and brute force login attempts. A WAF from Cloudflare, Sucuri, or a managed WordPress host blocks the majority of automated attacks before they have a chance to test for vulnerabilities. Most hacked small business sites were running without a WAF at the time of the breach.
Backup Restore vs. Secure Rebuild: What Each Actually Addresses
The decision between accepting a backup restore as your recovery strategy and commissioning a proper secure rebuild is a risk decision. The comparison below maps what each approach addresses and what it leaves unresolved, which determines your exposure to a repeat breach.
| Security Concern | Hosting Company Backup Restore | Proper Secure Rebuild / Hardening |
|---|---|---|
| Malicious code removal | Removes malicious code injected after the backup date. Code injected before the backup date remains in the restored version. | Full malware scan of all files identifies and removes all injected code regardless of when it was introduced, including backdoors installed before the backup date. |
| Root cause identification | Not performed. The vulnerability that enabled the breach is not identified and remains present in the restored site. | A full security audit identifies the specific vulnerability exploited, whether that is an outdated plugin, a compromised credential, a misconfigured permission, or a server-level issue. |
| Outdated software | Restored to the state of the backup, which may include outdated themes, plugins, and WordPress core versions with known vulnerabilities. | All plugins, themes, and WordPress core updated to current versions. Abandoned plugins replaced with maintained alternatives. Nulled software removed and replaced with licensed versions. |
| Admin credentials | Restored as they were. Compromised passwords remain active. No two-factor authentication added. | All admin passwords reset to strong, unique values. Two-factor authentication enabled for all admin users. Login attempt limits configured. Default “admin” username removed. |
| Web application firewall | Not configured. Incoming attack traffic continues to reach the site directly. | WAF configured at the DNS level (Cloudflare or Sucuri) or at the hosting level, blocking automated attack patterns before they reach the site’s code. |
| Ongoing monitoring | None. The next breach will be discovered only when it becomes visible, as the original one was. | Continuous malware scanning, uptime monitoring, file integrity monitoring, and automated alerts when any file changes outside of expected update patterns. |
| Risk of re-compromise within 30 days | High. The original vulnerability remains. The same attacker or an automated tool will likely find it again. | Low. The specific vulnerability is closed. Ongoing monitoring detects any new attempt before it succeeds. |
What a Proper Post-Hack Secure Rebuild Actually Involves
A secure rebuild following a website hack is not simply a visual redesign or a plugin update pass. It is a structured remediation process that moves through distinct phases, each of which addresses a specific dimension of the security problem. An agency with genuine security expertise can describe this process in detail before you hire them. One with general web design experience will describe a similar-sounding process that lacks the specific technical steps that make the difference between a site that is secured and one that looks secured.
Phase One: Audit and Root Cause Identification
Before any remediation work begins, a security-competent agency performs a full audit of your compromised or restored site. This includes a malware scan of all files using a tool like Wordfence or Sucuri Scanner, a review of server access logs to identify when and how the attacker gained entry, an assessment of all installed plugins and themes against known vulnerability databases, and a file integrity check that compares your current files against known-clean versions of the same WordPress core, theme, and plugin files. The output of this audit is a specific root cause identification: the exact vulnerability exploited, the time and method of entry, and the full scope of what the attacker accessed or modified.
Phase Two: Remediation and Hardening
Remediation closes every vulnerability identified in the audit. This phase includes updating all software to current versions, replacing abandoned or vulnerable plugins with maintained alternatives, resetting all admin credentials and enabling two-factor authentication, correcting file permission settings, removing any backdoors or malicious files identified by the audit, and configuring a web application firewall. Hardening goes further than remediation by implementing security configurations that are not enabled by default in WordPress but substantially reduce attack surface: disabling XML-RPC if not in use, hiding the WordPress version from public view, disabling directory browsing, and implementing HTTP security headers.
Phase Three: Ongoing Security Infrastructure
Security is not a project with an end date. It is an infrastructure commitment. A secure rebuild that does not include an ongoing maintenance plan reverts to a vulnerable state the moment a new plugin vulnerability is published and not patched, which happens routinely. A proper security infrastructure for a small business website includes continuous malware scanning with daily or real-time file integrity monitoring, automated WordPress core and plugin updates with a tested staging process, monthly or quarterly manual security review of user accounts and installed software, and a backup system that stores clean copies off-server and independently of the hosting company’s backup system. Agencies that frame post-hack security as a one-time project rather than an ongoing service have not fully understood the problem.
How to Evaluate Whether an Agency Has Genuine Security Expertise
Web agencies that claim security expertise range from those with genuine WordPress security certifications and documented malware remediation experience to those who have installed the Wordfence plugin and describe that as hardening. The questions below identify which you are dealing with before you pay for work that leaves your site in the same vulnerable state it was in before the hack.
- Ask them to describe the specific steps of their post-hack audit process, starting with how they identify the entry point. A security-competent agency can describe this specifically: server access log review, file integrity check against known-clean checksums, plugin vulnerability database comparison, and credential history assessment. An agency without genuine security experience will describe a malware scan and an update pass as their audit, which is a remediation action, not a root cause analysis. You cannot close a vulnerability you have not identified.
- Ask how they handle the possibility of a backdoor that predates the backup the hosting company restored. This is the question that separates agencies with real post-hack experience from those who treat a backup restore as sufficient recovery. A security-competent answer describes a full file integrity check that compares every file against verified clean versions, identifies any files that do not match, and removes or replaces those files regardless of when they were introduced. An answer that treats the restored backup as a clean baseline has missed the most important security risk in the post-restore environment.
- Ask what ongoing security infrastructure they configure as part of the secure rebuild and what ongoing maintenance they offer after delivery. A proper secure rebuild includes web application firewall configuration, continuous malware monitoring, an update management process, and a backup system independent of the hosting company. If the agency’s answer to “what happens after we launch the rebuilt site?” is limited to general availability for update requests, they have built a point-in-time security improvement rather than a durable security infrastructure.
- Ask whether they have worked specifically with WordPress security and whether they hold any relevant certifications or have used tools like Wordfence, Sucuri, or Solid Security at a professional level. WordPress powers a large share of small business websites and is the most commonly targeted CMS. An agency that has performed WordPress malware remediation professionally understands the specific attack patterns, the vulnerability databases, and the hardening techniques that apply to the platform your site runs on.
- Ask how they configure two-factor authentication and login protection, and what they do with existing admin user accounts. This question reveals whether the agency treats credential security as a foundational step or as an afterthought. A security-first answer describes removing the default “admin” username, resetting all admin passwords to strong unique values, enabling two-factor authentication for every admin account, configuring login attempt limits, and reviewing all user accounts for any that were added by the attacker during the breach period.
The Mistakes That Lead to a Repeat Hack After a Restore
The businesses that get hacked a second time within weeks of a restore almost always made one or more of the following decisions, each of which is understandable given the urgency of getting the site back up but none of which is adequate as a security response.
Mistake: Treating the Restore as the Fix and Moving On
The most common reason sites are re-compromised quickly after a backup restore is that the business accepted the restore as a resolution and resumed normal operations without performing any security audit. The hosting company fulfilled their obligation by restoring the backup. They did not perform a security remediation. That work was not done, and the same vulnerability that enabled the original attack remained in the restored site. Automated attack tools that scan for known WordPress vulnerabilities do not distinguish between a freshly hacked site and a recently restored one. They find the same vulnerability and exploit it again, often within days.
Updating only some plugins is the second common mistake. After a restore, businesses often update the plugins they know are outdated or that they recognize by name, but miss the plugins they did not install themselves, the ones that came with a theme, the ones a previous developer installed and never removed, or the ones with names that are not immediately recognizable. A complete plugin audit requires checking every installed plugin, including deactivated ones (inactive plugins can still be exploited), against the WordPress Vulnerability Database or a tool like WPScan to verify that no known vulnerabilities exist in the installed versions.
Staying on the same shared hosting environment is the third mistake. If the original breach came through a server-level vulnerability or a compromised neighboring site on shared hosting, restoring to the same hosting environment and rebuilding on the same infrastructure leaves that attack vector open. For small businesses in Dallas and across Texas that have experienced a breach, migrating to managed WordPress hosting with proper account isolation, server-level WAF, and active security monitoring is often the most impactful single security improvement available, regardless of what other hardening work is done on the site itself.
What a Post-Hack Secure Rebuild Costs and What It Delivers
A post-hack security audit and hardening engagement for an existing small business WordPress site typically costs $1,500 to $4,000 depending on the size of the site, the severity and complexity of the breach, and whether migration to a new hosting environment is included in scope. A full secure rebuild, where the site is rebuilt from scratch on a clean installation with security architecture built into the new build from the foundation, typically runs $6,000 to $15,000 depending on the scope of the redesign and content work included.
43%
of cyberattacks target small businesses, according to Verizon’s Data Breach Investigations Report, making small business websites far from low-value targets
6 – 12 mo
of hacked WordPress sites were running outdated WordPress core at the time of the breach, per Sucuri’s annual Website Hacked Trend Report
Agencies like Creasions approach post-hack rebuilds by beginning with a security audit before any design or development work is scoped, because the findings of that audit determine whether hardening the existing site is sufficient or whether a full rebuild on a clean foundation is the more defensible path. For businesses whose sites were built on outdated, plugin-heavy WordPress installations, a secure rebuild is often the opportunity to simultaneously address the security problem and the performance and conversion problems that have accumulated over the same period of deferred maintenance.
Frequently Asked Questions
My hosting company restored a backup of my hacked site is it safe now?
Not necessarily. A backup restore removes the malicious code that was visible after the attack, but it does not close the vulnerability that allowed the attacker to get in. The restore returns your site to the state it was in at the backup date, which was a state vulnerable enough to be breached. If the same plugin vulnerability, weak password, or misconfigured file permission that enabled the original attack is still present in the restored version, your site can be compromised again through the same method, often within days. A security audit after a restore is the step that actually determines whether the site is safe.
How do hackers get into WordPress websites?
The four most common WordPress attack vectors are: outdated plugins or themes with known, publicly documented vulnerabilities that automated tools scan for and exploit; compromised admin credentials obtained through brute force attacks or credential stuffing from leaked password databases; abandoned or nulled plugins and themes that no longer receive security patches; and misconfigured file permissions that give attackers write access to server files they should not be able to modify. A web application firewall blocks most automated attack attempts before they reach your site, and keeping all software updated and credentials strong eliminates the most common successful entry points.
What is the difference between a malware scan and a security audit for a hacked website?
A malware scan identifies malicious code that has already been injected into your site’s files and database. It tells you what is there now, but not how it got there. A security audit goes further by reviewing server access logs to identify when and how the attacker gained entry, checking every installed plugin and theme against vulnerability databases for known issues, performing a file integrity check to identify any files modified outside of expected update patterns, and assessing credential security and permission configurations. A malware scan is a cleanup tool. A security audit is a root cause analysis. You need both, in that order, after a hack.
Should I rebuild my website from scratch after a hack, or can I just harden the existing site?
The right answer depends on the results of a security audit. If the audit shows that the breach came from a single identifiable vulnerability in an otherwise well-maintained site, hardening the existing site is often sufficient. If the audit shows that the site was running on an outdated, plugin-heavy architecture with multiple vulnerabilities, had not been consistently maintained for years, or shows evidence of persistent backdoors installed before the backup date, a fresh rebuild on a clean technical foundation is the more defensible path. A secure rebuild also gives you the opportunity to address performance and conversion problems that have accumulated alongside the security problems, which is often a better long-term investment than hardening a site that needed to be rebuilt for other reasons anyway.
How much does it cost to have a hacked WordPress site properly secured after a breach?
A post-hack security audit and hardening engagement for an existing WordPress site typically costs $1,500 to $4,000 depending on the size and complexity of the site and whether hosting migration is included. A full secure rebuild, where the site is rebuilt from scratch on a clean WordPress installation with security architecture built into the new build, typically runs $6,000 to $15,000 depending on the scope of the design and content work included. The cost of not securing the site properly is typically a second breach within 30 to 90 days, with all the associated recovery time, potential inclusion on Google’s Safe Browsing blocklist, and reputational damage that comes with a site that shows malware warnings in visitor browsers.
What security measures should my website have to prevent future hacks?
The security measures that prevent the vast majority of successful small business website attacks are: a web application firewall (Cloudflare, Sucuri, or a managed host’s built-in WAF) that blocks automated attack traffic before it reaches your site; an active update policy that applies WordPress core, plugin, and theme updates within days of release; two-factor authentication on all admin accounts combined with login attempt limits; strong unique passwords for all admin accounts and FTP or hosting panel credentials; continuous malware scanning with file integrity monitoring that alerts you to any unauthorized file change; and a backup system that stores clean copies off-server at regular intervals. None of these measures is complex or expensive individually, but most hacked small business sites were missing two or more of them at the time of the breach.
Can a hacked website affect my Google rankings?
Yes, significantly. Google’s Safe Browsing system scans websites for malware, phishing content, and unwanted software, and when a compromised site is detected, Google adds it to its Safe Browsing blocklist. A blocklisted site shows a warning page in Chrome and other Google integrated browsers before visitors can access it, which eliminates virtually all organic traffic until the site is cleaned and the blocklist status is removed. The removal process requires submitting a review request through Google Search Console after the site is cleaned, and Google’s review can take several days to several weeks. Sites that remain compromised for extended periods can also lose search rankings accumulated before the breach due to negative quality signals associated with the malicious content.
How do I know if there is still a backdoor on my site after the hosting company restored a backup?
A backdoor is a hidden file or code snippet that maintains attacker access to your server independently of the site’s visible content. It can survive a backup restore if it was installed before the backup date. The only reliable way to identify backdoors is a file integrity check that compares every file on your server against verified clean versions of the same WordPress core, theme, and plugin files and flags any file that does not match what should be there. Tools like Wordfence, Sucuri Scanner, and WP File Monitor perform versions of this check, but a thorough post-hack audit from a security-competent agency goes further by manually reviewing flagged files for obfuscated code patterns that automated scanners sometimes miss.
Need a Secure Rebuild That Closes Every Vulnerability Not Just a Fresh Restore?
Creasions works with small and mid-sized businesses across Dallas and Texas to audit hacked sites, identify the root cause of breaches, and rebuild or harden sites on a security-first foundation with ongoing monitoring and maintenance built into the engagement. If your site was recently hacked and you want to know whether the restore actually protected you or just reset the clock, request a free consultation and we will walk you through a security assessment of your current setup and what a proper remediation looks like for your specific situation.