WordPress Hacked? First Steps for Irish Businesses
First steps for a suspected WordPress compromise: contact your host, restrict access, preserve evidence and validate recovery before reopening.

If you suspect a WordPress compromise, contact your host, restrict public access and record what happened. Preserve a protected copy of files, the database and available logs before destructive cleanup. A restore or rebuild needs investigation of the entry point and retained content; neither proves the site is clean by itself.
TL;DR:
- Check backup integrity and the likely compromise date before deciding on a restore, cleanup or rebuild.
- Restrict public access and preserve evidence promptly; this reduces exposure but cannot guarantee the attacker has lost access.
- Recover authorised access from a trusted device, revoke compromised sessions and rotate credentials again after cleanup.
- Combining remote and application-level scanners provides more comprehensive detection of malicious files and injected database content.
- Implementing ongoing security measures such as updates, strong passwords, two-factor authentication, firewalls, and regular backups reduces the risk of future infections.
Table of Contents
- First-response checklist: contain, document and contact your host
- Safely regain admin access so you can begin recovery work
- How to choose between cleaning the site and wiping then rebuilding
- Technical checklist to find malicious files and injected database content
- How to restore content safely and remove search-engine warnings
- Reduce the risk of reinfection
- When to DIY and when to ask for professional recovery
- Discuss a WordPress recovery project
- FAQ
- Sources
First-response checklist: contain, document and contact your host
Once you suspect a hack, the next hour matters more than the next day. Working through a short sequence, in order, keeps you from destroying evidence or making the damage worse.
- Ask your host to isolate the compromised site and serve a safe temporary response outside its infected files. A maintenance plugin or robots.txt alone does not contain an attacker or prevent direct access to harmful files. See Google’s quarantine guidance.
- Avoid deleting, editing or “quick fixing” anything yet. Every change can wipe out evidence you might need later.
- Ask the host to preserve files, database and available access/error logs. Record times and actions. Keep the infected copy protected outside the webroot; do not browse or execute its files on your everyday computer.
- Contact your hosting provider. Ask whether other accounts on the same server are affected, whether they hold recent clean backups, and whether they can snapshot your account for investigation.
- Write down every indicator of compromise you can find: unexpected redirects, unfamiliar admin accounts, new files, a Google “this site may be hacked” warning, or strange outbound email activity, as WordPress recommends documenting before you scan or clean anything.
Practical check: Keep evidence access restricted. It may contain personal data, malicious code and credentials; a normal shared folder is not an appropriate place for it.
Safely regain admin access so you can begin recovery work
WordPress recovery mode can help with certain fatal plugin or theme errors. It is not a malware cleanup or a way to regain trust in a compromised account. Use a trusted device and ask your host to help recover authorised access.
If you are locked out entirely, work through these steps:
- Use the host’s authorised recovery process or a trusted WP-CLI environment. Preserve the user/account evidence first. Avoid creating privileged accounts or editing database password hashes without an approved recovery plan.
- Rotate WordPress authentication keys and salts to invalidate existing WordPress login cookies. This does not revoke hosting sessions, application passwords, API tokens or other independent access paths; review those separately.
- From a trusted device, reset affected WordPress, hosting, SFTP/FTP, database and email credentials and revoke exposed tokens. Coordinate configuration changes to avoid breaking services. Repeat credential rotation after cleanup if secrets could have been captured again.
Coordinate access recovery, evidence preservation and revocation with the host. There is no universal safe order for every incident; active harm may require immediate isolation.
How to choose between cleaning the site and wiping then rebuilding
This decision shapes everything that follows, so get it right before you start deleting files.
- A verified backup from before the likely compromise can be a recovery option. Test it in isolation, check retained data and close the original entry point before reconnecting the site.
- Choose cleanup or rebuilding according to the evidence and what can be trusted. Suspected server-level compromise or affected sibling sites needs host-level investigation; reinstalling WordPress alone will not resolve it. Do not wipe files or overwrite the database before preserving evidence and agreeing the recovery plan.
- Partial cleaning (deleting the obvious malware file and calling it done) often misses a backdoor hidden deeper in a theme or plugin, which lets the attacker straight back in.
- A rebuild means fresh core files, fresh plugins and themes from official sources, a new
wp-config.php, and a check of your uploads folder for any stray PHP files masquerading as images.
Where trust cannot be established, ask for a scoped recovery assessment. A fresh application still needs validated data, secure hosting and the original vulnerability addressed.
Complex infections, a suspected data breach, or an infection that has spread across shared hosting are good reasons to bring in a professional rather than work through this alone.
Technical checklist to find malicious files and injected database content
Treat scanner findings as investigation leads, not proof that a file is clean or infected. Remote and application-level checks can complement one another, but coverage varies. Ask the host to investigate server-level persistence and retain the protected evidence copy for comparison.
- Scan
wp-content, including the uploads folder and both active and inactive themes and plugins, for PHP files that do not belong there or that were modified recently. - Check scheduled cron jobs and the full list of registered users for anything you did not create.
- Review server configuration, .htaccess, scheduled jobs and changed files against trusted versions. Strings such as eval, base64 or gzinflate can occur in legitimate code; they are investigation clues, not grounds for automatic deletion.
- Preserve another protected database snapshot before changes. Review injected posts, options, users and other relevant tables with someone who understands the schema; do not remove rows solely because they look unfamiliar.
Scanner coverage has limits. Combine appropriate checks with trusted-file comparisons, account and log review, and host-level investigation. Neither one scanner nor two scanners establish complete eradication.
How to restore content safely and remove search-engine warnings
Restoring the wrong thing from a backup can reintroduce the exact problem you just spent hours removing.
- Pull content and media back only from a backup that predates the hack, never from the infected copy you preserved for evidence.
- Validate restored media and database content, inspect unexpected executable files and compare trusted backups. A scanner result alone cannot establish that every file is safe.
- Test the recovered site, clear affected caches and review CDN rules before reopening. Where Google reports a security issue, request a review in Search Console’s Security Issues report after fixing every issue. Review completion and warning removal are not immediate or guaranteed.
- Revoke or rotate exposed secrets and review integrations and scheduled jobs for persistence. Agree a monitoring period with the host based on the incident; one or two quiet weeks is not proof of complete eradication.
Reduce the risk of reinfection
Getting the site back online is only half the job. These controls make a repeat attack much less likely:
- Keep WordPress core, themes and plugins updated, and remove anything you no longer actively use rather than letting it sit dormant and unpatched.
- Only install themes and plugins from official sources: never a “nulled” or cracked copy, however convenient it looks.
- Use a password manager for strong, unique passwords, and switch on two-factor authentication for every admin account.
- Review a suitable firewall and protected off-site backups. DISALLOW_FILE_EDIT disables dashboard editing. Broader file-modification restrictions need an explicit update/deployment plan; do not silently prevent security updates.
- Restrict PHP execution inside the uploads folder with
.htaccessor nginx rules, and set correct file permissions across the install.
Pro Tip: Put a recurring monthly reminder in your calendar to check for updates and run a scan, rather than relying on remembering after the last scare fades.
A protected, tested backup can support recovery. Restoration time and data loss depend on backup coverage, integrity and the incident; an afternoon’s recovery is not promised.
When to DIY and when to ask for professional recovery
Recovery needs appropriate access, a validated plan and the skills to interpret the evidence. If you cannot establish what can be trusted or how to close the entry point, agree a scoped recovery assessment with your host or a suitably experienced professional before destructive changes.
If personal data may have been accessed, preserve your evidence and treat your data protection obligations seriously rather than as an afterthought once the site is back up.
hostme.ie
Discuss a WordPress recovery project
Contact hostme.ie to discuss scoped website recovery, hosting or backup work. Availability, investigation, delivery time and any ongoing support are agreed before work starts; this guide does not promise an emergency response or a fixed recovery outcome.
For an initial scope conversation, message us on WhatsApp. A conversation is not a free technical audit. You can also review our hosting and security services.
Scope check: Recovery work, hosting and ongoing support have different scopes. Confirm availability and the proposed work before granting access or expecting an urgent response.
FAQ
Is my site hacked in WordPress?
Possible signs include unexpected redirects, unfamiliar administrator accounts, a Google security warning, unexplained files or unusual outbound email. Record these observations and investigate them with the host; individual symptoms or scanner alerts can have other explanations.
Is WordPress safe from hackers?
No website is immune to compromise. Updates, least-privilege access, strong authentication, secure hosting and monitored backups reduce risk; their presence is not proof that a site is clean.
What do I do if my website has been hacked?
Contact your host, restrict public access outside the infected application, and preserve files, database and logs before destructive changes. Investigate the entry point, validate the recovery and reset compromised access before reopening.
How to secure your WordPress site from hackers?
Keep software supported and updated, use strong authentication and least privilege, review hosting controls, and test protected backups. These controls reduce risk; they do not make future incidents a guaranteed quick restore.
Do I need to report a WordPress hack in Ireland?
A website incident is not automatically a reportable personal data breach. Assess whether personal data has been compromised and the risk to people. Controllers must notify the Data Protection Commission without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to pose a risk. A likely high risk also requires informing affected people without undue delay. Record the assessment even if notification is not required; get appropriate advice for the actual incident.
Sources
- WordPress.org incident response
- WordPress hardening
- Google: quarantine a compromised site
- Google: cleanup and recovery checks
- Google Search Console security reviews
- DPC breach notification guidance


