A red browser warning is not the moment to start clicking "Request Review" until the message disappears. If Google Safe Browsing or Google Search Console has flagged the site, the useful question is why the warning appeared and whether the underlying cause has actually been removed.
The visible warning may be the first sign the owner sees, but the root problem can sit somewhere else: injected JavaScript, a compromised plugin, a malicious redirect, a hidden iframe, a phishing page, an abused upload directory, or a third-party script that was altered outside the site's normal deployment process. A review request should come after investigation and remediation, not before it.
Confirm the warning and its scope
First, identify exactly what is being reported. Google Search Console's Security Issues report can show whether Google detected hacked content, social engineering, harmful downloads, or other security problems. The browser warning alone does not tell you which files or routes are affected.
Verify ownership in Search Console if that has not already been done, then read the examples Google provides. An example URL is a lead, not necessarily the only affected page. Compromised sites often contain many generated URLs or conditional behavior that appears only for certain visitors, referrers, devices, or search crawlers.
Preserve enough evidence before cleanup
If the site is actively compromised, containment matters, but so does understanding what happened. Before deleting everything you can find, preserve the information needed to identify the entry point:
- web server and application logs;
- recent deployment history;
- file modification times;
- administrator and hosting account activity;
- plugin, theme, and dependency versions;
- database changes where the platform stores executable or rendered content;
- unexpected scheduled tasks or startup entries;
- security alerts from the hosting provider, CDN, or endpoint platform.
The objective is not a forensic archive for every small website. It is to avoid cleaning the visible payload while leaving the original access path untouched.
Check what the public site is doing now
Vulnify's Site Compromise Checker is designed for public signals. It checks Google Safe Browsing status when the required service is available, final redirect behavior, page title, hidden frames, meta refreshes, and known cryptocurrency-miner hosts. That makes it useful as one external view of the current site.
The checker does not clean malware or inspect every file on the server. A clean result does not prove the server is uncompromised. The existing Vulnify article How to Check a Site for Public Compromise Signals explains that distinction in more detail.
Look for redirects that only some visitors see
Compromised websites often try to remain invisible to the owner. A malicious redirect may trigger only for mobile visitors, search-engine referrals, first-time visitors, a specific country, or visitors without an administrator cookie.
Check the site from an independent network and a clean browser profile. Inspect redirect chains for the affected URLs. Vulnify's Redirect Chain Checker can help show the public sequence, but conditional malware may require several controlled observations to reproduce.
If the final host changes to a domain you do not control, do not stop at removing a visible redirect rule. Find what created the rule or injected the redirect.
Inspect server-side files and database content
For a CMS, compare core files, plugins, themes, and extensions with known-good sources. Remove software that is abandoned or no longer used. Look for unexpected PHP, JavaScript, templates, or executable files in upload directories.
Do not forget database content. Some compromises inject script tags, iframe markup, rogue administrator users, scheduled jobs, or modified site settings into the database, so replacing application files alone may not clean the site.
If the application is custom-built, compare the deployed build with the release artifact or source-controlled version. Investigate any production-only file that cannot be explained.
Look for hidden frames and script injection
Malicious code does not need to replace the page. A small script can load an external payload, redirect a visitor, or inject an iframe that is visually hidden.
Review the rendered HTML and loaded resources on affected pages. Search for unexpected remote hosts, obfuscated script, unusual inline JavaScript, hidden iframes, and meta refresh tags. A Content Security Policy report can also reveal newly introduced script origins, although CSP is not a substitute for cleaning the compromise.
Assume exposed credentials may need rotation
If an attacker obtained administrator, hosting, deployment, database, or API credentials, deleting malicious files will not remove that access. Review accounts and rotate credentials according to what the investigation supports.
Prioritize:
- CMS and application administrators;
- hosting and control-panel accounts;
- SSH and SFTP credentials;
- CI/CD tokens and deployment keys;
- database credentials;
- cloud and storage credentials;
- payment, email, and other third-party API keys;
- session and signing secrets if exposure is plausible.
Enable multi-factor authentication where the platform supports it. Remove unknown accounts rather than merely changing their passwords.
Patch the entry point, not only the payload
Find the vulnerable or stolen-access path that allowed the compromise. Common causes include an unpatched plugin, reused administrator password, leaked deployment credential, vulnerable custom upload code, exposed management interface, or a third-party dependency.
If the exact entry point cannot be proven, remove the credible paths you identify anyway: update supported software, delete abandoned extensions, restrict administration, rotate credentials, and review exposed services. A cleanup without hardening is an invitation for reinfection.
Review exposed paths and old files
Attackers and malware sometimes leave backup archives, web shells, temporary scripts, development copies, or renamed files outside the obvious application directories. Use Vulnify's Exposed Paths Checker as a public-surface review for commonly exposed locations, but also inspect the server itself.
Search for old ZIP files, database exports, .git exposure, temporary deployment directories, and forgotten copies of the application. Remove material that does not need to be publicly reachable.
Check third-party scripts and tag managers
A site can serve malicious content without the origin server itself being modified. Review tag-manager containers, analytics integrations, advertising scripts, chat widgets, consent platforms, and other JavaScript that can inject content into pages.
Confirm who changed those configurations and when. Remove unauthorized tags. If a third-party provider was compromised, follow the provider's remediation guidance and consider whether a temporary block is appropriate.
Verify the clean site from outside
After remediation, perform public checks again. Test the specific URLs Google identified as well as representative pages across the site. Check redirects, loaded resources, page content, TLS, headers, and obvious exposed paths.
If the compromise affected multiple hostnames, review all of them. A clean www host does not fix malware still served by shop, blog, or an old subdomain.
Request review only when the site is actually ready
Google's guidance is to fix the security issue across the site and request a review after the site is clean and secure. In the review, explain what was found and what was changed. Keep the description factual and concise.
A useful review note might include:
We identified unauthorized JavaScript injected through a compromised CMS administrator account.
Actions completed:
- removed the injected code across affected templates;
- removed the unauthorized account;
- rotated administrator and hosting credentials;
- enabled multi-factor authentication;
- updated the vulnerable plugin;
- checked the site for additional modified files and redirects;
- verified affected URLs no longer serve the malicious content.Do not claim certainty you do not have. If the entry point is unknown, say what controls were changed and what validation was performed.
After the warning is removed
The incident is not over when browsers stop showing red. Review why detection came from Google before your own monitoring. Add file-integrity, account, uptime, or security monitoring appropriate to the platform. Keep software inventory current. Remove unused plugins and old subdomains. Make backups that can actually be restored.
If the site handles customer accounts or regulated data, the compromise may also create notification, legal, contractual, or forensic obligations. A browser warning is a public symptom, not a complete incident-impact assessment.
Safe Browsing response checklist
- Confirm the issue in Search Console and record example URLs.
- Preserve relevant logs and deployment evidence.
- Check the site externally for redirects, injected content, hidden frames, and suspicious scripts.
- Inspect server files and database content.
- Review administrators, hosting accounts, and deployment credentials.
- Patch or remove the likely entry point.
- Rotate exposed or plausibly compromised secrets.
- Inspect third-party scripts and tag managers.
- Check additional hostnames and exposed paths.
- Verify the public site again after cleanup.
- Request review only when the compromise is removed and the site is secured.
- Improve monitoring so a recurrence is detected earlier.
Use public checks before and after cleanup
Vulnify can help you observe public symptoms before and after remediation. Site Compromise Checker focuses on visible compromise indicators, Redirect Chain Checker shows public redirects, and Exposed Paths Checker can identify common public exposures. A broader security scan can help identify additional website risks within Vulnify's supported scope.
Those tools do not replace server-side malware investigation, incident response, credential review, or Search Console. Use them as independent public validation while the actual cleanup happens in the affected infrastructure.
Do not optimize for the warning
Do not optimize for making the warning disappear. Optimize for removing the reason the warning appeared and the path that allowed it. Once the site is genuinely clean, the review request becomes the last step rather than the first.