Login works in the preview and not on the real domain

Authentication is tied to exact addresses. The editor runs on one address, your live site on another, and every provider treats an address it does not recognise as an attack. Five causes, in the order they actually happen.

1. Your domain is not in the allowed redirect list

The provider only sends users back to addresses you listed in advance. The preview address was added automatically; your own domain was not.

How to checkOpen the authentication settings and read the redirect and site URL lists. Your live domain, with and without www, should both be there.

What to changeAdd them, including the exact protocol. Save, then sign out completely and try again in a private window.

A trailing slash counts as a different address with some providers.

2. The site URL still points at the editor

Magic links and password resets are built from a single configured address. If that address is still the preview, every emailed link sends your customers into your editor.

How to checkRequest a password reset for yourself and look at where the link actually points.

What to changeSet the site URL to your live domain. Keep the preview address in the allowed list so both still work.

This one usually survives launch unnoticed until a real customer cannot get back in.

3. Social login was never configured for production

The social provider has its own list of allowed addresses and its own keys, and generated apps often ship with development credentials that only work on localhost.

How to checkTry the social button on the live site and read the provider's error page, not your app's.

What to changeCreate production credentials with the provider, add your live domain to their allowed list, and put the new keys in your host's environment.

Some providers require a verified privacy policy and a review before the button works for anyone but you.

4. The session cookie cannot be set on your domain

Cookies are refused when the site is not served over a secure connection, when the domain does not match, or when third-party cookies are blocked on a phone.

How to checkSign in, then look at the browser's storage panel for the session cookie. If it is missing, the browser refused it.

What to changeServe everything over HTTPS, keep the authentication requests on the same domain as the app, and set the cookie attributes the provider recommends.

5. The user exists in the editor project, not in the live one

Many exports point at a different project or database in production. Your account simply is not there, so the credentials are wrong.

How to checkLook at the user list of the project your live site actually talks to.

What to changePoint the live site at the right project, or create the accounts where they belong. Then verify with a brand new sign-up on the live domain.

Test every launch with a fresh email address, not the account you have been using all along.

Not one of these five?

Send me the link and the exact error text. I will tell you what is broken and what it would take to fix, in writing, within 24 hours. That part is free, and you are not obliged to hire me afterwards.

If you do want it fixed: emergency rescue starts at $600, and I name one fixed number before I start.

Send me the link