The SEO prompt to use before launching a Lovable website

The prompt to paste into Lovable

Replace the bracketed placeholder with your intended live domain, then paste the whole prompt into Lovable’s chat. It deliberately asks for a report first and changes second, so you can see what Lovable believes before it edits anything.

You are reviewing this Lovable project for search-readiness before it goes live. Work in two phases. Do not change any file in Phase 1.

PHASE 1 - REPORT ONLY
1. State which stack this project uses (for example TanStack Start with server-side rendering, or React with Vite rendering in the browser) and how you know. Name the file or setting that shows it.
2. List every public route that should be found through search. Treat dashboards, account screens, login, thank-you pages and admin routes as private.
3. For each public route, report: the route path, the page title, the meta description, the canonical URL, the single H1, and whether that metadata is set per route or shared across the whole site.
4. Report how robots.txt and the XML sitemap are produced. Say whether each one currently exists, where it lives and which URLs it lists.
5. Report any place where the project contains the temporary preview address, a localhost address or a placeholder domain. The final domain is [https://www.example.com].
6. Check navigation and footer links. List any link that points to #, to a route that does not exist or to a modal instead of a page.
7. List images that lack alt text, and any single image over roughly 500 KB.
8. State whether an unknown route returns a real 404 status or shows the homepage with a message. If you cannot determine this from the code, say so rather than guessing.
9. For every finding, label it Confirmed from the code, Not confirmed, or Needs checking on the published site.

Present the findings as a table, ordered by likely impact on search visibility. Then stop and wait for my approval.

PHASE 2 - ONLY AFTER I APPROVE
Make the smallest changes needed to fix the approved findings. Use the framework's standard per-route metadata mechanism, not a script that edits the document head after load. Use UK English in any copy you write. Do not invent claims, testimonials or statistics. Do not change the visual design. Afterwards, list every file you changed and exactly what changed in each.

The prompt is plain text on this page, so you can select it directly or read it before deciding whether it suits your project.

When to use it

Use it once the pages and copy are broadly finished and before you connect the final domain. It is also useful after a large redesign, because generated changes can quietly replace per-page titles with a shared one.

Start with Lovable’s own SEO and AI search audit, which can inspect a published site and connect to Google Search Console. Then use this prompt when you want a more explicit, evidence-led report from the project before approving code changes.

It is a poor fit for a project that is still changing shape every day. Settle the list of public pages first, otherwise the report will be out of date as soon as you read it. If you have not yet decided which pages should exist, work through the site-structure prompt first.

What the prompt checks

Each numbered step in Phase 1 maps to a failure we commonly see in generated websites:

• Stack and rendering. Lovable projects can use different frameworks and rendering setups depending on when and how they were created. Asking Lovable to identify the project’s actual stack prevents the review from relying on a platform-wide assumption.
• Public versus private routes. Search engines should be pointed at pages meant for visitors, not at account screens.
• Per-route metadata. One title and description reused everywhere is the most common finding.
• Domain references. Canonical tags, sharing tags and sitemap entries that still use the preview address.
• Broken links and unreachable pages. Buttons that go nowhere and content that only appears in a pop-up.
• Error handling. Whether missing pages return a real 404 status.

The “Confirmed, Not confirmed, Needs checking” labels matter. They stop the report presenting guesses as facts.

What Lovable may still get wrong

Lovable can now audit a published site and connect to Google Search Console, but its chat response is still not independent proof of what Google receives or indexes. Treat every answer as a claim to verify on the live domain.

• Rendering on older projects. Lovable states that pre-rendered pages on React and Vite apps go to verified crawlers only, and that third-party SEO scanners and other unverified agents see the single-page app. A scanner that reports an empty page is not always showing what Google sees, and a clean scanner result does not prove the opposite. Inspect the page in Google Search Console instead.
• Confident but unchecked answers. The model may say a canonical is correct without opening the published page.
• Hidden dependencies. It may not notice a redirect, header or domain setting configured outside the code.
• Copy quality. Rewritten titles can become generic. Read each one.
• No ranking guarantee. Lovable’s own documentation is clear that ranking depends on content quality, search intent, backlinks, competition and performance.

After any change, republish and test the live address. The Lovable pre-launch checklist covers the checks to make on the published site, and this guide to indexing problems explains what to do if pages still do not appear.

A worked example

This is an illustrative scenario, not a client result. Imagine a three-service consultancy site built in Lovable, with the intended domain https://www.northfieldconsulting.example.

Lovable’s Phase 1 report might say the project uses TanStack Start, lists six public routes and finds that all six share the title “Northfield”. It might also find that the sitemap contains the preview address and that the footer’s “Careers” link points to #.

You would reply: “Approved: fix the titles and descriptions, the sitemap domain and the footer link. Leave the careers page out of the sitemap until it exists.” Lovable then makes only those changes and lists the files it touched.

Finally, you would republish, open each page’s source on the live domain, and confirm each title, canonical and sitemap entry. Only then would you submit the sitemap in Search Console. Nothing in this process guarantees indexing. It removes avoidable technical obstacles.

Next step: check the live site

A prompt can find problems in the code, but it cannot confirm how Google crawls the published site. That needs the live pages tested for crawlability and indexability, and an experienced person to interpret the results. Our Lovable SEO service covers this directly.

Book a site review and we will check the live pages for you, or send us a message if you would like to describe the problem first. You can also browse the rest of the resources hub.