Platform setup

Bolt setup

Use the deployed provider URL as origin and protect the public hostname.

Bolt setup

Use this guide when a Bolt-built site is deployed to a public host and crawler requests may still receive a JavaScript shell.

Bolt projects are often deployed to another provider such as Netlify, Vercel, StackBlitz, or a static host. The origin URL usually comes from that provider.

What this guide helps with

  • choosing no-code DNS setup for a Bolt site
  • finding the deployed provider URL
  • avoiding custom-domain origin loops
  • handling root vs www
  • verifying crawler-readable HTML after DNS changes

When to use this setup

Use no-code DNS setup when:

  • you have a public custom domain
  • the deployed provider URL still loads the normal website
  • you can point www.example.com to Prerender Buddy
  • you do not want to add middleware or edge code

Use developer setup if the final host can run middleware, workers, or edge functions before HTML is returned.

Platform-specific problem

Bolt helps ship quickly, but many generated sites are still client-rendered. The browser loads the app and then shows the finished page.

Crawlers may receive only the app shell if the request path is not routed through Prerender Buddy or server-side middleware first.

What to enter in Prerender Buddy

Public website address:

Example
1www.example.com

Current website location / origin URL:

URL examples
1https://your-project.netlify.app
2https://your-project.vercel.app
3https://your-project.stackblitz.io

Use the deployed provider URL, not the custom domain.

Why the origin should be the provider URL

The origin is where the normal website still loads after DNS changes.

If the origin is the same custom domain you are protecting, the setup can loop or bypass the original host.

  1. Add www.example.com as the public website address.
  2. Add the provider deployment URL as the Current website location.
  3. Copy the DNS record from Prerender Buddy.
  4. Add the DNS record where the domain is managed.
  5. Redirect root to www.
  6. Refresh status.
  7. Run Verify Installation.

Root vs www handling

Root and www are different hostnames. Protect one canonical hostname and redirect the other.

Request flow
1example.com -> https://www.example.com
2www.example.com -> Prerender Buddy

If you test example.com while only www.example.com is protected, the result may still show the original app shell.

How to verify

  1. Test the exact public hostname configured in Prerender Buddy.
  2. Run Verify Installation.
  3. Check Logs for a crawler request.
  4. Use Raw vs Rendered HTML to compare app shell vs rendered content.
  5. Test root and www separately.

What success looks like

  • crawler requests reach Prerender Buddy
  • bots receive readable text, metadata, and headings
  • the custom domain still works for visitors
  • the origin provider URL remains reachable

Common mistakes

  • using the custom domain as the origin
  • only protecting 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
  • forgetting that Bolt may deploy through another hosting provider

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