SECURWEB SCAN · REPUTATION · INJECTIONS
How to check if a website has been hacked: a diagnostic guide
A hacked website does not always show a defaced homepage. Attackers can add hidden phishing pages, SEO spam links, scripts on a checkout page or redirects shown only to certain visitors. The site may look normal while customers encounter a security warning.
Unexplained traffic loss, a browser warning or an alert in Google Search Console’s Security Issues report warrants investigation. Start with an external check, then review the server and logs with your technical team if concerns remain.
1. Review external alerts and Search Console
If Chrome warns about a deceptive or dangerous page, save its exact URL and check the site owner's Search Console Security Issues report. Google may provide examples of affected pages. Lost traffic or rankings can have other causes and do not prove a hack on their own.
SecurWeb Scan queries Google Web Risk for the submitted URL when that source responds and inspects a limited set of public pages. It cannot access your Search Console account or exhaustively check all threat lists or hidden pages. No reputation alert does not guarantee the site is clean.
SEO spam can introduce casino, pharmacy or counterfeit links and pages. Check Search Console for unfamiliar URLs and compare search snippets with your real pages; a spot check of public links may flag clues without detecting every cloaking variation.
2. Look for injections, forms and redirects
On publicly accessible pages, SecurWeb checks for some obfuscated JavaScript patterns, hidden frames, spam links, suspicious forms, observable redirects and a small set of exposed sensitive files. It also checks a few CMS and HTTP header clues. These patterns need confirmation in source files and logs; they do not explain the full attack by themselves.
A redirect may depend on the phone, country, search referrer or session. A scan that sees a normal page cannot rule it out. If visitors report a mobile-only issue, reproduce the journey in an isolated test environment and compare HTTP responses, served code and logs for each context.
For an online store, card-skimming code can be injected into checkout without stopping sales. Have security staff review third-party scripts, file changes and network connections on those pages. A public scanner cannot certify that checkout is free of data theft.
Protect your organisation’s online reputation and spot visible signs of website compromise
A compromised company website may host phishing pages, show spam links, redirect visitors or expose sensitive files. These changes can harm customers, trust and visibility. A browser or Search Console warning calls for prompt investigation.
SecurWeb Scan lets administrators, webmasters and communications teams check public pages on a domain. It examines observable redirects, suspicious script and form patterns, spam links, a small set of exposed files and Google Web Risk when available. Standard mode checks up to 5 pages and deep mode up to 20.
The scan does not inspect the server, logs or Search Console; it does not test every mobile variant or continuously monitor the domain. A clean result does not rule out compromise. Duration depends on the site and external sources.
Explore the Business offer3. Respond to suspected compromise
Contain risk and preserve evidence
If visitors may be exposed, temporarily disable the affected feature or put the site into maintenance under your incident process. Preserve a copy of the site, logs and alerts before cleaning; coordinate with hosting and response teams. Assess notification duties if personal data may be affected.
Find the entry point, clean up and rotate access
Compare files with known-good versions and inspect admin accounts, plugins, scheduled tasks, FTP/SFTP access and possible webshells. Fix the entry point, restore from a verified source, then rotate exposed passwords, application secrets and sessions in a coordinated order. Do not restore an unverified backup to production.
Recheck and request a review
Update the CMS and extensions where needed, check affected pages and monitor logs. If Google still reports a problem, request a review in Search Console’s Security Issues report after fixing all affected URLs. A review request does not instantly remove a warning or replace remediation.
Google guidance: Monitor security issues · Fix malware and request a review.
Conclusion: combine public checks with server investigation
Regular checks of public pages may reveal a redirect, exposed file or abnormal content. Long-term security also needs component inventory, updates, tested backups, log monitoring and an incident response process. No spot check guarantees a website is uncompromised.