Publishing & Custom Domains

Publish your site, connect a custom domain, and set up SEO and analytics basics.

16 min read·6 parts·beginner

You've built the thing. Now you have to actually ship it — put it at a URL people can type, tell search engines it exists, and know when someone visits. This is the last lesson of the beginner track, and it's the one that turns a project into a website.


Part 1 · Preview vs. Published

Every Lovable project has two URLs and it's important to know which is which. Confusing them is the single most common "why can't my friend see my site?" question.

Figure 1.1
Previewid-preview--…lovable.appUpdates on every editLogin required by defaultYour workshoppublishPublishedyourname.lovable.appOnly updates when you click PublishPublic — anyone with the linkThe storefront
The preview URL is your workshop. The published URL is the storefront. Publishing copies the current version from one to the other.
  • Preview reflects every edit in real time. It's gated by a Lovable login, so sending it to a client will make them hit a login wall. Use it for yourself and for share-preview links (7-day public snapshots).
  • Published is the version the world sees. It only changes when you explicitly hit Publish, which is exactly what you want — half-finished edits should never go live.
  • Backend changes (database, edge functions) are the exception: they deploy immediately when you save. Only frontend changes wait for Publish.
"Why can't my friend see my site?"
You almost certainly sent them the preview URL. Either publish and send them the yourname.lovable.app URL, or use Share → Share preview to create a 7-day public snapshot of the preview.

Part 2 · Publishing your first version

Publishing in Lovable is one click, but there's a rhythm to it that makes shipping feel safe instead of scary. The rhythm is: review, publish, verify, share — in that order, every time.

Figure 2.1
  1. 1Review

    Click through the preview one last time. Home, then every nav link, then a form submit.

  2. 2Publish

    Top-right Publish button. First publish gives you a URL you can rename to something clean.

  3. 3Verify live

    Open the yourname.lovable.app URL in an incognito window. If it works there, it works for everyone.

  4. 4Share

    Send the published URL — never the preview URL — to the people you want to see it.

A four-step publish loop. Verifying on the live URL is the step people skip and regret.

Renaming the Lovable URL

Your first publish creates a URL like project-abc123.lovable.app. In the publish dialog you can rename the slug to something readable —ahmadnajmi.lovable.app, studio-lumen.lovable.app. Lowercase letters, numbers, and hyphens only.

Re-publishing after changes

  • Every subsequent publish becomes a new version. Old versions are kept so you can roll back the live site if a bad release slips out.
  • Publish in small batches. One publish per meaningful change is better than a mega-publish with ten things in it — if something breaks, you know exactly which change caused it.
  • You don't lose the preview when you publish. The preview keeps moving; published stays frozen at the last publish.

Part 3 · Connecting a custom domain

ahmadnajmi.lovable.app is fine for a preview link, but for anything you want people to remember you want ahmadnajmi.com. Custom domains work as long as the project is published — Lovable needs somewhere to point them at.

Figure 3.1
RegistrarNamecheap, Google Domains, Lovable itself…DNS recordsA @ → 185.158.133.1 • A www → 185.158.133.1 • TXT _lovableLovableVerifies, provisions HTTPS, serves the siteyourdomain.comLive over HTTPS
Custom domains have four moving parts. The registrar is where you bought the domain; DNS records tell the internet where to look; Lovable serves the site; HTTPS is automatic once the records match.

The three-record recipe

  • A record on @ — points the bare domain (yourdomain.com) at 185.158.133.1.
  • A record on www — same IP, so www.yourdomain.com resolves too. This one is easy to forget, and then www visitors get a "site not found" error.
  • TXT record on _lovable — the verification token Lovable shows in the Connect Domain dialog. Copy it exactly.
DNS takes time
Propagation can be five minutes or several hours (rarely up to 72). If a domain shows "Verifying" for a while, that's normal — grab coffee, don't retry every 30 seconds. Once verified, Lovable provisions HTTPS automatically.

Common gotchas

  • Both apex and www must be added as separate entries in Lovable — one doesn't imply the other.
  • Old records left behind from a previous host will fight the new ones. Delete or update conflicting A records before verifying.
  • Cloudflare proxy — if your DNS lives behind Cloudflare's orange cloud, tick "Domain uses Cloudflare or a similar proxy" in the Advanced section of the connect dialog.
  • Bought through Lovable — DNS is managed for you: Project Settings → Domains → ⋯ → Configure → Manage DNS.

Part 4 · SEO basics on a live site

Being live is not the same as being findable. A published site with no metadata shows up in Google as "Untitled" with a blank description, and social share cards look empty. Ten minutes of SEO basics fixes this permanently.

