Platform setup

Vercel setup

Understand when Vercel hosting still needs prerendering or middleware.

Vercel setup

Use this guide when a Vercel-hosted site needs crawler-readable HTML.

Vercel hosting does not automatically mean a site is server-rendered. A Vercel-hosted React, Vite, or client-side app can still return a thin app shell if the app is not using SSR or static generation for public pages.

What this guide helps with

  • choosing no-code DNS setup or Vercel middleware setup
  • understanding Vercel hosting vs server-rendered HTML
  • storing API keys safely
  • verifying crawler requests on the production hostname
  • avoiding root-vs-www and origin URL mistakes

When to use no-code DNS setup

Use no-code DNS setup when:

  • the site is already deployed as a client-rendered app
  • you can point www.example.com to Prerender Buddy
  • you have a separate Vercel origin URL
  • you do not want to add middleware

The origin usually looks like:

URL examples
1https://project.vercel.app

Do not use the custom domain as the Current website location.

When to use developer setup

Use Vercel or Next.js middleware when:

  • DNS should stay unchanged
  • the project can run middleware before HTML is returned
  • you can store PRERENDER_BUDDY_API_KEY as a server-side environment variable
  • you want crawler routing to live inside the deployment

Use SSR or static generation if you are rebuilding the site and want rendering handled by the application architecture itself.

What to enter in Prerender Buddy

For no-code DNS setup:

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

For developer setup:

Example
1Public website address: www.example.com
2Connection method: Developer/API setup
3API key: stored in Vercel environment variables

API key storage

Add the key in:

Environment variable
1Vercel Project Settings -> Environment Variables
2Name: PRERENDER_BUDDY_API_KEY
3Value: your_site_api_key

Do not use:

Environment variable
1NEXT_PUBLIC_PRERENDER_BUDDY_API_KEY
2VITE_PRERENDER_BUDDY_API_KEY

Those values can be exposed to browser code.

Middleware placement

Crawler routing must happen before the JavaScript app shell is returned.

Good places:

  • Next.js middleware
  • Vercel middleware
  • server-side route handling

Too late:

  • React components
  • client-side hooks
  • browser-only scripts

Root vs www handling

Protect one canonical hostname, usually www.example.com, and redirect the other version to it.

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

If both hostnames serve content directly, verify both.

How to verify

  1. Deploy the Vercel middleware or DNS change.
  2. Test the production custom domain, not only the .vercel.app preview.
  3. Run Verify Installation.
  4. Check render logs.
  5. Compare root and www.

What success looks like

  • crawler-style requests receive the rendered page
  • page-specific title, description, H1, and links are visible
  • normal visitors continue seeing the normal Vercel app
  • logs show crawler requests after verification

Common mistakes

  • assuming Vercel hosting means SSR
  • using NEXT_PUBLIC_ for the API key
  • testing preview URLs instead of the production domain
  • protecting only one hostname but submitting the other in Search Console
  • adding crawler logic inside browser React code

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