How to Remove a Phishing Page Planted on a WordPress Site

You find a URL on your own domain that imitates a bank, digital wallet, marketplace, or other service’s sign-in page. It may sit in a directory you did not create, be absent from the site menu, or only come to light when a customer sends a screenshot. Deleting one WordPress post may stop one symptom, but it does not tell you whether the page came from a user submission, a compromised administrator, a vulnerable plugin, or a file that keeps injecting the content.

The short answer is: record the URL and evidence, limit visitor exposure, map every copy and the path that created it, clean the source, then make sure the URL serves the correct content or returns 404/410. Close access and persistence, test again, and request a security review if Search Console has reported an issue. Do not rely on robots.txt or a temporary Google removal as cleanup.

This guide covers phishing content planted on WordPress. For a broader compromise, follow the incident response steps for a hacked website. If the site also has spam comments or posts, see how to distinguish WordPress comment spam from compromise.

Protect visitors before testing the page

A phishing page is designed to make someone enter information in the wrong place. Do not repeatedly open the URL on your personal phone, fill in the form “to check it”, or ask a customer to bypass a browser warning. Save the complete URL, time and time zone, a screenshot without victim data, and any message from the browser or host. Do not copy credentials a customer submitted into a general support ticket.

After preserving the minimum evidence, limit access to the page. If your host provides a documented quarantine or blocking option, coordinate with the provider before using it. For a transactional site, notify the payment-process owner and the authorised privacy contact if a business flow or customer data may be involved; do not claim a data breach without evidence. If phishing is still active and you are unsure how to disable the URL safely, ask the host to isolate the site while preserving a copy for investigation.

A screenshot or scan can itself trigger a redirect. Use an isolated investigation environment that has no active sessions for important accounts. The aim is to collect enough facts without entering real information or spreading a harmful link.

Decide whether the page came from a user or a compromise

Suspicious pages do not all arrive the same way. Start by asking whether the site accepts public submissions, such as listings, forum posts, profiles, forms, comments, or vendor-created landing pages. If it does, check the content owner, moderation state, user history, and role changes. A user-submitted page may be abuse of a feature without server access—but the account or form still needs attention.

If there is no feature that should create this kind of page, or if you also find an unknown administrator, changed files, hidden redirects, or unfamiliar scripts, treat the site as potentially compromised until you can rule that out. Check whether the domain and host in the URL are actually yours, or whether your brand appears only in a path or a subdomain controlled by somebody else. A phishing page on another person’s domain needs a different reporting route from a page stored on your WordPress server.

Record what is known and what remains a theory. An IP address, filename, or content creation date may not identify a person. Do not delete logs or contact a suspected author before the site owner and host agree on the investigation plan.

Map all phishing URLs, not just one example

Open the Search Console Security issues report for the property covering the affected domain and subdomain. Check the security or social-engineering category and sample URLs; Google describes these URLs as examples, not a complete list. Also check the Google Safe Browsing site status if a browser shows a warning.

Build an inventory from several sources:

• URLs in Google’s report, the sitemap, and server logs;
• posts, pages, custom post types, drafts, trash, form submissions, and users allowed to create content;
• files in the WordPress root, plugins, themes, must-use plugins, and uploads;
• WordPress rewrite and redirect settings, .htaccess or server configuration, CDN, DNS, and subdomains;
• pages that appear only for a path variation, query parameter, device, or anonymous session.

A site:example.com search can help reveal traces in search results, but it is not a full crawler and cannot prove there are no other pages. Do not aggressively test every variation in an ordinary browser. Start with reported URLs, then ask your host or technician to inspect patterns and access logs.

Clean the source of the page

If the phishing page is a post, page, or user submission

Record its ID, URL, date, author, status, and any evidence you need. Once the site owner approves containment, remove or quarantine the phishing content and restrict the account or feature being abused. Check whether the page uses a legitimate template that was altered, an unknown shortcode or plugin, or an external file.

If public submissions are necessary, limit file and URL types, require verification or moderation before publication, reduce the submitting role’s permissions, use appropriate anti-spam controls, and alert on unusual registrations or posting. Do not simply turn moderation off because the queue is inconvenient.

If the page comes from a file, database, or rewrite rule

Before changing the system, take a backup and ask the host to preserve logs that may expire. Compare core files with official packages, inspect plugins, themes, and uploads, and investigate recent changes in context. Do not delete a file just because it contains base64, eval, or a random-looking name; these patterns can occur in both legitimate and malicious code. Validate the result against a trusted source and have a technician interpret it.

Check the database for unknown pages, posts, options, widgets, menus, shortcodes, and redirects. Also remove scripts that inject a form or redirect visitors. If the code came through a vulnerable plugin or theme, update or replace it from a trusted source; removing one injected file without fixing the component lets an attacker repeat the change.

For an initial WordPress check, WP-CLI provides wp core verify-checksums and wp plugin verify-checksums --all. These checksum commands compare supported files with official checksums, but they are not a full audit: commercial or custom plugins, themes, the database, host configuration, and malware that adds a new file need other checks. Use a copy or staging environment and read the official documentation for core checksum verification and plugin checksum verification before taking action.

Make the removed URL return the right response

The correct result depends on whether the URL ever had a legitimate purpose:

• A legitimate page was altered: restore trusted content and remove the phishing form, script, or redirect. Do not leave a hidden fake page in the template.
• The URL was never legitimate and has no equivalent replacement: remove its content from WordPress and the server, then make sure the URL genuinely returns 404 or 410.
• There is a genuinely equivalent replacement: use a permanent redirect only to the relevant replacement, not to the homepage just to avoid an error.
• The page came from a user-submission feature: remove the submission, audit the author account, secure the endpoint, and test whether another version of the URL can still be generated.

