Discovery
Can crawlers reach every priority route through normal HTML links and the correct sitemap?
Lovable SEO
Lovable SEO: Diagnose What Is Actually Blocking Search Visibility
Lovable sites can rank. Some need rendering work; others need better discovery, unique route metadata, stronger content or more authority. We test before prescribing.
Five separate questions—not one “SEO problem”
Rendering
What useful content and links exist in the initial HTML, and what appears only after JavaScript runs?
Indexation
Do status codes, robots directives and canonicals consistently describe the intended URL?
Content and authority
Does the page uniquely satisfy a real query, and does the wider web provide reasons to trust it?
Raw HTML versus rendered output
| Raw response test | Rendered-page test |
|---|---|
| Check status, title, description, canonical, H1, primary copy and crawlable anchors returned by the server. | Check the final DOM, client-side errors, injected metadata, interactive content and links after scripts execute. |
Google can render JavaScript, but crawl, render and index are separate phases. A mismatch is evidence to investigate—not automatic proof that the site is invisible.
Rendering decision table
| Approach | Best fit | Main trade-off |
|---|---|---|
| Static generation (SSG) | Stable marketing routes known at build time | Requires a rebuild when content changes |
| Server-side rendering (SSR) | Dynamic routes that need reliable request-time HTML | More server complexity and runtime cost |
| Build-time prerendering | A finite SPA route set that can be rendered during deployment | Must keep the route list and build output current |
| Dynamic rendering | Legacy constraints where crawler-targeted HTML is a temporary workaround | Google calls this a workaround; parity and maintenance must be monitored |
| Acceptable CSR | Implementations whose important content, links and metadata are reliably processed and validated | Rendering delay and non-Google crawler differences still require testing |
When prerendering is—and is not—necessary
It may help when
The raw response is an app shell, priority content appears only after JavaScript, and the chosen deployment path cannot produce equivalent HTML another way.
It is not the default answer when
The server already returns useful HTML, the real issue is discovery or content quality, or SSG/SSR is practical and more maintainable.
Sources: Lovable SEO and AI-search documentation, Google JavaScript SEO basics, and Google dynamic rendering guidance.
What we check on a Lovable site
Unique route signals
Titles, descriptions, one clear H1 and self-consistent canonical URLs for every target route.
Discovery paths
XML sitemap inclusion, crawlable navigation and contextual links that communicate importance.
Production behavior
Custom-domain redirects, HTTP status codes, raw/rendered parity and repeatable availability.
Search evidence
Search Console inspection and indexing exports when available, plus content-to-query mapping.
DIY or specialist?
Fix obvious items yourself when the site is small and the cause is clear. Consider specialist help when only the homepage is indexed, routes are missing from raw output, canonicalization is inconsistent, or the remediation requires architecture and deployment decisions.
Related Lovable implementation guides
Prerendering for Lovable sites explains one rendering path. Schema markup for Lovable sites covers accurate structured data. Also see why AI-built websites do not rank and the platform comparison.
Start with evidence
We will review the public production site and identify up to three likely blockers. A complete audit and implementation are separate services.
Check my Lovable site