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.
- 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.
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.
- 1Review
Click through the preview one last time. Home, then every nav link, then a form submit.
- 2Publish
Top-right Publish button. First publish gives you a URL you can rename to something clean.
- 3Verify live
Open the yourname.lovable.app URL in an incognito window. If it works there, it works for everyone.
- 4Share
Send the published URL — never the preview URL — to the people you want to see it.
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.
The three-record recipe
- A record on @ — points the bare domain (
yourdomain.com) at185.158.133.1. - A record on www — same IP, so
www.yourdomain.comresolves too. This one is easy to forget, and thenwwwvisitors get a "site not found" error. - TXT record on _lovable — the verification token Lovable shows in the Connect Domain dialog. Copy it exactly.
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.
<title>Lovable App</title>meta description = "Lovable Generated Project"No og:image. Search results are grey; shares are blank.
<title>Dr Ahmad Najmi — Researcher & Educator</title>meta description = "Academic, entrepreneur, and founder of NexScholar. Publications, teaching, and news."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."
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.
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.comafter a few days. If nothing shows up, submit the URL in Google Search Console.
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.
Sign up with my invite link and Lovable will drop 10 bonus credits into your account — enough to try everything in this course.
Claim 10 credits