The four tags that matter most

  • Title — under 60 characters, includes the page's real subject. This is the big blue link in Google.
  • Description — under 160 characters, a real sentence about what the page is. This is the grey text under the title.
  • og:title / og:description / og:image — the same, but for social shares. Without an image, Slack, WhatsApp and X show a bare link.
  • Canonical URL — the "real" URL of the page. Prevents duplicate-content problems if the same page is reachable at two URLs.
Figure 4.1
Avoid
Template defaults
<title>Lovable App</title>
meta description = "Lovable Generated Project"
No og:image. Search results are grey; shares are blank.
Do
Real title, real description
<title>Dr Ahmad Najmi — Researcher & Educator</title>
meta description = "Academic, entrepreneur, and founder of NexScholar. Publications, teaching, and news."
Same page, two write-ups. The right one is one meaningful sentence — the left is what every empty template ships with.
Figure 4.2
chat.example.com
Dr Ahmad Najmi — Researcher & Educator
Academic, entrepreneur, and founder of NexScholar. Publications, teaching, and news.
ahmadnajmi.com
A social share card is built from og:title, og:description, and og:image. Any of them missing and the card falls back to something ugly.

Hiding admin pages from search

You almost never want /admin or a login page indexed by Google. Add a <meta name="robots" content="noindex, nofollow" /> on those routes — the agent can do this in one prompt: "Add noindex to every /admin route."

Caches don't refresh instantly
If you change your og:image and the old one keeps showing up on WhatsApp or Slack, it's cached. Use the platform's link preview debugger (Facebook, LinkedIn, X all have one) to force a refresh.

Part 5 · Analytics basics

The moment your site is live, the first question is: is anyone looking at it? Analytics answers this. Don't over-engineer it on day one — a small set of numbers, checked weekly, beats a dashboard with fifty charts that nobody opens.

Avoid
Track everything
Install three tools, tag every button, ship a cookie banner on day one. Six months in, you have data you never look at and legal work you didn't need.
Do
Track three things
Pageviews per route, clicks on your top call-to-action, and form submissions. That's enough to answer "is it working?" for the first six months.

First-party vs third-party

  • First-party — you store the events in your own Lovable Cloud tables. No cookies, no banner in most jurisdictions, full control. Great for small sites.
  • Third-party — Google Analytics, Plausible, Fathom. Faster to set up, but you're sending visitor data to a third party, which may need a cookie/consent banner.
  • Rule of thumb — start first-party. Add a third-party tool later if you actually need funnels or audience segments.

What to track early

  • Pageviews — one row per visit, with route and referrer. Answers "which pages do people read?"
  • Key clicks — the Contact button, the sign-up link, the "Buy" button. Answers "does the site convert?"
  • Form submits — every completed contact form or signup. Answers "are the forms actually working in production?"
"Add a first-party pageviews table with route, referrer, timestamp, and a session id in localStorage. Log a pageview on every route change. Don't set any cookies."

Part 6 · Post-publish checklist

The site being live doesn't mean the site is done. Ten minutes after publishing, walk this checklist on the actual live URL (not the preview). It catches the small things that only break in production.

  • Every nav link works on the live URL — especially deep links, refreshed on a route (people share these).
  • Forms submit and you get the notification you expect (email, Cloud row, both).
  • Images load — big hero images sometimes work in preview and 404 in production if you referenced a path that got cleaned up.
  • Mobile check — open the live URL on your phone. Half of your visitors are on mobile; the preview device toggle is not the same as a real phone.
  • Title and share card — paste the URL into Slack or WhatsApp. If the preview looks broken, fix the og:* tags and re-publish.
  • Google can find it — search site:yourdomain.com after a few days. If nothing shows up, submit the URL in Google Search Console.
Figure 6.1
published v1published v2 ✓published v3 brokerolled back to v2rollback
Publishing keeps every version. If v3 is bad, revert the live site to v2 — the preview keeps moving so you can fix forward without breaking users.
Publishing is not the finish line
It's a savepoint. The site being live means you can now iterate with real feedback: what people click, where they get stuck, what they email you about. That loop is worth more than any pre-launch polish.

Publish cheat sheet

Six habits that make shipping feel routine instead of dramatic.

  • Preview is for you, published is for them — never send a preview URL to a client or a customer.
  • Publish in small batches — one meaningful change per publish makes rollbacks trivial.
  • Verify on the live URL in incognito. If it works there, it works everywhere.
  • Domains need three records — A @, A www, TXT _lovable. Miss one and it silently doesn't work.
  • Fix your title, description, and og:image — ten minutes of SEO buys years of decent search results.
  • Track three things, not thirty — pageviews, key clicks, form submits. Grow the dashboard only when a question demands it.
Recap — end of the beginner track
You've now gone from opening Lovable for the first time to a published site on a custom domain, with real content, working forms, sensible SEO, and enough analytics to know it's alive. The intermediate track picks up here: adding a real backend with auth, database, storage, and AI, so your site stops being a brochure and starts being a product.