Platforms

Origin and Host header

The origin is where Wrenda fetches your pages from once DNS points at Wrenda — usually the platform hostname your domain used to be CNAMEd to. Managed hosts route requests by the Host header, so two things can happen:

• The host still has your custom domain attached. Requests with Host: your-domain.com work, even though the host's dashboard may warn that DNS no longer points at it.
• The host only knows its own hostname (your-app.vercel.app). Requests with your domain in the Host header get a 404 or a “deployment not found” page. In that case Wrenda must send the platform hostname as the Host header instead.

When you add a domain, Probe origin tries the origin with and without a Host override and reports reachable, the detected platform, whether a Host header is required, the suggested value, and whether the origin loops back to the domain. Accept the suggestion and the override is stored with the domain.

Vercel

Origin

https://your-project.vercel.app (the production deployment URL)

Host header

Usually required: your-project.vercel.app. Vercel serves a 404 for a Host it doesn't know.

DNS

Replace the cname.vercel-dns.com CNAME (or the Vercel A record) with the Wrenda records.

Watch out for

Vercel’s Domains page will show the custom domain as misconfigured once DNS points at Wrenda. That is expected; the site is served from the .vercel.app origin.

Alternatively keep the custom domain assigned to the project in Vercel and leave the Host header as your domain; Vercel then routes by the assigned domain. Either way the probe tells you which works. Next.js image and asset paths (/_next/image, /_vercel/…) are treated as static and always passed through.

Netlify

Origin

https://your-site.netlify.app

Host header

Often required: the .netlify.app hostname, unless the custom domain stays configured under Domain management.

DNS

Replace Netlify’s CNAME / load-balancer A record with the Wrenda records. If you used Netlify DNS for the whole zone, add the records there.

Watch out for

Netlify’s “Check DNS configuration” warning and its own certificate provisioning no longer apply; Wrenda issues the certificate.

Shopify

Origin

https://your-store.myshopify.com

Host header

Leave as your domain to start. Shopify routes by Host and may redirect the .myshopify.com hostname to the primary domain, which can loop.

Method

DNS proxy only — Shopify gives you no server or CDN configuration.

Watch out for

See limits below.

Webflow

Origin

The Webflow hostname your domain was previously pointed at (Webflow’s docs list the current value, typically proxy-ssl.webflow.com).

Host header

Your domain. Webflow routes by Host, so keep the domain listed under Site settings → Publishing.

DNS

Replace Webflow’s A records / www CNAME with the Wrenda records.

Watch out for

Webflow will show the domain as not verified once DNS changes; publishing still works.

WordPress

Origin

The server hostname or IP from your host’s control panel (for managed hosts, the host-provided hostname such as the .wpengine.com or .kinsta.cloud address).

Host header

Your domain. WordPress redirects requests whose Host doesn’t match its Site URL, so an override usually causes a redirect loop.

Already on Cloudflare?

Use Quick Connect. Otherwise make sure the origin record is not proxied by another CDN that only accepts your domain.

Watch out for

Page-cache plugins are fine; they cache on the origin, Wrenda caches the crawler-facing copy separately.

Purge on publish

Wrenda caches optimized pages for an hour and pre-rendered pages for 24 hours. To refresh a page the moment you publish, call the domain's purge webhook (Domain → Purge hook → copy URL). Drop this into a must-use plugin (wp-content/mu-plugins/wrenda-purge.php):

<?php
/**
 * Wrenda: purge the cached copy of a post when it is published or updated.
 * Paste the purge-hook URL from Domain -> Purge hook (keep the token secret).
 */
define('WRENDA_PURGE_URL', 'https://api.wrenda.ai/domains/YOUR_DOMAIN_ID/purge-hook?token=YOUR_TOKEN');

add_action('transition_post_status', function ($new_status, $old_status, $post) {
    if ($new_status !== 'publish' && $old_status !== 'publish') {
        return;
    }
    wp_remote_post(WRENDA_PURGE_URL, [
        'headers'  => ['Content-Type' => 'application/json'],
        'body'     => wp_json_encode(['urls' => [get_permalink($post)]]),
        'blocking' => false,
        'timeout'  => 5,
    ]);
}, 10, 3);

Omit urls to purge the whole domain instead. The hook is rate-limited to 10 calls per minute per domain. Details: Cache & purge.

Cloudflare Pages

Origin

https://your-project.pages.dev

Host header

Usually the .pages.dev hostname, unless the custom domain stays attached to the Pages project.

DNS

The zone is already on Cloudflare, so use Quick Connect. Pages created a proxied (orange) CNAME for the custom domain — it must be replaced by the DNS-only CNAME to proxy.wrenda.ai.

Watch out for

Pages will list the custom domain as inactive afterwards; that only affects Pages’ own certificate, which is no longer used.

Static hosts (GitHub Pages, S3, Firebase, Render…)

Same pattern: origin is the host-provided hostname, and the probe tells you whether the host needs its own hostname in the Host header. Two notes:

• Hosts that serve one site per Host header (GitHub Pages with a CNAME file, Firebase Hosting with a connected domain) generally keep working with your domain as the Host, even though their dashboards report the DNS as unverified.
• Plain object storage (an S3 website endpoint) doesn't care about Host at all; use the bucket website endpoint as the origin.

JavaScript-rendered sites

After the domain is created, Wrenda compares the raw HTML with the rendered DOM. If the rendered page has materially more text (more than 1.5× the raw text, or a framework root such as #__next or #root with under 400 characters of raw text), the domain is flagged JS-rendered and the recommended rules include Search engines → pre-render. Most Vercel, Netlify and Pages apps built with React, Vue or Angular land here.

Next