Platform setup

Tempo setup

Test whether Tempo-generated public pages expose readable HTML to crawlers.

Tempo setup

Use this guide when a Tempo site looks correct in the browser, but you want to test whether search engines and AI crawlers receive crawler-readable HTML.

Tempo is relevant when the generated site is deployed as a JavaScript-heavy public app. The important check is whether route-specific headings, links, and metadata are present for crawlers.

What this guide helps with

  • checking whether crawler-readable HTML is present
  • choosing the right public hostname
  • choosing the right Current website location / 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 original Tempo or deployment URL still loads the normal website
  • you do not want to add middleware or edge code
  • the main question is crawler-readable HTML, not changing the visitor experience

Use developer setup only if the final host can run routing logic before the JavaScript app shell is returned.

The platform-specific problem

AI-built sites can move quickly from prompt to public domain. That speed is useful, but crawler behavior still depends on what HTML the deployment returns before JavaScript runs.

A browser can show the finished page after scripts load. A crawler-style request may receive a thinner initial response.

The right first step is to test the actual hostname before deciding whether prerendering is needed.

What to enter in Prerender Buddy

Public website address:

Example
1www.example.com

Current website location / origin URL:

URL examples
1https://your-project.tempo.build
2https://your-project.vercel.app

Use the platform or deployment URL as the origin when possible. Do not use the custom domain as the Current website location.

Why the origin should not be the custom domain

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

If the origin is also the public hostname, requests can loop back to Prerender Buddy instead of reaching the original site.

Good:

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

Bad:

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

Root vs www handling

Root and www are separate hostnames.

If you protect www.example.com, make sure example.com redirects to https://www.example.com and preserves the path.

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

If Google Search Console, a sitemap, or another crawler uses the unprotected hostname, bots may still reach the original app shell.

How to verify

  1. Add the site in Prerender Buddy.
  2. Set the public website address to the exact hostname you want crawlers to use.
  3. Set the Current website location to the Tempo or deployment URL.
  4. Add the DNS record shown in Prerender Buddy.
  5. Wait for DNS propagation.
  6. Click Refresh status.
  7. Click Verify Installation.
  8. Test both root and www if both are public.

What success looks like

  • Verify Installation says the integration is connected.
  • Logs show crawler-style requests.
  • Bot View Checker shows readable page text.
  • Raw vs Rendered HTML does not show a large app-shell gap for important public pages.

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
  • assuming the generated UI and the crawler-readable HTML are the same thing

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