Your site is redirecting visitors to a casino page, Chrome is showing a red warning, or Google has emailed you about hacked content. This is a practical guide to hacked website recovery for businesses in Saudi Arabia and the Gulf: how to confirm the hack, what to do in the first hour, how to choose between cleaning and restoring, how to get Google's warnings lifted, and what Saudi data protection guidance expects if customer data may have been exposed.
In short:
- Confirm it is a hack and not an expired plan or a broken update. Then copy everything before you delete anything.
- Contain first: take the site offline behind a 503 maintenance page, tell your host, and change every password from a clean device.
- Restore a backup taken before the attack if you have one; clean the site if you don't. Either way, close the hole the attacker used.
- Fix every affected page, then request a review in Search Console's Security Issues report and wait for the decision without resubmitting.
- If personal data may have leaked, SDAIA's breach guide sets a notice to SDAIA within 72 hours in the cases it describes, and notice to affected people without undue delay.
In this guide
Hacked or just broken? A ten-minute check
Many "hacked" websites turn out to be an unpaid hosting renewal, an expired SSL certificate or a failed plugin update, while many genuinely hacked sites look normal to their owners. Spend ten minutes on these checks first:
- Read the exact warning. A browser message about an insecure connection usually points to the certificate. A message about a dangerous or deceptive site points to malware or phishing.
- Search Google for
site:yourdomain.com. Google's own guidance notes that this shows every indexed page, including pages a hacker may have added. Pages in Japanese, Russian or about pharmacy and gambling products are a clear sign. - Open the site the way a customer does. Use your phone on mobile data and click through from a Google result rather than typing the address. Some hacks use cloaking: they show spam only to search visitors or mobile users, so the owner sees a clean site.
- Check the user list in your dashboard. An administrator nobody on your team created is a strong signal.
- Open Search Console. If the site is verified, the Security Issues report and your messages will tell you what Google has detected.
A bilingual site needs one extra check. Open both the Arabic and the English versions, because injected content often lands in one language folder and not the other. A marketing manager who only reads the English pages can miss spam sitting under the Arabic URLs for weeks.
Hacked website recovery starts with the first hour
The aim of the first hour is containment, not repair. You want to stop harm reaching visitors, lock the attacker out, and keep the evidence that explains what happened. Work through these steps in order:
Write down what you see
Screenshots, the time, who reported it, and the last change made to the site: a new plugin, a new user, an update. This note saves hours for whoever investigates.
Copy the infected site
Files and database, as they are now. Label the copy "infected" with the date and store it away from the server. You will never restore it, but it is the only record of what the attacker changed.
Take the site offline properly
Google's quarantine guidance recommends taking the site offline so it stops serving content to users, ideally with a 503 "temporarily unavailable" response served from outside the compromised files; your host can often set this up. Blocking crawlers in robots.txt is not enough, because people can still reach the harmful pages.
Tell your hosting provider
Your host may hold access logs and older backups you cannot see. Ask how far back their backups go.
Remove unknown users and change passwords
Note the names of accounts you don't recognise, then delete them. Change passwords for every CMS user, the hosting panel, FTP or SFTP and the database. If your own laptop might be infected, do this from another device.
Secure the domain and the admin email
Log in to your domain registrar, check that the DNS records have not changed, and turn on two-step verification. Do the same for the mailbox that receives password resets, or every new password can be reset again.
Just as important is what not to do in that first hour:
- Don't start deleting suspicious files. You destroy evidence and usually miss the backdoor hidden elsewhere.
- Don't restore last night's backup on reflex. If the attacker got in three weeks ago, last night's backup is infected too.
- Don't install a random "malware cleaner" plugin from an unknown source while the site is compromised.
- Don't make a public statement before you know what was affected. Communicate, but with facts.
Who holds the keys? Sorting out access when the builder has moved on
In the Gulf, a common obstacle has nothing to do with code. The website was built by a freelancer who has since left the Kingdom, or by an agency abroad, or by a colleague whose personal email still owns the hosting account. On the day of the hack, nobody can log in. Head offices add another layer: a regional site may sit on a group hosting account managed from another country and another time zone.
Before anyone can fix anything, gather these on one page:
- Hosting: the provider, the account holder's name and email, and who can raise a support ticket.
- Domain: the registrar and whose name the domain is registered in. If it is not your company's, start that conversation now.
- Website platform: WordPress, another CMS, a static site or a hosted store, and who built it.
- Backups: where they are kept, how often they run and the date of the oldest one.
- Connected services: email on your domain, payment or booking tools, analytics and Search Console. Each is a login that may need a new password.
- Internal policy: if you are part of a larger group, find out whether IT or legal at head office must be told, and by when.
If an account is in someone else's name and they cannot be reached, the provider's support team is your route back in. Start early, because it often takes longer than the clean-up itself. Then move every account to a company email address.
Clean, restore or rebuild: choosing your recovery route
The deciding question is not "do we have a backup?" but "do we have a backup from before the attack started?" Attackers often get in weeks before anyone notices, and every backup taken after that point carries their files. Google's clean-up guidance treats a clean recent backup, a clean but old backup, and no clean backup as three different situations. Add the option of rebuilding and you get four routes:
| Route | When it fits | What it involves | Main risk |
|---|---|---|---|
| Restore a recent clean backup | A backup exists from shortly before the first sign of the attack | Restore, update all software, close the hole, change passwords again | Picking a backup that was already infected |
| Restore an older clean backup | The only clean backup is weeks or months old | Restore it, compare with the infected copy, carry over new content only after checking it | Losing orders, bookings or posts added since |
| Clean the site | No clean backup exists | Work on a copy: remove added files, replace core and plugins with fresh copies, clean the database | Missing a backdoor, so the hack returns |
| Rebuild | The site is old, unsupported, or has been hacked more than once | A new site on a clean base, with text and images moved across after checking | Time, and the need to keep URLs and search visibility in mind |
A worked example
A trading company in Dammam runs a bilingual WordPress site with a quote request form. On the 20th, a client mentions that the Arabic home page sent him to a pharmacy site. The host keeps weekly backups for two months. The oldest suspicious file on the server is dated the 6th. The backup from the 13th is therefore infected, and the right choice is the backup from the 4th. Quote requests received since then are recovered from the notification emails in the sales inbox, not from the infected database. Then the team works out how the attacker got in, because restoring without that answer only resets the clock.
Finding the way in
Google's guidance is blunt on this: removing malicious files is not enough if the vulnerability stays open. On small business sites the entry point is usually one of a short list:
- An outdated plugin or theme with a published vulnerability.
- A stolen or guessed password, often an admin account without two-step verification.
- A "nulled" (pirated) copy of a paid theme or plugin that arrived with malware built in.
- An old developer or FTP account nobody removed.
- Another site on the same poorly isolated shared hosting account.
Ask whoever does the work to state the likely cause in writing. If they cannot find it, that matters too: it means monitoring after relaunch has to be tighter. When the old site is beyond saving, a website redesign on a clean base is often less risky than patching it one more time.
The right backup is not the newest one. It is the last one taken before the attacker got in.
Google warnings, the Security Issues report and review requests
When Google detects that a site is hacked or harmful, its pages can appear in search results with a warning label, and browsers such as Chrome may show a full-page warning before the site opens. Everything below happens in the Security Issues report in Google Search Console; if your site is not verified there yet, set it up now (our guide to getting found on Google covers the basics).
What the report shows
Google's help page groups issues into hacked content (content, code or links placed on your site without permission), malware and unwanted software, and social engineering (deceptive pages and downloads). Each issue lists sample URLs. Treat them as examples, not a complete list: Google states that fixing the issue on only some pages will not earn a partial return to search results.
Pages the attacker created
Spam pages added by the attacker should return a 404 once the site is clean. You can also use the Removals tool in Search Console for those pages, since Google describes it as being for pages you never want to appear in results. Don't use it for your own pages that were tampered with and then cleaned; you want those back in search.
Writing the review request
Once every issue is fixed on every page, choose Request Review in the report. Google asks you to explain the problem, describe the steps you took, and document the outcome. A short, specific request might read:
- Problem: spam pages in Japanese were added under a new folder, and the server configuration file was changed to redirect mobile visitors.
- Steps taken: restored a clean backup from before the attack, updated the CMS and all plugins, removed an abandoned plugin identified as the entry point, and changed all passwords.
- Outcome: the spam URLs now return 404, the redirect is gone, and the sample URLs in the report were rechecked with the URL Inspection tool.
Then wait. Google says a review can take from a few days to a few weeks, and asks you not to resubmit while a request is pending. Even after the warning is lifted, some spam results may linger until Google recrawls the clean pages. Nobody can promise a date, but a complete fix and a clear request are the shortest route.
If customer data may be exposed: what Saudi PDPL guidance expects
Any site with a contact form, bookings, customer accounts or orders holds names, phone numbers and email addresses at the very least. After a hack, the question is whether the attacker could reach that data.
The Saudi Data and AI Authority (SDAIA) has published a Personal Data Breach Incidents Procedural Guide under the Personal Data Protection Law (PDPL) and its Implementing Regulations. In plain terms, it sets out three stages for the controller, meaning the organisation responsible for the data:
- Notify SDAIA within no more than 72 hours of becoming aware of the incident, if it is expected to harm the personal data or the people it belongs to, or conflicts with their rights or interests. Notice goes through the breach notification service on the National Data Governance Platform, which requires registration. The notice covers what happened and when, the categories and approximate number of people affected, the risks, and the actions taken.
- Contain the breach: identify the type and amount of data, change what can be changed (such as passwords), identify the people affected, and notify them without undue delay where the breach causes damage to their data or conflicts with their rights or interests.
- Document: keep copies of what was submitted, the corrective actions and related records.
The guide also notes that this is without prejudice to any reporting required under National Cybersecurity Authority regulations or other rules in the Kingdom. This is a general summary, not legal advice. Foreign-owned companies may also have obligations at home or under group policy, so involve your legal team or adviser early. For the wider picture of how a website handles personal data, see our PDPL website compliance checklist.
What a good customer notice says
SDAIA's guide asks for a notice in clear, simple language that explains the incident, the possible risks and what you did about them, how to contact you, and advice to help people protect themselves. It can go by text message or email, the channels customers already use with you. In practice:
- Say what happened and when, without drama and without playing it down.
- Say what data may be affected and what was not, for example that card details are not stored on the site, if that is true.
- Explain what you have done: taken the site offline, cleaned it, changed passwords.
- Tell people what to do: change their password if they have an account, and be wary of messages using your business name to ask for payments or details.
- Send it in Arabic and English if your customers use both, and give a direct contact who knows the facts.
After the site is back: two weeks of watching, then hardening
If a backdoor was missed, the attacker will try to use it soon after relaunch. Treat the first two weeks as a watch period.
Daily checks for the first two weeks
- Open the site from a Google result on your phone, on mobile data, in both languages.
- Check the user list for accounts you did not create.
- Check the Security Issues report and your Search Console messages.
- Run the
site:search again and confirm the spam results are shrinking. - Submit your own contact form and confirm it lands in the inbox, not in spam.
What changes for good
Google's clean-up guidance recommends changing passwords more than once during recovery, removing software you no longer use, running regular automated backups, keeping everything updated and keeping the devices you log in from secure. On top of that, three habits come out of an incident:
- An incident log: one page with the date, the likely cause, what was done and who did it. You will need it if a customer, auditor or head office asks.
- Restore tests: the backups that saved you this time should be test-restored every few months.
- A named owner: one person or one provider responsible for updates, backups and monitoring. Hacks thrive on sites that everyone uses and nobody owns.
Our website maintenance checklist turns this into weekly, monthly and yearly tasks. Also check the padlock after a restore, since an old backup can bring back settings that break HTTPS; what an SSL certificate is explains what to look for. And if the hosting itself was part of the problem, our guide to types of web hosting helps you weigh the alternatives.
How Webnaa can help after a hack
Webnaa offers website maintenance and support: updates, backups, monitoring and fixing problems. If your site has been hacked, we can inspect it first and then send you a written plan to clean or restore it, with the scope and price set out before any work starts. To be straightforward about it: nobody can promise an outcome before the site has been examined. Some sites only need a clean backup restored; others need rebuilding on a clean base. The consultation is always free.
If you decide the old site is not worth saving, Webnaa's website design service builds a new one, with the content written for you. We send the design on a preview link within 24 hours of receiving your complete information, before it goes live on your domain. Hosting and SSL are included, and there is a money-back guarantee if you don't like the design during the design stage. Web design at Webnaa starts from SAR 39 a month for a one-page, one-language site on a Webnaa subdomain. The price of a site on your own domain depends on its type, languages and number of pages, and the price calculator shows it in seconds.
Think your website has been hacked?
Send us the link and what you have noticed. We will look at it and propose a written plan before any work begins.
FAQ
How do I recover a hacked website without a backup?
Work on a copy of the site, not the live server: remove files the attacker added, replace the CMS core, themes and plugins with fresh copies, and clean modified database records. It takes longer and needs experience. If the site is old or keeps getting hacked, rebuilding may be the better route.
How long does it take Google to remove a hacked site warning?
After you fix every affected page and request a review in the Security Issues report, Google says a review can take from a few days to a few weeks. Don't resubmit while a request is pending.
Will a hacked website lose its Google rankings?
It can, especially if a warning label appears in results or the site fills with spam pages. Once the site is clean and the warning is lifted, Google reassesses pages over time. Nobody can promise rankings will return exactly as they were.
Do I have to tell customers my website was hacked?
If their personal data may have been exposed in a way that harms them, SDAIA's breach guide expects you to notify them without undue delay, and to notify SDAIA within 72 hours in the cases it describes. If no personal data was involved, a short honest message to anyone who noticed the problem still protects trust.
Why does my website keep getting hacked after cleaning?
Usually because the way in was never closed: an outdated plugin, a password that was not changed, a hidden backdoor, or an infected backup that was restored. Cleaning without finding the cause brings the same problem back.
Should I move to a new host after a hack?
Moving an infected site moves the infection with it. Clean it and close the hole first. If weak hosting was part of the cause, moving afterwards makes sense.
Summary
Hacked website recovery goes best in a fixed order. Confirm it is a hack, copy the infected site, take it offline behind a 503 page, tell your host and change every password from a clean device. Make sure you control the hosting, the domain and the admin email. Then restore a backup from before the attack, or clean the site, and close the way in. Fix every affected page before you request a Google review, and follow SDAIA's breach guide if customer data may have been exposed. Finally, give the site a named owner, so the next incident is caught early or never happens.
Sources: Google Search Console Help: Security Issues report, Google on web.dev: quarantine your site, Google on web.dev: clean and maintain your site, SDAIA: Personal Data Breach Incidents Procedural Guide. All accessed November 2026. From Webnaa: website maintenance checklist and PDPL website compliance checklist.