Before promoting a Lovable website, verify the published pages, their search signals and the content a new visitor actually receives. Start with the final domain and a few important routes, fix confirmed problems, then repeat the checks after publishing the changes. A finished preview or a green scan badge alone does not establish that Google has indexed the site.
Lovable SEO advice needs to match your project. Current Lovable hosting uses server-side rendering for newer projects and serves pre-rendered pages to verified crawlers for older projects. An SEO scanner receiving an empty response therefore needs investigation; it is not, by itself, proof that Google receives the same thing.
The 30 checks below cover a Lovable-hosted public website, from the first release to the final verification before wider promotion. Some require that first public publish. Keep private app areas protected, and use your host's actual behavior if you have moved the project elsewhere. The examples are illustrative, not results from a tested Lovable deployment.
Start with the right Lovable project and domain
1. Identify the actual rendering stack
Ask Lovable which framework and hosting configuration the project currently uses. Project age is a clue, but an upgraded or externally hosted project needs its own answer. Record the stack alongside the public URL so later findings have context.
| Lovable-hosted project | Expected response pattern | Appropriate first check |
|---|---|---|
| TanStack Start | Server-rendered HTML for people and crawlers | Inspect the direct HTML response and Google-rendered page |
| Older React + Vite | Browser app for people; on-request pre-rendering for verified crawlers | Compare the user experience with Google's URL Inspection output |
| Exported to another host | Depends on that host and deployment | Verify the actual deployment rather than assume Lovable hosting behavior |
This distinction prevents an unnecessary rebuild or rendering-service purchase before you have identified a real failure. It does not establish that every route's data is complete.
2. Confirm the website is publicly accessible
Check the published website's access setting, separately from who can edit the project. A private development preview or an invitation-only website is not the public marketing site you want people to discover. Lovable's publishing documentation explains this distinction.
Test the intended marketing page while signed out. It should show its useful content without a workspace invitation. Keep dashboards, customer records and account areas behind their proper access controls. Removing authentication to improve an SEO score would defeat the purpose of those pages.
Workspace-branded app addresses also have different search restrictions from ordinary public website addresses. Check the current workspace configuration instead of assuming every URL ending in lovable.app has the same purpose.
3. Choose the final primary domain
For a lasting business website, decide which domain you intend to own and promote. A custom domain requires a paid Lovable plan; a default published address can still be useful for a demo. Domain ownership is a practical publishing decision, not a guaranteed ranking improvement.
In Project → Settings → Domains, confirm the chosen domain is Live, then check its primary setting. Lovable's domain documentation describes how the primary address controls other connected domains. Save the exact preferred hostname and path convention for your links, canonicals and sitemap. Do this before distributing launch links so those signals can agree from the start.
Check what a fresh request receives
4. Verify HTTPS and connected-domain redirects
Open the HTTPS address and check for certificate errors. Then inspect the connected alternative hostnames you actually use, such as the www and non-www versions. They should end at the chosen primary address without an unexpected detour.
Expect Lovable's native primary-domain redirect to use 302. Its current domain documentation explicitly says connected project domains use temporary redirects and that native 301 redirects between them are not supported. Do not label that expected behavior a broken launch or try to fix it by changing unrelated DNS records. Keep links and canonical signals consistent with the selected primary domain; Google's canonical selection remains a separate process.
A developer can examine a real GET response without impersonating a search crawler:
curl -sS -L -D response-headers.txt -o response-body.html \
-w 'Final URL: %{url_effective}\nStatus: %{http_code}\n' \
'https://example.com/pricing'
Replace the example URL. The headers file contains redirect hops as well as the final response. This is an inspection command, not a result from a site we tested.
5. Open deep routes directly
Paste an important inner URL into a fresh tab and refresh it. Do not start at the homepage and click through first. Test one page from each relevant template, such as a service page, an article and pricing.
The direct request must return the intended page, not the homepage, an authentication screen or an error. If only in-app navigation works, record the exact failing route and investigate routing or deployment before rewriting its SEO text. Google's JavaScript SEO guidance explains the importance of real URLs and meaningful response codes.
6. Test a nonexistent route
Try a path you know is absent, such as /launch-check-missing-page/. Confirm that the response and visible page communicate that it does not exist. A styled “not found” component served with 200 can still be a soft-404 problem.
For an ordinary missing page, the target is an appropriate 404 response. If a previously published page has a genuine replacement, evaluate a relevant redirect instead; do not send every invalid path to the homepage. Ask for the response evidence before declaring the issue fixed. The broader pre-launch audit walkthrough shows how to organize representative routes when your site has several templates.
Confirm crawlers can read the page
7. Compare the appropriate crawler view
On a server-rendered project, inspect the direct response for the main heading, meaningful copy and important links. On an older Lovable-hosted project, an ordinary scanner may receive the browser app shell while a verified crawler receives rendered HTML. A blank scan is a finding about that request, not a substitute for Google's view.
Use Search Console URL Inspection for a public page when you need Google's evidence. Compare the indexed information with a live test, then inspect the available rendered HTML, screenshot and resource details. Search for a distinctive sentence from the page, not merely the brand name in a script bundle.
| Observation | What to do next |
|---|---|
| Ordinary scanner is sparse; Google's live rendering contains the expected content | Investigate scanner/hosting compatibility before changing the framework |
| Google's rendered page lacks important public content | Investigate the content-loading path, resource errors and access requirements |
| Current live content is correct; indexed information is older | Record the difference and allow for Google's later processing; do not report immediate indexation |
Changing a request's user-agent string does not prove that Lovable recognizes it as a verified crawler.
8. Inspect late-loading public content
Rendering the layout is not enough if the useful facts arrive only after another action. Choose a data-backed page: for example, a fictional bakery's class description loaded from a content source. Verify that the class name, dates and booking information appear when the page loads, rather than only after opening a modal or signing in.
Lovable's hosting documentation cautions that late content can be missing from older projects' pre-rendered output. Check a recently updated item as well as an older one. If the title is current but the class details are stale or absent, investigate that data path. Do not automatically solve the wrong problem by adding another rendering service.
9. Keep rendering resources crawlable
Inspect the published robots.txt and any confirmed resource errors affecting the page. An accidental site-wide crawl block, or a block on essential JavaScript and CSS, can prevent proper processing. Correct only the rule responsible for the intended public content.
This does not mean exposing every backend endpoint. Private records and credentials remain protected. If public page content depends on data that requires a signed-in session, provide an appropriate public representation rather than granting anonymous access to sensitive data. Robots instructions govern crawling; they are not access control.
Align indexing and URL signals
10. Remove accidental noindex from public pages
Inspect both the page's robots meta tag and its response headers for noindex. An unintended directive on a public service page can exclude the very page you want people to find. A deliberate directive on a sign-in or temporary page may be correct.
Google's noindex documentation makes an important distinction: Google must be able to crawl the URL to read that instruction. Blocking a page in robots.txt is not a reliable way to make Google see its noindex tag. Decide which public URLs belong in search, then make the signals agree. Keep authentication in place for private content; noindex does not protect it from visitors.
11. Check page-specific canonicals
For each distinct public page, examine the declared canonical and its destination. A pricing page should not accidentally identify the homepage as its preferred equivalent. A canonical pointing at a development domain or a broken URL also needs investigation.
Record the requested URL, final URL and canonical together. Resolve conflicting declarations instead of adding another tag on top. Google's canonical guidance explains how redirects, canonical annotations and sitemap signals can work together. They express preferences; Google can select a different canonical.
For truly duplicate versions, choose the intended representative. For genuinely different pages, preserve their individual purpose and signals.
12. Decide how URL variants behave
Now test the variants people or scripts might create: slash versus no slash, tracking parameters, old paths and duplicate filter views. This check is about the URLs your application exposes, beyond the canonical tag on one preferred page.
For the illustrative /classes/bread-making/ page, decide whether /classes/bread-making is an alternative spelling and whether a campaign parameter changes the content at all. Use one chosen form in internal links and the sitemap. Do not create separate indexable pages solely for tracking labels.
If you rename an existing page, document its replacement and verify the deployed behavior. Lovable's connected-domain 302 policy does not establish what every application-level path does. Ask the builder to inspect the actual route rather than assume a universal redirect configuration or rewrite unrelated URLs.
Reconcile the sitemap and internal links
13. Validate the live sitemap document
Fetch the actual sitemap URL on your final domain. Confirm it returns a sitemap, not an HTML app shell, sign-in page or error disguised as XML. Check that its page addresses are absolute URLs using the intended hostname.
If you use a sitemap index, follow it to the child sitemap containing your pages. Do not assume that a file in the project means the same file is live. Lovable can create or repair a sitemap, but its existence and accuracy still need verification after publishing.
Google's sitemap guidance explains accepted formats and submission. A sitemap is a discovery hint, not a command to index its contents. Include meaningful modification dates when available; do not set every page's date to today solely to look fresh.
14. Compare it with the real published inventory
A valid sitemap can still omit an entire section or list pages that were never built. Compare its URLs with the actual public route and content inventory, including data-driven articles or product pages.
| Comparison | Example of a separate failure | Appropriate correction |
|---|---|---|
| Sitemap document | /sitemap.xml returns the homepage HTML |
Serve the intended sitemap response |
| Sitemap coverage | XML is valid, but published class pages are missing | Generate entries from the real published content set |
| Sitemap exclusions | Draft, private or removed items appear | Exclude those records and retest the generated output |
This is why document validation and inventory reconciliation are two checks. Ask Lovable to use the routes or content source, not invent a page list from a prose description of your business. Recheck after adding and removing a sample item in your normal publishing workflow.
15. Make important pages reachable through links
Start at the homepage and find a useful path to each important public page. A sitemap entry does not replace navigation and contextual links. If a bakery has a bread-making class page, the classes index should link to it, and the class page can link to booking information.
Inspect the link itself: it should expose a real destination through an HTML anchor, such as <a href="/classes/bread-making/">Bread-making class</a>. Framework navigation can still use anchors; the problem is relying solely on a click handler with no discoverable URL. Google's link guidance covers the distinction.
Record public pages absent from both the crawl and navigation. They may be orphaned; a crawl that never reached them cannot certify their metadata or content.
Give every public page a useful job
16. Match the page to one reader task
Write down what the visitor needs from each important page before asking Lovable to expand it. A homepage introduces the business; a class page helps someone decide whether to attend; an article might explain a baking technique. Those jobs need different information.
For a fictional bakery, a useful class-page brief would be:
Help a beginner decide whether this bread-making class fits them. Explain the actual skill level, location, duration, available dates, what is included and how to book. Use only the supplied class details. Link to booking and answer the real restrictions. Do not invent places, availability or reviews.
That brief defines what to verify at launch. It does not prescribe a minimum word count, a compulsory blog or ten extra pages. Publish a separate page when it has a useful, distinct job; consolidate copies that serve the same task.
17. Replace unsupported generated claims
Read the finished copy against the real business facts. Check testimonials, qualifications, prices, locations, integrations and availability. An AI-generated statement can sound convincing while describing something the business never offered.
For example, “Award-winning classes trusted by 10,000 bakers” needs genuine evidence. If the only verified facts are a small-group format and an introductory lesson, describe those instead. A specific truthful offer gives a visitor more to assess than an invented authority signal.
Add real supporting detail where it matters: the actual booking policy, an authentic class photograph or a demonstration you can substantiate. Remove generic paragraphs that repeat the hero without answering another question. The acceptance test is whether someone can make the intended decision, not whether the page reaches a target length.
18. Read its heading and semantic structure
Review the page as an outline. Use a clear main heading that identifies the subject, then section headings that describe useful information. Keep the hierarchy understandable rather than choosing heading levels to achieve a font size.
Ask Lovable to use appropriate landmarks such as main, nav and article where they fit the actual content. Check that a heading still has explanatory text beneath it and that the important answer is not only an image or animation. A practical launch convention is one clear main H1; do not present that convention as a magic ranking rule.
The fictional class page might have sections for the lesson, suitability, logistics and booking. It does not need a repeated FAQ if those sections already answer the questions clearly.
Review titles, descriptions and social cards
19. Review generated page titles
Lovable's current publishing workflow generates page-specific titles and descriptions while building. That is a starting point to review, not a reason to assume every project needs a new metadata library. Use the mechanism supported by the actual project.
Open the page selector above the preview and inspect each important page's Search card. Ask Lovable to edit a specific page if its title is generic, inaccurate or duplicated across distinct routes. Then verify the published HTML after the next publish; the preview can contain changes that are not live yet.
Lead with the page's distinguishing topic and keep the wording concise. Roughly 50–60 characters can be a useful editing target, but Google sets no fixed title-length limit. It can also generate a different title link.
20. Check descriptions against the body
A description should explain what this page actually provides. For the fictional bakery, these pages should not inherit the same introduction:
| Page | Appropriate description focus |
|---|---|
| Classes index | Available class types and how to compare them |
| Bread-making class | Level, format and actual booking details for that lesson |
| Contact | How to reach the bakery and what enquiries it accepts |
Do not insert a price, free offer or guarantee absent from the page. Aim for a clear, specific sentence, often around 140–160 characters when that fits naturally. Google's snippet documentation explains that descriptions are one possible source of snippets, not a promise of the exact text displayed.
If several routes still share a fallback, diagnose the shared template rather than rewriting unrelated content. Screpy's duplicate title and description guide covers that repair in more detail.
21. Check route-specific social previews
In Lovable's page selector, review the Social card as well as Search. Confirm that the image, title and description belong to the selected route. A pricing link should not accidentally advertise a different product or expose an unsuitable development screenshot.
Ask for specific Open Graph values and an appropriate image when the generated result is wrong. After publishing, check the actual public link with the platform where you plan to share it; cached previews may need refreshing there. The editor's card helps review your configuration, but it does not prove an external platform has fetched the new version. Social presentation also does not replace indexability checks.
Check images and the favicon
22. Use context-specific image alternatives
Review images according to what they contribute, rather than filling every alt attribute with keywords. The W3C image decision tree distinguishes informative, functional and decorative images.
For the fictional class page:
- An instructional photograph might use
alt="Hands shaping a round bread dough before proofing"if that accurately describes the image. - A purely decorative background can use an empty alternative,
alt="", or an appropriate decorative implementation. - An image that is the only content of a booking link needs an accessible name explaining the destination or action.
Complex diagrams need their essential information in nearby text, too. Check that real class details remain readable even if an image does not load. Do not invent a scene in alt text or repeat “best bread-making class” on every photograph.
23. Deliver appropriately sized images
Inspect the actual images used on the published page, especially a large hero or gallery. Serve dimensions appropriate to the displayed area and device, compress without losing useful detail, and use an efficient supported format. Google's image guidance covers responsive images, quality and speed.
Ask Lovable to review oversized uploads and responsive image behavior rather than apply a universal tiny file limit. A detailed teaching photograph and a small card thumbnail have different needs. Preserve the important subject when cropping.
Record the image URL and the oversized asset you changed. Then recheck the live response; replacing a local file while the published page still loads the old one is not a completed optimization. The full page's loading behavior is reviewed separately in check 27.
24. Replace and verify the favicon
Confirm that the site icon represents your business rather than an old project or default. Lovable generates a favicon while building, and you can request a replacement in chat. Republish, check the icon URL and inspect the Search preview card.
Follow Google's current favicon guidance: a square image at least 8×8 pixels, with a larger image than 48×48 recommended for different surfaces. Use a stable, crawlable URL. Do not repeat older advice that only multiples of 48 are accepted.
A correct icon in the live HTML does not guarantee immediate replacement in Google's results. Separate a working published icon from browser or search caches, and allow for recrawling rather than changing the URL repeatedly.
Validate markup and the mobile experience
25. Validate only applicable structured data
Inspect the JSON-LD that actually appears on the public page. Choose a type appropriate to its content and verify the required properties against Google's documentation for that search feature. A published article, a genuine product offer and a utility screen do not all need the same markup.
The general structured data guidelines require truthful, relevant information. Do not generate reviews, ratings, prices or author credentials merely to fill a schema template. Validate eligible markup with Google's Rich Results Test, while recognizing that a successful test does not guarantee a rich result.
If a page does not need a supported rich-result type, record that decision. Adding every available schema type is not a launch requirement. Google retired FAQ rich results in May 2026, so do not add FAQ markup expecting those dropdowns.
26. Use the real mobile journey
Use Lovable's device controls while building, then check the published page on an actual phone when possible. Read the copy, open navigation and follow the main action. Look for horizontal scrolling, obscured controls, unreadable text and overlays that prevent someone from completing the task.
On the fictional bakery page, can a visitor identify the class date and get to the intended booking step? If you conduct a form test, use a controlled test that does not create an unwanted real booking or charge. Record the actual result rather than assuming a success message means the submission arrived.
A viewport preview is useful preparation; it is not a full accessibility review or proof that every device behaves identically. Give Lovable a specific URL and observed failure to repair.
27. Measure loading, responsiveness and stability
Run PageSpeed Insights on the published homepage and an important inner page. Lovable's SEO review no longer runs Lighthouse audits, so a passing SEO scan does not supply this evidence.
The current Core Web Vitals targets are:
| Metric | Experience measured | Good threshold |
|---|---|---|
| Largest Contentful Paint (LCP) | Main content loading | 2.5 seconds or less |
| Interaction to Next Paint (INP) | Responsiveness to interactions | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | Visual stability | 0.1 or less |
These thresholds apply to the 75th percentile of real page loads, assessed separately for mobile and desktop. A new site may not have enough field data. Record that absence; a lab run helps diagnose performance but cannot establish a real-user INP pass.
Work on the measured cause: a delayed main image, expensive interaction code or shifting content space, for example. Recheck the same page and conditions after publishing. Passing performance thresholds is useful for visitors, not a promise of a top ranking.
Verify the published release
28. Verify the final Search Console property
Make sure Search Console covers the domain you actually plan to promote. If you changed from a temporary address to a custom domain, verify the new address and submit its live sitemap. Do not rely on a property for a different hostname.
Lovable's current workflow can connect Search Console and complete verification and sitemap submission through chat when the connection and workspace permissions allow it. Follow the requested setup, publish any verification changes, then confirm the result. If the connection is unavailable, record what remains unfinished instead of assuming it happened.
Inspect the homepage and a representative inner page. Distinguish Google's indexed information from a fresh live test. A successful access test, verified property or accepted sitemap does not mean all pages are indexed. Request indexing for ready priority pages when appropriate, then monitor the actual outcome rather than promise a date.
29. Rescan after Lovable applies fixes
Open More → Analytics → SEO & AI and run the review. Address the relevant findings, publish changes when required, then use Scan again. Lovable's review documentation distinguishes a fix being applied from its verification by another scan. Publishing alone does not automatically rerun the SEO review.
Check ignored findings as well as active ones. An ignored problem is not repaired, and an earlier passing scan may predate your last edit. Also distinguish the Publish dialog's security Quick scan from the SEO review; they answer different questions.
Prioritize a public page blocked from crawlers or returning the wrong content over cosmetic warnings. Keep a note explaining an intentional exclusion, rather than removing it merely to make the report green.
30. Save and repeat a release evidence record
Keep one record that connects the intended page, the observation and the post-fix check. This small CSV is a reusable starting point; the rows deliberately contain no invented pass results:
url,intended_indexing,check,observation,decision,retested_at
https://example.com/,index,public_content,PENDING,PENDING,
https://example.com/pricing,index,title_and_canonical,PENDING,PENDING,
https://example.com/classes/bread-making/,index,rendered_class_details,PENDING,PENDING,
https://example.com/account/,exclude,access_and_indexing_controls,PENDING,PENDING,
Replace the example URLs and adapt the indexing intent to your site. Add an owner and evidence link when several people are involved. Stop promoting an important route when a confirmed blocker prevents its intended use; a minor warning or Google's pending indexing decision is a different state.
A Screpy Website Audit can help inventory returned titles, descriptions, links, images and canonical signals across crawled pages. Screpy publishes this guide. On older Lovable hosting, interpret that crawl alongside the verified-crawler distinction in check 7; no third-party audit should be presented as Google's own indexing verdict.
Give Lovable a bounded verification request rather than “make the SEO perfect”:
Review only these public URLs: [paste your list].
Confirm the current stack, final domain and intended indexing for each.
For each confirmed issue, explain the smallest repair and affected files.
Preserve private access controls and unrelated working pages.
After publishing, report the actual final response, title, canonical,
indexing directives and expected content for each changed URL.
Separate checks you performed from checks you could not perform.
Rerun the SEO review and record what still awaits verification.
Do not claim Google indexed or ranked a page without Google's evidence.
Repeat the relevant checks when a later AI edit changes routes, templates, metadata or content loading. This guide was researched against official documentation on October 16, 2026; it is a launch review framework, not a hands-on deployment case study or a guarantee of search traffic.