arrow_back Back to Blog
lovable custom domainlovablednsseo

Lovable Custom Domain: Setup and Fixes

·

Putting a custom domain on a Lovable app takes about four minutes when it works. When it doesn’t, it can eat a whole evening, because the dashboard says “Verifying” and nothing else, and DNS is the one part of the stack nobody on a small team actually understands.

First, the boring prerequisite: a Lovable custom domain needs a paid plan. On the free plan you’re on yourapp.lovable.app and that’s that.

The two records

You either buy the domain through Lovable (it sets everything up for you, including www) or you connect one you already own. If you connect your own, Lovable offers an automatic setup for some registrars that logs in and writes the records for you. When that works, use it. When it doesn’t, or your registrar isn’t on the list, you add two records by hand:

  • An A record for the root (@) pointing at 185.158.133.1
  • A TXT record at _lovable with a value that starts with lovable_verify=. Copy the exact string from your project’s domain settings, it’s unique per project.

If you’re connecting a subdomain like app.yourstartup.com, the TXT host becomes _lovable.app. People miss this constantly and put the TXT on _lovable, which verifies nothing.

Then you wait. Usually it’s minutes. Lovable’s own docs say up to 72 hours, which is technically true and practically useless as advice.

Why it’s stuck on “Verifying”

In rough order of how often we see each one:

There’s an old record in the way. Your registrar parked the domain and added its own A record pointing at a “coming soon” page, and now you have two A records for @. Half the lookups go to Lovable, half go to GoDaddy’s parking server. Delete everything on @ that isn’t Lovable’s. Same for AAAA records: Lovable doesn’t give you an IPv6 address, so any AAAA on the root sends IPv6 visitors somewhere else entirely. Delete it.

You’re on Cloudflare with the orange cloud on. If your DNS lives on Cloudflare and the A record is proxied, Lovable sees a Cloudflare IP instead of its own and never verifies. Either turn the proxy off (grey cloud, “DNS only”), or use the “Uses Cloudflare or similar proxy” option in Lovable’s advanced settings, which switches you to a CNAME setup and drops the TXT check.

A CAA record blocks the certificate. This one is invisible unless you know to look. A CAA record says which certificate authorities may issue SSL for your domain. If someone added one years ago allowing only, say, DigiCert, Lovable can’t get a certificate and you’ll sit on “Setting up” forever. Lovable needs one of Google Trust Services (pki.goog), Let’s Encrypt (letsencrypt.org) or SSL.com. Check with dig CAA yourdomain.com. No output means no CAA record, which means no problem.

You typed the TXT value with quotes, or with the host appended. Some DNS panels add the domain to the host automatically, so _lovable.yourdomain.com becomes _lovable.yourdomain.com.yourdomain.com. Run dig TXT _lovable.yourdomain.com +short and see what the world actually sees.

We had a founder message us on a Sunday with “my domain has been verifying for three days.” Their DNS was at Namecheap, records looked perfect in the panel. dig showed the A record pointing at an old Webflow IP. Turned out the nameservers weren’t Namecheap’s at all: two years earlier they’d moved DNS to Cloudflare for a different project and forgotten. They were editing records in a panel the internet wasn’t reading. Run dig NS yourdomain.com before you touch anything else. It would have saved them three days.

The SEO parts Lovable leaves to you

This is where I get opinionated, because getting the domain live is not the same as getting it indexed properly.

The lovable.app URL never goes away. You can’t remove it. Your app is now reachable at yourapp.lovable.app and yourstartup.com, same content on both. Google can pick either one as the “real” page, and it doesn’t always pick the one you paid for. Add a canonical tag pointing at your custom domain on every page, and set your custom domain as the primary one in Lovable.

The www redirect is a 302. Lovable redirects www to your root (or the other way around) with a 302, which tells Google the move is temporary. It works for users. For search, a 301 is the honest signal. We found the same problem on our own site this week with a different host, where /pricing went to /pricing/ with a 307, and Search Console started listing our pages as duplicates with Google choosing the slash-less version. If you care about rankings and your DNS is on Cloudflare, you can put a proper 301 redirect rule for www in front of it. If you don’t care about rankings yet, ignore this, it’s not urgent.

And none of this fixes the SPA problem. A custom domain makes your app look legitimate. It doesn’t make Google see content that’s rendered in JavaScript. That’s a separate fight, and we wrote it up in why Google can’t read your Lovable app.

One domain, one project

You can only connect a given domain to one Lovable project, and each project has one primary domain. You can, however, point different subdomains at different projects: app.yourstartup.com on one, yourstartup.com marketing site on another. That’s actually a sane setup for most startups, and it means your marketing page can be rebuilt without anyone touching the product.

If you’re planning to leave Lovable hosting later, say for Vercel or Cloudflare, keep your DNS somewhere you control (Cloudflare is free and fine) rather than buying the domain inside Lovable. Moving a domain between registrars is a 5-day transfer with an auth code. Changing two DNS records is five minutes.

Domains are a small piece of taking a Lovable app to production. If yours is live on a custom domain and you’re now worried about the backend behind it, our Lovable Cloud to Supabase migration is the usual next step. Or ask us and we’ll look at your DNS with you.