Troubleshooting · checked 16 October 2026

Your Lovable page is not indexed: follow the Search Console status

Start with one exact published URL and its reported reason. A working browser page, a successful scan and an indexed page are three different observations. This decision path helps you choose a next check without guessing at a ranking problem.

First, separate the saved report from a live test

Inspect the intended custom-domain URL in your verified Search Console property. Record the status, crawl date and selected canonical. The initial result describes Google's stored information; a live test fetches the current page. A successful live test does not establish indexing or predict Google's canonical choice. URL Inspection documentation.

If your last publish is newer than the reported crawl, keep both timestamps. That difference is a reason to compare versions, not evidence that the repair failed.

Fetch failure: can the published page be reached?

What it proves: that fetch attempt failed. It does not tell you that the page needs longer text or a different title.

Next check: expand Page fetch in URL Inspection. Distinguish DNS/TLS failure, server error, robots access and authentication. Check the same public route while signed out, then compare hosting logs for the reported time. Repair the observed cause and retest; do not disable access controls on private pages. A transient failure can differ from the next live test. Google's fetch diagnostics.

Noindex: should this URL be public in search?

What it proves: Google encountered an indexing exclusion. For account pages or browser history, that may be correct.

Next check: for an intended public article, inspect the published robots meta tag and X-Robots-Tag response header. Remove only the unintended exclusion, publish, and inspect again. Google must be allowed to crawl the URL to see a changed noindex directive; a robots.txt block is not a substitute. Noindex is not privacy protection—sensitive content still needs authentication. Google's noindex guidance.

Alternate page with proper canonical tag

What it proves: Google treats this URL as an alternate and has indexed its canonical. If that is your intended preferred page, the alternate need not be indexed separately. Indexing status definitions.

Next check: inspect the selected canonical. Compare it with your intended custom-domain URL. If they differ, check whether old lovable.app URLs, redirects, internal links or sitemap entries send conflicting signals. Align signals only after deciding which equivalent page should be preferred; do not point unrelated pages at the homepage. A canonical declaration is a signal, not a command. Google's canonical guidance.

Discovered – currently not indexed

What it proves: Google knows the URL but has not crawled it yet. It does not establish a rendering failure or a content-quality diagnosis. Status definition.

Next check: confirm this exact page is published, reachable through a normal internal link and listed in the intended sitemap. Check server availability if crawl access is suspect. Record these observations before making content changes. Avoid publishing near-identical pages just to create more URLs to submit.

Crawled – currently not indexed

What it proves: Google fetched the page but has not indexed it. It may or may not be indexed later; Google says resubmitting this URL for crawling is unnecessary. The label does not identify a single fix. Status definition.

Next check: examine the available crawled content and compare it with the page you meant to publish. Then review whether this page serves a distinct reader need or repeats another page. Treat those as investigations, not a diagnosis inferred from the label. Fix a concrete mismatch you can demonstrate, then keep a record of the changed page and date.

For Lovable, check the rendering path too

Lovable documents SSR for apps created from May 13, 2026, or June 22 on Enterprise. Older React/Vite apps use on-request prerendering for verified crawlers on deployed public URLs. Unverified scanners may receive the ordinary single-page app instead; late-loading content may be absent from prerendering. Confirm your project's stack and published response rather than assuming every Lovable app behaves alike. Lovable rendering documentation.

For a rendering investigation, compare the meaningful content in the response with the rendered view and resource errors. Google can process JavaScript, but blocked resources or missing server responses can still matter. Google's JavaScript SEO guidance.

LaunchForge observes one ordinary static fetch, not a verified Googlebot fetch. A shell or size-limited result leaves content unknown; it is not proof that Google cannot index the page. Read the static-scan limitations.

Keep a small evidence record

For each investigated URL, save: intended purpose, exact status, reported crawl time, current published response, selected canonical, change made and retest date. Mark missing evidence as unknown. Visits and scanner scores cannot replace Search Console's indexing evidence.

Use a live test to inspect a meaningful repair. An indexing request can ask Google to reconsider an updated page, but it is not a promise of inclusion or timing. No step here guarantees indexing or ranking. Inspection and indexing requests.

Check the current static response Review your Lovable page setup