Phishing is an attack in which someone impersonates a person or organization you trust, like your host, registrar, bank, or colleague, in order to steal information, redirect a payment, or talk you into an action that helps them. The message is the delivery vehicle, and the goal is always the next action you take.

If you run a website, you’re on both sides of this problem. Your hosting panel, domain registrar, WordPress admin, email, and payment accounts are all valuable targets, and if an attacker gets in through any of them, your site can quietly end up hosting phishing pages aimed at someone else’s customers.

In this guide we’ll walk through how phishing actually works, the forms it takes, the signals that give it away, what it does to a website’s reputation, and what to do in the first hour after you suspect you’ve been caught. If you want the shorter conceptual primer first, start with our phishing explainer and come back here for the site-owner view.

Contents:

• How does phishing work?
• What are the common types of phishing?
• How do you recognize a phishing attempt?
• Can phishing affect my website?
• How do you protect your accounts and your website?
• What should you do after a suspected phishing attack?
• Frequently asked questions

How does phishing work?

Nearly every phishing attempt follows the same four beats: a message arrives, the message creates a reason to act, you’re asked to do one specific thing, and the consequence lands somewhere you didn’t expect.

Here’s a quick hypothetical: An email appears to come from your hosting provider with the subject “Final notice: account suspension in 24 hours.” It says an unpaid invoice will take your site offline tomorrow, and it includes a “Review billing” button. The button leads to a page that looks exactly like your host’s login screen, on a domain that’s close to the real one but not the real one. You enter your username, password, and the six-digit code from your authenticator app. The page spins, then redirects you to the genuine host’s website, which looks completely normal. Meanwhile, the attacker has used those credentials and that code in real time to open a session of their own.

Notice what the lure was doing. It wasn’t really about billing. It was about compressing your decision time so you’d type a password on a page you hadn’t checked.

To be clear, receiving a phishing message doesn’t mean anything has been compromised, and clicking a link usually doesn’t either. A click can expose your IP address and browser details, and it can land you on a page that tries to exploit your browser or hand you a file, but on its own a visit to a credential-harvesting page doesn’t give anyone access to your accounts. What matters is whether you submitted something, downloaded something, or approved something. Our walkthrough of a real phishing email in How to Recognize & Avoid Phishing Emails: A Cautionary Tale shows how convincing the staging can be when you see it step by step.

What are the common types of phishing?

It helps to separate two things that often get mixed together: how an attacker targets you, and how the message reaches you.

Targeting is the difference between bulk and bespoke. Mass phishing goes out to huge lists and plays the odds with generic branding, generic urgency, and no idea who you are. Spear phishing is written specifically for you. It names your host, your plugin stack, your agency, or the client whose invoice you’re waiting on. Attackers research spear-phishing targets using whatever is public. This could be your site’s team page, WHOIS data, LinkedIn, past press coverage, even the contact form confirmation that tells them who answers it. Language tools have made that kind of personalization cheaper and the writing cleaner, which mostly means one old heuristic is weaker than it used to be: bad grammar is no longer a reliable tell.

Delivery is the channel, and there are several:

• Email: Still the most common, often with a spoofed sender name or a lookalike sending domain. Weak email authentication on your own domain makes you easier to impersonate, which we covered in Missing DMARC Records Lead to Phishing.
• SMS and chat apps (“smishing”): Where the short format hides the real destination behind a shortened link.
• Voice calls (“vishing”): Including calls that claim to be your host’s support desk and ask you to read back a code “to verify your identity.”
• QR codes: Printed on notices, invoices, or stickers, which move the link out of your email client, away from any link scanning it does, and onto your phone.
• Collaboration tools: Like Slack or Teams, where a message from a compromised internal account carries far more trust than an outside email ever would.

The channel changes the signals you can check. The underlying request for credentials, a code, a payment, or a file rarely changes.

How do you recognize a phishing attempt?

Start with the request rather than the appearance. Most phishing asks for one of four things, and all four deserve a pause:

1. A link that takes you to a login screen you didn’t go looking for.
2. A one-time code or an approval prompt. Nobody legitimate needs your authenticator code read aloud or pasted into a chat.
3. A payment, or new payment details. Changed bank instructions on a familiar invoice are a classic.
4. A file or an install. An attachment, a “required update,” a plugin ZIP from outside the repository.

Then look at the context. Was it unexpected? Does it create a deadline, a penalty, or an emotional hook? Does the sending domain match the organization exactly, character for character? Hover the link and read the actual host before the first single slash, since that’s the part your browser obeys.

Three assumptions are worth correcting here, because all three get people caught.

HTTPS doesn’t prove trustworthiness. The padlock means the connection is encrypted, nothing more; certificates are free and attackers use them routinely. Polished writing doesn’t prove authenticity either. Correct spelling, real logos, and accurate account details can all be copied or researched, and conventional multi-factor authentication, while absolutely worth having, isn’t a force field. A phishing page that proxies your login in real time can capture your SMS or app code and use it within its validity window, and an attacker who steals a valid session cookie can sometimes skip the login step altogether.

Verification is the habit that holds all of this together. Don’t verify using the message. Open a new tab and type the address or use your own bookmark, or call the number printed on your card or on the contract you already have. If a colleague sends an unusual payment request, call them back on a number you already had. It’s a thirty-second detour that defeats most of the attacks you’ll see.

Can phishing affect my website?

Yes, in two distinct ways, and the second one surprises people.

The first is direct. If an attacker phishes your hosting, registrar, FTP/SFTP, or WordPress administrator credentials, they have the same access you do. That’s enough to add an admin user, upload a file, change DNS, or install a malicious plugin. Some phishing attacks target site administrators for exactly that reason, arriving as a fake security notice or a fake required update.

