---
title: "Per-page titles and meta descriptions in Lovable | Lovable Field Guide"
description: "Every route of a client-rendered app ships the same title. How to set Lovable meta tags per route on TanStack Start and Vite, and where the built-in checks stop."
lang: en
json-ld: |
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebSite",
"@id": "https://prerenderlovable.com/#website",
"url": "https://prerenderlovable.com",
"name": "The Lovable Field Guide",
"description": "A working journal on Lovable SEO: getting apps built with Lovable indexed, ranked and cited, plus the migration and integration work that comes with it.",
"publisher": {
"@id": "https://prerenderlovable.com/#organization"
},
"inLanguage": "en"
},
{
"@type": "Organization",
"@id": "https://prerenderlovable.com/#organization",
"name": "The Lovable Field Guide",
"url": "https://prerenderlovable.com"
},
{
"@type": "BlogPosting",
"@id": "https://prerenderlovable.com/blog/lovable-meta-tags-and-titles#article",
"headline": "Per-page titles and meta descriptions in Lovable",
"description": "Every route of a client-rendered app ships the same title. How to set Lovable meta tags per route on TanStack Start and Vite, and where the built-in checks stop.",
"datePublished": "2026-09-11T00:00:00.000Z",
"dateModified": "2026-09-11T00:00:00.000Z",
"inLanguage": "en",
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://prerenderlovable.com/blog/lovable-meta-tags-and-titles"
},
"author": {
"@type": "Organization",
"name": "The Lovable Field Guide",
"url": "https://prerenderlovable.com"
},
"publisher": {
"@id": "https://prerenderlovable.com/#organization"
},
"keywords": "lovable meta tags, lovable page title, lovable meta description, duplicate titles lovable, lovable per-route metadata",
"articleSection": "SEO"
},
{
"@type": "BreadcrumbList",
"@id": "https://prerenderlovable.com/blog/lovable-meta-tags-and-titles#breadcrumbs",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://prerenderlovable.com/"
},
{
"@type": "ListItem",
"position": 2,
"name": "SEO",
"item": "https://prerenderlovable.com/seo"
},
{
"@type": "ListItem",
"position": 3,
"name": "Per-page titles and meta descriptions in Lovable",
"item": "https://prerenderlovable.com/blog/lovable-meta-tags-and-titles"
}
]
},
{
"@type": "FAQPage",
"@id": "https://prerenderlovable.com/blog/lovable-meta-tags-and-titles#faq",
"mainEntity": [
{
"@type": "Question",
"name": "Why does every page of my Lovable site have the same title?",
"acceptedAnswer": {
"@type": "Answer",
"text": "On a client-rendered React + Vite build, the only title in the HTTP response is the one baked into index.html. Libraries like react-helmet change the title by mutating document.head after the page loads, which happens long after the response body has closed. Anything that reads the raw HTML (most crawlers and every link unfurler) sees the baked-in title instead."
}
},
{
"@type": "Question",
"name": "Does Google see the titles my React app sets with JavaScript?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Usually yes. Googlebot renders pages with an evergreen Chromium, and measurements by Vercel and MERJ put the median render delay at about 10 seconds. The problem is everything else: link unfurlers, most AI crawlers (Vercel and MERJ measured GPTBot, ClaudeBot and PerplexityBot running no JavaScript in December 2024) and Bing, which testing by Screaming Frog found tends to use the title from the initial HTML even when it renders the body."
}
},
{
"@type": "Question",
"name": "How long should a title tag and meta description be?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Google truncates search snippets by pixel width and has never published a limit. As a working budget, keep titles near 50 to 60 characters and descriptions near 150 to 160, put the distinguishing words first, and treat anything past that as likely to be cut."
}
},
{
"@type": "Question",
"name": "Does Lovable set per-page metadata automatically?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Lovable's documentation says metadata is auto-generated and that its SEO review checks for duplicate titles, placeholder text, weak descriptions and wrong canonicals, with og:title, og:description and og:image settable per route. It grades findings rather than guaranteeing them, so verify the published HTML yourself."
}
},
{
"@type": "Question",
"name": "Does upgrading to TanStack Start fix duplicate titles by itself?",
"acceptedAnswer": {
"@type": "Answer",
"text": "It fixes the static case. Metadata you type into a route file is resolved on the server and lands in the HTML response. Titles built from fetched data are separate: server rendering doesn't run effects, so a title assembled after hydration is still absent from the response body. Move that data into a route loader or a server function."
}
},
{
"@type": "Question",
"name": "Do I have to republish after editing my metadata in Lovable?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. Publishing is snapshot-based, so edits made after a publish do not reach the live site until you publish again. Always run your checks against the live domain."
}
}
]
}
]
}
---
[Skip to content](#main)
[Lovable Field Guide ](/)
[SEO](/seo)[Migration](/migration)[Integrations](/integrations)[All posts](/blog)
[Start here](/blog/lovable-seo)
[SEO](/seo)[Migration](/migration)[Integrations](/integrations)[All posts](/blog)
1. [Home](/)
2. / [SEO](/seo)
3. / Per-page titles and meta descriptions in Lovable
# Per-page titles and meta descriptions in Lovable
Every route of a client-rendered app ships the same title. How to set Lovable meta tags per route on TanStack Start and Vite, and where the built-in checks stop.
Published September 11, 2026 · 12 min read
A client-rendered single-page app has exactly one `` in its HTTP response | the one baked into `index.html`, and it serves that same title, description and canonical for every route. Whether your Lovable project has this problem depends entirely on which stack it is on, so establish that first, then fix the metadata at the layer crawlers actually read.
## First: which stack is your project on?[#](#first-which-stack-is-your-project-on)
On 13 May 2026 Lovable changed its default stack from React + Vite to TanStack Start with SSR on Cloudflare Workers. Existing projects were not migrated; Lovable’s blog states that every project already built continues to run exactly as before. So there are two populations, and the advice for them differs.
Check `package.json` rather than guessing:
```
grep -E '"(@tanstack/react-start|@tanstack/react-router|react-router-dom)"' package.json
```
- `@tanstack/react-start` present → new stack. The server renders your route components, so every request gets real markup, crawlers included. That is markup, not necessarily your data; see below.
- only `react-router-dom` → old stack. Client-rendered, with Lovable applying on-request pre-rendering on deployed public URLs, served only to _verified_ crawlers.
Do not read that first bullet as “metadata is handled”. Server rendering renders your components, and it only includes data that a route loader fetched. React’s `useEffect` documentation is blunt about it: “Effects only run on the client. They don’t run during server rendering”, and TanStack Query’s SSR guide says the same of queries you haven’t prefetched: they “wont be server rendered, instead they will be fetched on the client after the application is interactive.” A page can be 100% server-rendered and still ship `<title>Loading…`, because the title was assembled from data the server never fetched. Lovable’s own blog wording is conditioned on exactly this: the server “runs the React tree, **executes the loaders**, and streams the result.” Loaders. Where the fetch lives decides what reaches the ``, and the dynamic-routes section below is where that bites.
The second bullet matters for debugging, too. On an old-stack, Lovable-hosted project, Screaming Frog or Ahrefs will report your pages as empty or title-less. Lovable’s docs say verified crawlers get pre-rendered HTML instead, which can’t be verified from outside. If you want the wider picture of what changes between the two stacks, start with the [Lovable SEO overview](/blog/lovable-seo).
Lovable's own docs disagree with each other
As of September 2026 the deployment/hosting page still describes projects as “standard Vite + React”, and `llms.txt` says the same. The SEO, hosting and TanStack Start pages say new apps are SSR. Check `package.json`; it’s the only reliable source.
## Why one static title ends up on every route[#](#why-one-static-title-ends-up-on-every-route)
The mechanism is worth stating precisely, because the popular explanation (“Google can’t read React”) is wrong and has been for years.
1. The server returns `index.html`. Its `` contains whatever the build baked in: identical for every URL.
2. A crawler reads that byte stream, extracts `title`, `og:*` and `twitter:*`, and is done.
3. Only later, in a real browser, does the bundle download, React mount, and `react-helmet` imperatively mutate `document.head`.
A crawler that never executes step 3 cannot observe it. The library is not broken: react-helmet’s README documents calling `Helmet.renderStatic()` after `renderToString` on the server. `curl` of create-react-app.dev returns `` in the raw HTML, because Docusaurus renders helmet’s output at build time. Same library, opposite result, purely because the output landed in the response body.
Swapping to `react-helmet-async` changes nothing about this. It is the same client-side mutation with a different concurrency story.
## What identical titles actually cost you[#](#what-identical-titles-actually-cost-you)
Be honest about who is affected, because the blast radius is smaller than most posts claim and differently shaped.
Consumer
Sees JS-set titles?
Consequence of one static title
Googlebot
Yes: renders with evergreen Chromium; median render delay ~10s (p75 26s)
Mostly unaffected, but thin/duplicate initial HTML feeds “Crawled – currently not indexed” verdicts
Bingbot
Inconsistently. Bing says processing JS “at scale” is difficult
Screaming Frog’s testing found Bing tends to use the _initial-HTML_ title even when it renders the body, so every page is titled identically in Bing
Link unfurlers (Slack, Meta, LinkedIn, WhatsApp)
No: Slack’s own docs describe fetching a byte range, not rendering; Meta’s 1 MB fetch cutoff and LinkedIn’s tag requirements imply the same, though neither states it
Every shared URL previews as the same page. Covered in [why Lovable link previews break](/blog/lovable-link-previews-broken)
AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Bytespider)
No, per Vercel/MERJ measurement (Dec 2024)
Your page is one undifferentiated blob of site-wide boilerplate
Applebot
Yes: Apple’s docs say it “may render the content of your website within a browser”
Unaffected
The Bing detail is the sharpest and least known: a SPA can rank in Bing on rendered body content while every result carries the same title text. You will not diagnose that in Google Search Console, which offers no duplicate-title list: only indirect signals like “[Crawled – currently not indexed](https://encited.com/blog/fix-discovered-crawled-currently-not-indexed-google-search-console)”. Duplicate titles surface in third-party crawls, in Lovable’s own SEO review, and in Bing Webmaster Tools.
Gotcha
Bot-challenge pages are their own metadata failure. A curl with a Facebook user agent against lovable.dev in September 2026 returned `Just a moment...`: Cloudflare’s interstitial. If your WAF challenges unfurlers, every shared link previews as “Just a moment…”, no matter how correct your tags are. The [OG image previewer](https://encited.com/free-tools/og-image-previewer) shows what a preview will look like.
## Verify before you fix[#](#verify-before-you-fix)
Run this against the live domain. It prints exactly what a non-rendering client receives.
```
for route in / /pricing /blog/hello-world; do
echo "=== $route ==="
curl -sL -A 'facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)' \
"https://yourapp.com$route" \
| grep -oE '[^<]*|]*(description|og:|twitter:)[^>]*>|]*canonical[^>]*>'
done
```
If the three blocks are identical, you have the problem.
One caveat before you act on the output. Curling a Lovable-hosted Vite project from your laptop returns the SPA shell whatever user agent you send, so it tells you nothing about what Google or Slack received. Lovable’s docs say verified crawlers get pre-rendered HTML, and that can’t be verified from outside. For that stack, confirm with Search Console’s URL Inspection (“View crawled page”) and with each platform’s own debugger for unfurls. On the TanStack stack, and on anything you host yourself, curl is telling you the truth.
## Setting titles per route on TanStack Start[#](#setting-titles-per-route-on-tanstack-start)
TanStack Start resolves route metadata on the server and writes it into the HTML response. For static values (the strings you type into the route file) that closes the rendering gap completely. Values built from fetched data are a different problem, and the next section is about them. Each route passes a `head` function in its route options; the root document renders the collected tags.
```
// src/routes/pricing.tsx
import { createFileRoute } from '@tanstack/react-router'
export const Route = createFileRoute('/pricing')({
head: () => ({
meta: [
{ title: 'Pricing | Acme' },
{ name: 'description', content: 'Per-seat pricing. No setup fees, no minimum.' },
{ property: 'og:type', content: 'website' },
{ property: 'og:url', content: 'https://acme.com/pricing' },
{ property: 'og:title', content: 'Pricing | Acme' },
{ property: 'og:description', content: 'Per-seat pricing. No setup fees, no minimum.' },
{ property: 'og:image', content: 'https://acme.com/og/pricing.png' },
{ name: 'twitter:card', content: 'summary_large_image' },
],
links: [{ rel: 'canonical', href: 'https://acme.com/pricing' }],
}),
component: Pricing,
})
```
Two dependencies to check. First, the root route must render the head-output component (`HeadContent` in current TanStack Start) inside the document’s ``, or none of this reaches the response. Second, TanStack Start was still labeled a Release Candidate on tanstack.com when this was written, and head-related export names moved during that period: confirm against the version in your `package.json` before assuming a snippet compiles.
Put site-wide defaults (`og:site_name`, the fallback `og:image`, `twitter:card`) on the root route and override only what differs per route. Keep the per-route list short; duplication across twenty route files is how descriptions go stale.
### Dynamic routes need the data on the server[#](#dynamic-routes-need-the-data-on-the-server)
This is the gap SSR does not close for you. The server renders the component tree and serializes whatever the server itself fetched; effects and un-prefetched queries are not part of that. TanStack Start’s own Query guide states the condition plainly: “The route awaits the query for content that must appear in the initial HTML.” Await it in the route, or it isn’t in the HTML. So if a blog post’s title is fetched by the component after hydration, the metadata in the response body is whatever your loading branch renders: exactly the failure you just migrated away from, now running on a server.
```
// src/routes/blog.$slug.tsx
import { createFileRoute } from '@tanstack/react-router'
import { getPost } from '../server/posts' // a createServerFn, runs server-side
export const Route = createFileRoute('/blog/$slug')({
loader: ({ params }) => getPost({ data: params.slug }),
head: ({ loaderData }) => ({
meta: [
{ title: `${loaderData.title} | Acme` },
{ name: 'description', content: loaderData.excerpt },
{ property: 'og:title', content: loaderData.title },
{ property: 'og:description', content: loaderData.excerpt },
{ property: 'og:image', content: loaderData.ogImage },
],
links: [{ rel: 'canonical', href: `https://acme.com/blog/${loaderData.slug}` }],
}),
component: Post,
})
```
The rule: anything that feeds a meta tag has to come from a route loader or a server function, never from a `useEffect` or an un-prefetched `useQuery`. “SSR is on” and “my title is in the HTML” are independent facts, and only the second one is worth anything to a crawler.
Test it against a page with dynamically loaded content (CMS posts, product pages, directory listings: anything that isn’t written into the page’s source code): never the homepage, which is usually static and will pass no matter what your blog pages do:
```
curl -s -A 'Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)' \
https://yourdomain.com/blog/hello-world > /tmp/page.html
grep -qiF 'a phrase that exists only in that post' /tmp/page.html \
&& echo 'server-rendered' || echo 'client-fetched: crawlers never see it'
# Then look at where it landed: this is the command caveat 2 refers to:
grep -oi '.\{120\}a phrase that exists only in that post.\{120\}' /tmp/page.html
```
Three things that make this test lie if you skip them:
1. **The search phrase must be one contiguous text run.** Markup splits phrases across elements, so `
Hello World
` will never match “Hello World”. Pick a phrase you know sits inside a single text node.
2. **Check where the string landed.** React’s streaming SSR can deliver resolved content inside a `