Publish and connect a custom domain

Run the pre-publish checks, go live on a cvrlanding.com link or your own domain, and roll back when you need to.

Updated October 14, 2026

On this page

Checks before publishing

Publish from Publish & domains or the builder’s Publish artifact. CVRLanding first checks the version and lists what passed and what needs attention:

  • Content sanitation: no unsafe markup, scripts or links.

  • Dead links, and images or files that fail to load.

  • Unconnected forms: every form needs somewhere to send its submissions.

  • Broken event mappings between the page and your ad platforms.

  • Payment setup: an order page needs a configured payment method, such as cash on delivery.

  • Factual claims without a source, shown as warnings.

  • Accessibility and the mobile layout.

  • Privacy links and SEO metadata: page title, description and sharing image.

  • Pixel consent: ad tags wait for consent where it’s required.

  • Domain status, when you publish to your own domain.

Fix what’s flagged, publish with one click, then copy the link or its QR code. Publishing needs a paid plan, and how many pages can be live depends on your plan.

Every published page gets a hosted link in the form cvrlanding.com/ld/{slug}, for example cvrlanding.com/ld/beauty-offer. You choose the slug, which must be:

  • Lowercase.

  • Unique: one slug points to one page.

  • Not one of the words CVRLanding reserves for its own pages.

If you change a slug, the old link keeps serving the same page — it is not redirected and never reassigned — so ads that use it keep working and attribution isn’t lost. Still, update those ads’ final URLs when you can.

Snapshots and rollback

Each publish creates an immutable snapshot of that version. Visitors switch to it in a single step, so nobody sees a half-published page, and editing the draft afterwards never changes what’s live.

To undo a publish, roll back to an earlier snapshot. If a publish fails, whether at a check, during the build or in the health check after deployment, the last good version stays live and you see what went wrong.

Connect a custom domain

Publish on a domain you already own: a subdomain such as offer.example.com, or an apex domain such as example.com. CVRLanding doesn’t sell domains, and you need access to your domain’s DNS settings.

  1. In Publish & domains, add the domain, for example offer.example.com.

  2. Prove you own it: add the TXT record the wizard shows to your DNS.

  3. Point the domain to CVRLanding with the record the wizard shows: a CNAME record for a subdomain, or an A or ALIAS record for an apex domain.

  4. Wait for the automated DNS checks. The status updates as records are found, and you can run the check again at any time.

  5. Once the domain is verified, an HTTPS certificate is issued automatically.

  6. When the status reads Active, publish your page to the domain.

Copy record names and values exactly as shown, because they’re specific to your domain. The wizard also has guides for common DNS providers.

Domain status

  • Pending verification

    What it means

    The checks haven’t found the TXT record yet, or the domain doesn’t point to CVRLanding yet.

  • Verified

    What it means

    Ownership is proven and the DNS checks have passed.

  • Issuing TLS

    What it means

    The HTTPS certificate is being issued. This happens automatically.

  • Active

    What it means

    HTTPS works, and pages can be published to the domain.

  • Error

    What it means

    A check or the certificate failed, for example because a record changed. The wizard shows what went wrong and what to fix.

Certificates renew automatically. We email you when the domain is ready, and if there’s a problem renewing its certificate.

DNS tips

  • DNS changes can take minutes to hours to appear, depending on your provider and the record’s TTL.

  • If your DNS provider proxies traffic, as Cloudflare does in proxied mode, set the record to DNS only until the domain is active.

  • Remove older records for the same name. A name with a CNAME record can’t have other records, and a leftover A record can send visitors to the wrong server.

  • Watch for doubled names such as offer.example.com.example.com, a common slip when a provider appends your domain to the record name.

  • Not every provider supports ALIAS records. If yours doesn’t, use the A record the wizard shows, or publish on a subdomain.

How many custom domains you can connect depends on your plan. See pricing.

Removing a domain

Remove a domain in Publish & domains when you no longer need it. Your pages stop being served on that hostname, and you can then delete its DNS records at your provider.

The hostname is released safely: no other workspace can take over the old entry, and anyone who adds the domain again, including you, must verify ownership afresh. Before removing a domain that live ads point to, change those ads’ final URLs first.

Domains, redirects and your ads

Keep the approved page behind the ad

Never use a domain, a slug or a redirect to send ad traffic somewhere other than the page the ad platform approved. To send traffic to a different page, change the ad’s final URL on the ad platform instead. Swapping the destination behind an approved ad can be treated as circumventing the platform’s review, which can get an ad account suspended. See the acceptable use policy.

The same goes for reusing an old slug or domain for a different offer while ads still point to it. Give the new offer its own page and link, and update the ads.