The second is that your site becomes the hosting infrastructure for someone else’s phishing. Attackers commonly drop a convincing replica of a bank, courier, or webmail login into a subdirectory of a legitimate site (something like /wp-content/uploads/.cache/secure-login/) and leave the homepage completely untouched. Why? Because a real domain with real history is less likely to be filtered than a brand-new one. You can browse your site all day and see nothing wrong.

The fallout is real even though your pages look fine. Browsers can show a deceptive-site warning to your visitors. Your domain can be flagged by blocklists and reputation services, which hurts search visibility and, worse, email deliverability. Your host may suspend the account to stop the abuse. Payment processors notice. And if your customers get the warning screen, you’re explaining it to them whether or not you understand it yet.

If that’s your situation right now, our dedicated walkthrough covers the cleanup in detail.

How do you protect your accounts and your website?

Split this into two lists, because they’re maintained by different habits.

People and team practices

• Use a password manager, and give every service its own password. A manager also quietly checks the domain before it autofills, so it won’t offer your host’s credentials to a lookalike site.
• Turn on multi-factor authentication everywhere it’s offered, and prefer app-based codes over SMS where you have the choice.
• Where a service supports passkeys or FIDO security keys, use them for your highest-value accounts. These are bound to the real site’s domain, which means a lookalike page has nothing useful to collect.
• Agree on one rule for money and credentials: any request to change payment details, send funds, or share a login gets verified by a call-back on a number you already had. Put it in writing so nobody feels awkward enforcing it.
• Protect the recovery path too. An attacker who can reset your password doesn’t need to phish it, so keep recovery email and phone numbers current and locked down.

Website controls

• Keep core, themes, and plugins updated, and remove what you don’t use. Unmaintained code is how a phished credential turns into persistent access, and how an unphished attacker gets in anyway.
• Apply least privilege. Most contributors don’t need Administrator. Fewer admin accounts means fewer accounts worth phishing.
• Monitor for change. Server-side scanning and file integrity monitoring compare what’s on disk against what should be there, which is how hidden directories get noticed before a blocklist notices them for you.
• Put a web application firewall in front of the site to filter malicious requests and help block exploitation attempts against known vulnerabilities.

On our own tooling, worth being precise: SiteCheck is a remote scanner, so it examines publicly accessible content. That makes it fast and free to run, but a clean remote result can’t establish that every file on your server is clean. A phishing kit sitting in an obscure path with nothing linking to it may simply not be reachable from outside. Server-side scanning and file integrity monitoring look at the files a remote scan can’t see; malware removal addresses what’s found; a WAF reduces the exposure that let it happen. Together those layers lower risk considerably. None of them, ours included, can promise complete protection.

For a fuller treatment of the defensive side, see How to Protect Your Website from Phishing.

What should you do after a suspected phishing attack?

Match the response to what actually happened. Over-reacting wastes a day; under-reacting leaves someone logged in.

You only clicked the link. Close the tab. Don’t enter anything. Clear the site’s cookies if you’re unsure whether you were already logged in to the real service in another tab, then log in to that service directly and check recent activity. No credentials submitted usually means no further action, but stay alert for a follow-up call or message, since a click sometimes confirms to the sender that you’re a live target.

You submitted credentials. Move quickly, in this order:

1. Change the password by going to the legitimate service yourself (typed address or bookmark, never the link in the message).
2. Change it anywhere else you reused it.
3. Revoke active sessions and sign out all devices, so a stolen session cookie stops working.
4. Review MFA enrollments and remove any device or app you don’t recognize.
5. Check recovery email, recovery phone, and, for email accounts, forwarding rules and filters. Attackers often add a quiet forward to keep reading your mail after you’ve changed the password.
6. If the account touches your site (host, registrar, CMS admin, SFTP), assume the site needs checking and go to the next step.

You downloaded or ran a file. Disconnect the machine from the network, run a full scan with reputable endpoint software, and treat every credential stored in that machine’s browser as exposed. Change them from a different, known-clean device. If it’s a work machine, tell your IT contact before you clean anything, because they may want to look first.

You found a phishing page on your own site. Preserve what you can before you start deleting: note the file paths, keep copies of the files, and pull the relevant access logs. Then look past the page itself. Deleting the fraudulent files makes the symptom disappear while leaving the cause completely intact. Sites get re-infected within days precisely this way. So: remove the malicious files, find and close the entry point, hunt for backdoors and unexpected admin users, rotate every credential involved, and only then request review from the blocklisting services and your host.

If you suspect your site has been compromised and you’d rather not work through it alone, our team can inspect the server side, remove what’s there, and help you close the hole that allowed it. Either way, the thing to carry out of this piece is the smaller habit: when a message asks you for credentials, a code, or money, verify it somewhere the message can’t reach. That one pause prevents most of what follows.

Frequently asked questions

Can you get hacked just by clicking a phishing link?

Usually not. A click can reveal your IP address and browser details and may land you on a page that offers a malicious file, but it doesn’t hand over your accounts by itself. Risk rises sharply once you submit credentials, enter a one-time code, approve a prompt, or run a download.

Does MFA stop phishing?

Multi-factor authentication blocks many attacks and you should use it everywhere, but it isn’t absolute. A real-time phishing page can capture and replay your SMS or app code, and a stolen session cookie can bypass login entirely. Passkeys or FIDO security keys, where supported, resist that far better.

What should I do if my website is hosting a phishing page?

Record the file paths and save copies and logs first, then remove the malicious files. Next, find the entry point, hunt for backdoors and unknown admin users, and rotate every related credential. Deleting the pages alone leaves the vulnerability and attacker access in place, which invites reinfection within days.