Platform setup

Lovable setup

Connect Lovable custom domains without sending bots to the app shell.

Lovable setup

Use this guide when a Lovable site looks finished in the browser, but crawlers may still receive a JavaScript shell.

Lovable is fast for shipping public pages. The important setup detail is that crawler routing must happen before the app shell is returned.

What this guide helps with

  • connecting a Lovable custom domain through no-code DNS setup
  • choosing the right public hostname
  • finding the Lovable origin URL
  • avoiding root-vs-www indexing problems
  • verifying that crawler requests reach Prerender Buddy

When to use this setup

Use no-code DNS setup when:

  • the public hostname can point to Prerender Buddy
  • the Lovable-hosted project URL still loads the normal website
  • you do not want to add custom middleware
  • the issue is crawler-readable HTML, not the visitor experience

If the site can run server middleware before HTML is returned, developer setup can also work, but most Lovable custom-domain setups should start with no-code DNS.

Platform-specific problem

A Lovable site can look correct in a browser because JavaScript runs and renders the finished page.

Crawler-style requests may receive something closer to:

HTML
1<div id="root"></div>
2<script src="/assets/app.js"></script>

That is why testing the browser preview is not enough. Check what crawler requests receive.

What to enter in Prerender Buddy

Public website address:

Example
1www.example.com

Current website location / origin URL:

URL examples
1https://your-project.lovable.app

Use the Lovable-hosted published URL as the origin. Do not use the custom domain as the Current website location.

Why the origin should be the Lovable URL

After DNS changes, the public hostname points to Prerender Buddy.

If the origin is also the public hostname, Prerender Buddy may send the request back to itself instead of to the original Lovable site.

Good:

Example
1Public website address: www.example.com
2Current website location: https://your-project.lovable.app

Bad:

Example
1Public website address: www.example.com
2Current website location: https://www.example.com

Root vs www handling

If www.example.com is protected, redirect example.com to https://www.example.com.

Otherwise Google may crawl the root domain and still see Lovable's original app shell.

The redirect should preserve the path:

Request flow
1https://example.com/blog/post
2  -> https://www.example.com/blog/post

How to verify

  1. Add the DNS record shown in Prerender Buddy.
  2. Wait for DNS propagation.
  3. Click Refresh status.
  4. Click Verify Installation.
  5. Test the exact hostname you configured.
  6. Open Logs and confirm a crawler request appears.
  7. Run Bot View Checker on both root and www if both are public.

What success looks like

  • Verify Installation says the integration is connected.
  • Logs show a crawler request.
  • Bot View Checker shows real page text.
  • The root domain redirects to the protected www hostname, or both hostnames are configured intentionally.

Common mistakes

  • using the custom domain as the origin
  • protecting only www while root still serves the app shell
  • testing the wrong hostname
  • adding crawler logic inside React instead of routing before HTML is returned
  • not waiting for DNS propagation
  • submitting the root sitemap when only www is protected

Ready to check the setup?

After DNS or middleware is deployed, use Verify Installation from the site dashboard and check the logs tab for crawler requests.

Still stuck? Email support@prerenderbuddy.com.

Open dashboard