Treat an unexpected page or redirect as an incident
Treat visible defacement or an unexplained redirect as a possible incident: stop interaction, preserve safe observations and contact the authorised owners.
An unexpected advert, defacement or redirect may vary by visitor and expose a device to hostile content. Do not revisit it to gather more screenshots. Preserve the URL, time, browser warning text and any screenshot or message already received. Note who saw it and from which ordinary user journey, without collecting unnecessary personal data.
A changed page can also come from an authorised release or a mistaken DNS cutover. Ask the application owner whether a planned change explains it, but do not dismiss a security warning on that assumption. Avoid announcing a cause until the authorised team has investigated.
Send the minimum useful evidence to the right owners
Use the agreed incident route to contact both the application owner and Novasean hosting support. Provide the affected domain, observed URL, first known time, safe screenshot or warning text, and any recent deployment or access change the owner knows about. Do not paste passwords, session cookies, private logs or a database dump into a ticket. If customer data might be involved, flag that possibility to the designated incident contact so the responsible team can assess it under the agreement.
If the site owner has Search Console access, its Security Issues report may show Google’s findings and sample URLs. Google says those examples are incomplete and can be absent even when an issue exists. A clean report therefore does not overrule an observed compromise. Let the authorised investigator decide whether and how to inspect affected content without loading a suspected infected page in a normal browser.
For example, record the first unexpected redirect URL and time already observed. Avoid revisiting the destination; the incident owner can obtain server-side evidence through an approved route.
Wait for a scoped containment and preservation decision
The application owner and hosting operator should agree how to protect visitors, preserve evidence, identify the entry point and assess affected data. Depending on the facts, they may isolate the site, revoke compromised access, restore known-good code and patch the vulnerable component. Do not run a cleanup script, overwrite the live tree with an old archive or change all credentials blindly before they have defined the sequence; that can destroy evidence and leave the cause active. This guide does not replace the incident team’s investigation.
Check the supported recovery outcome
After the team declares the site safe for testing, use an independent client to check the previously affected URL and a representative normal page. Confirm that the expected site appears without the unwanted redirect and that intended sign-in or forms work. The application owner should review their own monitoring and any Search Console issue status. A Google review request belongs after remediation across affected pages; its timing and outcome are separate from a local page check. Report any recurrence with a fresh timestamp and do not continue browsing the suspicious content.
Frequently asked questions
Should I restore yesterday’s backup immediately? Ask the incident owners first. The backup may predate new customer data, contain the same weakness or overwrite evidence.
Does one clean browser test prove the site is safe? No. Malicious behaviour can depend on URL, user or referral source, and the authorised team must complete its wider checks.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.