Do not use robots.txt to hide the URL. It limits crawling; it does not remove a page, and a crawler may be unable to see the 404 response that should follow deletion. Do not serve normal content to Google but different content to people, or the reverse. Test the URL without logging in, check encoded URLs found in logs, trailing-slash variations, redirects, and caches after changing the rules.

Close the access and persistence that created the page

The page can be recreated if access remains open. Audit administrators, custom roles, recently created users, active sessions, application passwords, recovery email, hosting panel, SFTP/SSH, database, APIs, and CDN/DNS access. Revoke unfamiliar sessions and tokens after identifying their owner. Change credentials from a trusted device and update secrets used by the application.

Review plugins and themes, uploads, cron tasks, must-use plugins, wp-config.php, redirect configuration, and accounts or rules that could recreate the page. If a legitimate user submitted the page through an open feature, fix validation, moderation, and permissions—not only the administrator password. Record versions before and after cleanup so the work can be reviewed.

For other malware symptoms, such as hidden spam pages or device-specific redirects, use our guide to signs of malware on a WordPress site. If the change returns after cleanup, stop deleting the symptom repeatedly and escalate; persistence has not been found.

Request a security review only after every finding is fixed

If the Security issues report lists social engineering or hacked content, resolve every finding across the site before selecting Request Review. Explain the category, URLs or areas checked, source found, cleanup, root-cause fix, and visitor-level test results. Keep the confirmation and wait for the decision through the report or official email; Google may need time, and a site owner cannot set its review schedule.

If customers need to stop finding the phishing URL in Google quickly, the Search Console Removals tool can temporarily limit search results. It does not clean the server and its block is not permanent; the source must still be removed or secured. For a suspected false positive, use the appropriate official reporting channel after verifying the page, not before cleanup.

Test the site as a visitor after the changes

The final check should show that harmful content is no longer served and legitimate features still work:

1. Test each URL in your inventory, relevant hosts, redirect variations, and pages without signing in.
2. Confirm the fake URL now returns legitimate restored content or 404/410, as appropriate.
3. Check the response and network requests for unknown forms, scripts, iframes, or redirect destinations.
4. Repeat file, account, database, and log checks; see whether a phishing file or post returns after scheduled tasks or cache refresh.
5. Test sign-in, public forms, notifications, and important transactions with approved test data—not a victim’s credentials.
6. Monitor Search Console, Safe Browsing status, hosting reports, and newly created URLs after reopening.

Record the time, versions, URL status results, reviewer, and changes. If a URL still redirects or displays a warning, do not call the incident resolved; isolate it again and find the remaining path.

Mistakes to avoid

• Deleting one URL and assuming the whole site is clean. There may be a copy, another path, or a redirect.
• Editing the production database without a backup. A content or option mistake can break the site and destroy evidence.
• Redirecting every unknown URL to the homepage. An irrelevant redirect can conceal the problem and create a poor visitor experience.
• Blocking the URL in robots.txt. The content remains at the origin, and a crawler may lose access to the removal response.
• Relying on one scan or checksum. Its scope is limited; accounts, database, server, and persistence need separate checks.
• Sending the phishing link to colleagues for testing. Do not increase exposure or ask anyone to submit data.
• Requesting a review before removing the source. An active finding can lead to a failed review and repeated cleanup.

Prevent another phishing page

Update WordPress and its plugins and themes, remove unused components, use MFA and least-privilege accounts, close public registration that is not needed, moderate submissions, and keep tested off-site backups. Give developers and vendors individual accounts instead of a shared administrator login. Limit upload and database capabilities to what each function needs.

Maintain a baseline of legitimate URLs, administrator accounts, and change-approval steps. Enable Search Console notifications and assign someone to review them. After an incident, monitor new pages, file changes, redirects, and user accounts on a schedule that fits the site; retain logs for as long as the host allows. Our guide to securing WordPress for a small business covers additional account and component controls.

When to escalate

Contact your host or a security specialist if the page returns after deletion, new accounts appear, many files have changed, you cannot tell whether a fake form collected customer data, or transactions are affected. Coordinate with the business owner, host, and authorised privacy contact; do not upload backups or victim data to an open channel.

Rawat Web offers initial diagnosis through Website Emergency Assistance and a Free Audit. Send the domain, phishing URL, and symptoms without victim data or passwords. The initial diagnosis does not require access. If cleanup is needed, we agree the scope and cost before making changes, then document the checks and outcome. We do not promise a date when Google removes a warning or a URL disappears from search results.

Frequently asked questions

Can I delete the phishing page from WordPress immediately?

Limit exposure after you preserve the URL, screenshot, time, backup, and logs you can safely retain. If the page is active, coordinate quarantine or removal with the host. Then close the source and account that created it, not just the post itself.

What status should a deleted phishing URL return?

If the page was unauthorised and has no equivalent replacement, it should generally return 404 or 410. A restored legitimate page can serve its correct content. Redirect only to a relevant replacement; do not send every URL to the homepage.

Can robots.txt remove a phishing page from Google?

No. robots.txt controls crawling; it does not remove content from the server. Remove or secure the source, return the correct response, and use Removals only as a temporary step if needed.

Is removing one page enough to request a review?

Not necessarily. Google’s report provides sample URLs. Check the category and patterns across the site, close the root cause, test as a visitor, and describe verified work in the Request Review.