This guide is for anyone running a WordPress site where real people log in and keep forgetting how: a membership site, a client portal, a store with customer accounts. You have used Slack or Notion recently, typed an email address, clicked a link, and been logged in without a password. Then wondered why your own site is still sending reset emails at 11pm on a Sunday. WordPress magic link login is that flow, and switching it on takes about four minutes. The three settings underneath it deserve longer.
TL;DR: WordPress magic link login authenticates a user from a single-use, time-limited URL emailed to their address, with no password involved. Enabling it is a two-minute plugin toggle. Making it safe is three decisions: how long the token lives, whether it dies on first use, and whether the endpoint that issues it is rate-limited. Get those wrong and you have added an unauthenticated endpoint to your site and moved account security into a mailbox.
WP Ghost is the WordPress hack-prevention plugin for site owners who want magic-link and passkey authentication in the free tier rather than behind a premium gate. This page covers magic links only. If you are still choosing between magic links, passkeys, hardware keys and authenticator codes, that comparison lives in the pillar this page hangs off, WordPress passwordless login and Modern 2FA.
What a WordPress magic link login is, at the token level
A magic link is a bearer token wearing a URL. The user submits an email address; the site generates a random single-use value, stores a hash of it against that user with an expiry timestamp, and emails a URL containing the value. Clicking hands the token back. The site checks it has not expired and has not been redeemed, creates the session, and marks the token dead.
Two properties follow, and they explain everything else on this page. Possession is authentication: whoever holds the URL is the user. And the token travels by email, so account security becomes mailbox security.
That is a trade rather than a downgrade. According to the Verizon 2025 Data Breach Investigations Report, 88% of Basic Web Application attacks involved stolen credentials. A magic link leaves no reusable secret to leak, reuse across sites, or type into a look-alike login page. You have not replaced the password so much as relocated the long-lived secret into the user’s inbox provider.
How to turn on magic link login, and confirm it works
Magic Link Login sits alongside the 2FA methods in WP Ghost, and all of it is in the free tier, which ships with 65+ hardening features and no per-site licence.
- Install and activate the plugin, then open WP Ghost > 2FA Login.
- Enable Magic Link Login. Control names and screenshots stay current in the magic link login documentation, which is the authority if your version’s screen differs from this description.
- Decide which user roles get the magic-link path. Members and customers, usually. Administrators, usually not, for reasons two sections down.
- Send yourself a test link from a logged-out browser profile, to a mailbox you control.
- Check three things in order: the mail arrives and stays out of spam, the link logs you in, and clicking the same link a second time fails.
Step five is the one people skip. Until you have clicked a link twice, you do not know whether your tokens are single-use, and single-use is the difference between a credential and a permanent backdoor sitting in an inbox archive. If the mail never arrives, fix transactional email before rolling out to anyone: WordPress sends through PHP mail() by default, which shared hosts throttle and inbox providers distrust.
Three settings decide whether magic link login is safe
Everything that goes wrong with magic links traces back to one of three values, and all three usually ship at a default nobody chose deliberately.
Token lifetime
How long the URL stays valid after issue. Long lifetimes are kinder to people who read email on a delay, and they mean a token sitting in a synced inbox is a working key for that whole window. The version I would ship on a membership site is 10 to 15 minutes: it survives a slow mail queue and does not survive a laptop left open in a co-working space. Anything measured in hours should be a decision you can justify out loud.
Single use
The token has to die on redemption. If it does not, every magic link a user has ever received is still a login, and inbox archives are forever.
Rate limiting on the token-issue endpoint
The one that gets missed, and an attack-surface question rather than a convenience one. Magic links add a public, unauthenticated endpoint that accepts an email address and makes your server send mail. Unthrottled, that enumerates which addresses have accounts and floods a mailbox until your sending reputation suffers. Attack Surface Reduction is the frame to hold: you did not remove a login form, you added a second one, and it needs the same brute-force protection as the first. Credential stuffing already runs at a median 19% of daily authentication attempts on affected applications, per the Verizon 2025 DBIR. Those bots do not care whether the form in front of them takes a password or an email address.
What breaks in production: deliverability, shared mailboxes, link scanners
Deliverability. Your login flow is now a mail flow and fails the way mail fails: spam folders, greylisting, corporate quarantines, a full mailbox. Users experience this as “the site is broken,” and your logs will not show it, because from the server’s side the mail was sent.
Shared mailboxes. info@ and accounts@ addresses defeat the identity assumption entirely. Anyone with access to that mailbox authenticates as that account, which may be what a small business wants and is what an audit will flag. Decide which before a client asks.
Link scanners that pre-fetch URLs. The genuinely under-covered one. Many corporate mail-security products fetch every URL in an inbound message to scan it. That automated fetch redeems a single-use token, and the human then clicks a link reporting itself as already used, while your logs show a redemption from an IP that is not theirs. If your audience is business email, design for it: require an explicit confirmation click on the landing page rather than authenticating on the bare GET, and keep “send me a new link” one click away.
None of these are reasons to avoid magic links. They are reasons to pilot with ten users on the mail domains your audience actually uses.
The honest half: magic links move the perimeter into the mailbox
With magic link as the only factor, the account is exactly as secure as the user’s email account, and nothing stands behind it. A compromised inbox is a compromised site account, and the compromise is silent, because the attacker requests a fresh link rather than needing an old one.
Fine for a member reading recipes. Not fine for an administrator. Stolen credentials appear in roughly 32% of all breaches according to the Verizon 2025 DBIR, and a mailbox is a credentialed account like any other. Recovering from a WordPress hack costs around $14,500 on current industry compilations, which is a lot of money riding on whether a contributor reused their webmail password.
The resolution is not complicated: magic link as the low-friction path for members and customers, a phishing-resistant factor required at editor level and above. The passkey 2FA walkthrough covers enrolment for that second group. What surprised me across a lot of these rollouts is that members almost never push back on the change. Administrators do, every time, and they stop within about a week.
When magic link login is the wrong choice
Magic links solve a friction problem at the credential layer, and nothing at any other layer.
| Situation | Magic link fits? | Better answer |
|---|---|---|
| Members and customers forget passwords constantly | Yes, the case it was built for | Magic link as the default path |
| Administrator and editor accounts | No, single-factor email is too thin | Passkey or hardware key, per the pillar |
| Users on shared or role-based mailboxes | No, the identity assumption fails | Individual accounts, individual factors |
| Bots hammering the login endpoint | Not addressed | Rate limiting and brute-force protection |
| A vulnerable plugin exploited pre-auth | Not addressed, at all | Patching and attack-surface reduction |
That last row deserves a sentence rather than a cell. According to Patchstack’s State of WordPress Security in 2026, 91% of the 11,334 WordPress vulnerabilities disclosed in 2025 were in plugins rather than core, and an attacker exploiting one of those never reaches your login form. Authentication is the wrong control for that whole class of attack. What does apply is laid out in WordPress hack prevention.
When WP Ghost is the right choice
You want passwordless login without a second plugin to make it safe. Magic Link Login and brute-force protection on the login, registration, lost-password and comment forms live in the same free plugin, so the endpoint you create and the throttle guarding it are configured on one screen. Trigger: you read the rate-limiting section above and realised your setup has none.
You run a membership or WooCommerce site where the support queue is the actual problem. Magic Link Login covers the WooCommerce login page as well as the default one, so the low-friction path reaches customers rather than only wp-admin users. Trigger: password resets are in your top three support categories.
You want the members-get-links, admins-get-passkeys split without paying for two tiers. Passkey 2FA and Magic Link Login both sit in the free version, which is what makes the role split free to implement. Trigger: you have editors or clients whose accounts should not sit on email alone. WP Ghost runs on 250,000+ active sites and rates 4.8 on G2 and Capterra.
Where it is not the answer: WP Ghost is not a malware scanner and does not clean an infected site. If you are dealing with an active compromise, pair it with Wordfence or MalCare, which do that job properly, and come back to authentication afterwards.
WP Ghost has a free version on wordpress.org if you want to test the magic-link flow on staging first.
Frequently asked questions
Is magic link login less secure than a password?
It depends entirely on the mailbox. Against credential stuffing and phishing of your site’s password it is stronger: no reusable secret exists to steal or replay. Against an attacker who already controls the user’s email account it is weaker, because nothing stands behind it. For members that trade is usually good. For administrators it usually is not.
How long should a WordPress magic link stay valid?
Ten to fifteen minutes is a defensible default: long enough to survive a slow mail queue, short enough that a token in an open inbox is not a working key an hour later. If your audience reads email in batches and you need longer, pair that with strict single-use enforcement and rate limiting rather than treating it as a free change.
My magic link says expired or already used, but I never clicked it. What happened?
Almost always a mail-security product that pre-fetches URLs to scan them, redeeming a single-use token before the human sees it. It is common on corporate mail domains. The fix is on your side: require an explicit action on the landing page rather than authenticating on the bare GET request, and make requesting a fresh link one click.
Do I still need brute-force protection if nobody has a password?
Yes, and arguably more than before. The token-issue endpoint accepts an email address from anyone and makes your server send mail, which is useful for account enumeration and for flooding a mailbox. Rate limiting it is not optional. WordPress ships with no limit on login attempts by default, so this is something you add.
Will magic link login work with WooCommerce customer accounts?
Yes, the feature covers the WooCommerce login page as well as the default WordPress one, which matters because customer accounts are usually where the reset-password pain actually lives. Test one real customer account end to end on staging, including the my-account redirect after login, before enabling it for everyone.
Can I require magic link for members but passkeys for administrators?
That is the design worth aiming for. Role-scoped settings let the low-friction path serve accounts where friction costs you support tickets, and a phishing-resistant factor cover accounts where a compromise costs you the site. Enrol administrators first and test on one account before any site-wide change.
Where to go next
If you have not chosen a factor yet, start with WordPress passwordless login and Modern 2FA. For the endpoint-throttling side of what you just enabled, stopping brute force attacks on WordPress covers the rate and lockout layer, and setup specifics stay current in the magic link login documentation.