1. Record the current state
Integration, origin, hostnames, cache operations, crawler rules, and rollback files.
Migration guide
Migrate from Prerender.io without guessing at the request path.
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 first2. 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
Build a reversible migration record.
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
Choose the layer you actually control.
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 setupDeveloper 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 setupControlled workflow
Prepare, cut over, verify,then clean up.
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.
Representative URL verification
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
DNS rollback
Restore the previous public target.
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
Redeploy the previous request layer.
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
Stop when the previous state is unknown.
If the current integration cannot be reconstructed, postpone cutover until the configuration, credentials owner, and restoration path are documented.
When migration should not proceed
- 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
Common migration failures
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.
Review the setup path before changing production.
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