Migrate from Prerender.io without guessing at the request path.

Migration guide

This is a controlled replacement of one crawler-rendering integration with another. Audit the existing path, test representative routes, prepare rollback, change one layer, and verify both crawler and visitor responses before removing the old configuration.

No one-click migration, endpoint compatibility, automatic settings import, cache transfer, or zero-downtime guarantee is claimed.

Compare the products first

1. Record the current state

Integration, origin, hostnames, cache operations, crawler rules, and rollback files.

2. Change one routing layer

Use managed DNS or developer integration. Do not stack both migration paths.

3. Verify before cleanup

Check visitors, crawler-style responses, status codes, metadata, logs, and rollback readiness.

Before changing production

A crawler-rendering migration changes how requests are intercepted and served. The rollback must exist before the cutover, not after a problem appears.

• Record the public hostname, canonical hostname, origin URL, DNS provider, CDN or proxy, and current Prerender.io integration layer.

• Save the current middleware, Worker, reverse-proxy, CDN, or DNS configuration so it can be restored without reconstructing it.

• Inventory the sitemap and a representative set of homepage, pricing, documentation, content, dynamic, redirect, 404, and error URLs.

• Document custom crawler user agents, excluded routes, query-parameter rules, cache freshness, recache jobs, and API operations currently in use.

• Confirm who can deploy the request layer or change DNS, and agree on a rollback owner and validation window.

Migration path

The two paths solve the same routing problem at different infrastructure layers. Choose one for the production hostname.

No-code managed DNS

Use this when the host serves a static frontend or AI-built site and cannot run middleware. You need DNS access and the current hosting URL as a non-public origin.

Review DNS setup

Developer request layer

Use this when you control middleware, an edge function, Worker, Node server, Nginx, or another reverse proxy. Keep the Prerender Buddy key server-side.

Review developer setup

Controlled workflow

Keep the old configuration available until the new response path has passed representative route and visitor checks.

01

Create the Prerender Buddy site

Add the exact production hostname and choose No-code DNS or Developer integration based on the request layer you control.

For managed DNS, use the existing host URL as origin. For developer setup, generate or reuse a server-side API key.

02

Test before replacing the old path

Use the public diagnostic tools and dashboard render test on representative public URLs.

Confirm titles, descriptions, canonicals, headings, links, status codes, and readable text. Do not treat a successful homepage as coverage for every route template.

03

Prepare the cutover

Lower DNS TTL in advance when appropriate, or prepare a reversible middleware/Worker deployment.

Do not copy a Prerender.io token, endpoint, cache setting, or custom bot list into Prerender Buddy without mapping it to the current setup.

04

Change one production layer

For DNS, apply only the records currently shown in the Prerender Buddy dashboard and preserve unrelated email and verification records.

For code, deploy the Prerender Buddy integration and remove or disable the old request interceptor so the same crawler request is not processed twice.

05

Verify the live response path

Test normal visitor traffic first, then controlled Googlebot, Bingbot, GPTBot, ClaudeBot, and PerplexityBot-style requests where available.

Check response status, HTML, Prerender Buddy headers, cache source, logs, root/www behavior, redirects, and the hostname used in the sitemap.

06

Monitor before final cleanup

Watch crawler logs, fresh renders, cached hits, origin errors, and setup health through the validation window.

Only remove old credentials and obsolete configuration after the rollback window has passed and representative routes remain healthy.

Test route types, not just a convenient list of successful pages.

Homepage and primary landing page

Pricing or conversion page

Documentation or article route

Client-rendered dynamic route

Canonical redirect and root/www pair

Known 404 and representative error response

Open bot view checker Read verification guide Review crawler status Review technical evidence

DNS rollback

Restore the recorded CNAME, ALIAS, A record, or CDN target, then wait for DNS and HTTPS behavior to settle. Confirm both normal and crawler-style responses before resetting the Prerender Buddy setup.

Developer rollback

Restore the prior middleware, Worker, server, or proxy configuration from version control. Remove the Prerender Buddy route from the active deployment, then repeat visitor and crawler checks.

Do not improvise rollback

If the current integration cannot be reconstructed, postpone cutover until the configuration, credentials owner, and restoration path are documented.

• Raw HTML already contains the important public content and a rendering layer is not needed.

• The site depends on Prerender.io APIs, recache queues, device-specific snapshots, retention, or support commitments that have not been replaced.

• The request layer, DNS, origin, canonical hostname, or rollback configuration is not understood.

• The site is primarily authenticated, personalized, private, or otherwise unsuitable for public crawler rendering.

• Representative routes, error statuses, and normal visitor behavior cannot be tested during a controlled window.

• Expected volume or operational requirements exceed the selected Prerender Buddy plan and no custom setup has been agreed.

Troubleshooting

Two rendering layers intercept the same request

Do not leave both integrations active on the same request path after cutover. Duplicate interception can create loops, conflicting headers, or unexpected responses.

The origin points back to the public proxy hostname

Managed DNS requires the current hosting URL as origin. Using the public hostname as its own origin can create a routing loop.

Root and www follow different paths

Test the hostname used by canonicals, internal links, sitemaps, and Search Console. Root and www are separate HTTPS and routing endpoints.

Assets, APIs, or private routes are rendered

Keep crawler routing narrow. Skip non-GET requests, assets, API paths, authenticated content, and other routes that should not enter a public rendering path.

Old cache behavior is assumed to transfer

Prerender.io cache entries and settings do not migrate. Re-test important URLs and establish Prerender Buddy freshness settings independently.

A simulated crawler is treated as operator verification

A supplied user-agent test proves request routing, not crawler authenticity, indexing, ranking, citation, or recommendation.

Compare the products, confirm the integration layer, and contact support when the current Prerender.io configuration or rollback path is unclear.

Review plans and render limits

Open setup guide Contact support