Why does my Lovable login work in preview but not after I publish?

Sign-in is a round trip. Your app sends the user to Supabase Auth (or to Google through Supabase), and Supabase sends them back to a URL. It will only return to a URL that's on the Redirect URLs allowlist. If none matches, it falls back to the Site URL.

The preview runs on a different address from your published app, so a setup that works in one can fail in the other:

• Lovable Cloud (built-in backend): Lovable sets the Site URL to your published lovable.app address when you publish. It also adds a custom domain to the redirect URLs once the domain is live. But a Site URL you set by hand stays unchanged, and your own Google credentials still need updating separately.
• Your own Supabase project: nothing updates for you. You have to add every address yourself.
• Hardcoded URLs in code: if the AI wrote redirectTo: 'https://id-preview--….lovable.app' or http://localhost:3000, users get sent there regardless of your settings.

1. Find out which backend you're on. If your project has a Cloud view (More → Cloud), you're on Lovable Cloud. If you connected a Supabase project yourself, the settings live in the Supabase dashboard.

2. Open the URL settings.

• Lovable Cloud: More → Cloud → Users → Auth settings → Advanced
• Own Supabase: Authentication → URL Configuration

3. Set the values.

• Site URL: your main live address, e.g. https://yourdomain.com. This is the fallback, and it's what email links use by default.
• Redirect URLs: add every address users really sign in from:

https://yourdomain.com/**
https://www.yourdomain.com/**
https://yourapp.lovable.app/**
http://localhost:3000/**

In Supabase patterns, * doesn't match dots or slashes but ** matches anything. Supabase recommends exact paths for production, so once things work you can narrow /** down to your real callback path. Leave localhost off unless you develop locally.

4. Remove hardcoded redirect targets. Search the code for lovable.app, localhost and redirectTo. Build the redirect from the address the user is actually on:

// OAuth (Google, GitHub, ...)
await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: { redirectTo: `${window.location.origin}/` },
});

// Email confirmation / magic link
await supabase.auth.signUp({
  email,
  password,
  options: { emailRedirectTo: `${window.location.origin}/` },
});

5. If you use your own Google OAuth credentials, open Google Cloud Console → your OAuth client:

• Authorized JavaScript origins: add https://yourdomain.com.
• Authorized redirect URIs: on your own Supabase this is your project's callback, https://<project-ref>.supabase.co/auth/v1/callback (copy it from the Google provider page in Supabase). On Lovable Cloud with your own credentials, add every redirect URI Lovable lists under Auth settings → Google, then go back to Lovable, select those URIs and click Save. Lovable adds a new custom domain's URI to that list but doesn't select it for you.

6. Test it like a new visitor. Open a private window on the live domain and sign up and sign in. Request a new email, because old confirmation emails still carry the old redirect target.

Paste this into Lovable, Bolt, Cursor, Claude, ChatGPT, Replit, v0 or whichever tool you build with. Replace the bracketed parts first.

Sign-in works in the preview but fails on my published app at https://yourdomain.com. Please fix only the auth redirect handling and don't redesign anything.
1. Find every place that sets redirectTo or emailRedirectTo, or hardcodes a lovable.app preview URL or localhost. Replace them with `${window.location.origin}` plus the existing callback path.
2. Tell me exactly which Site URL and Redirect URLs to set in the auth settings for https://yourdomain.com and https://yourapp.lovable.app. If this project is on Lovable Cloud, update them for me.
3. If Google sign-in uses my own OAuth credentials, list the exact redirect URIs I must add in Google Cloud Console.
Don't change the login UI, the database or any other pages.

This one tends to come back. It happens when you connect a new domain, switch from www to the apex domain, move from Lovable Cloud to your own Supabase, or let an AI edit rewrite the auth helper.

Heedza checks your live login and signup pages on a schedule and emails you a screenshot and a Lovable fix prompt if the page breaks or the form disappears. It doesn't sign in with a real account, so make a private-window sign-in part of every domain change too. To see what Heedza checks on your live site, run the free scan on your published URL.