// SETUP

Two records. That's the whole thing.

One TXT record to prove the domain is yours. One CNAME when you're ready for us to serve it. No plugin, no script tag, no repo access, no Cloudflare account, no code review. It works the same on WordPress, Shopify, Squarespace, a Vercel app or a box you rent — because from where we stand they are all just an origin.

The second record is optional and it stays optional. Everything else in Citeworthy — audits, findings, drafts, Search Console — works without it, on every plan including Free.

start free what being in the path means →
// THE ACTUAL FLOW

Two things on day one. Two when you're ready.

Not a four-step wizard, because we do not have one and drawing one would be the first lie of the relationship. The wizard is three screens and stops at "scheduled"; the edge is switched on afterwards, from the site's own page, whenever you decide you want it.

// DAY ONE
1 · Add the site

Type a URL. That is the whole form.

2 · Prove it's yours — one TXT record

A _citeworthy TXT record with a token we generate. Copy button per field. Press "check DNS" and the first audit schedules itself.

At this point you have audits, findings and drafted fixes. Nothing routes through us and nothing has been changed.

// WHEN YOU’RE READY
3 · Connect Search Console

Google OAuth, read-only scope, one click. This is what lets a change get a measured verdict — and without it, nothing can ever earn autonomy. Disconnecting deletes the data.

4 · Point one CNAME at the edge

Confirm where your content actually lives, add the record below, press verify, wait for the certificate. Usually minutes.

Both of these are opt-in, independently, at any time or never.

// THE ONE RECORD

This is literally what you type.

Three fields, copied one at a time on purpose: the single biggest cause of a failed DNS step is a value pasted into the wrong box, or a name pasted as a full domain into a panel that appends the domain for you. One blob to copy would hide both.

Type   CNAME
Name   www
Value  edge.citeworthy.io
Enter just "www" as the name — most DNS panels append your domain automatically, and typing the full "www.example.com" creates "www.example.com.example.com".
And you can check it from your own machine, before you ever sign up for anything:
dig +short CNAME www.example.com

We re-check automatically every hour too — you do not have to sit on the page and press a button. And when your hostname does not resolve yet, we show you an empty required field for your origin rather than a prefilled guess, because a wrong origin confirmed in one click is how a site goes dark the moment DNS flips.

// WHEN IT DOESN’T WORK

The seven screens we hope you never see.

Every one of these is real. Not a mock-up and not a paraphrase: this page calls the same function your dashboard calls, with made-up inputs, and prints what comes back. Two of them are permanent — if your site sits behind another CDN, or your DNS provider cannot point a bare domain at anyone, the managed edge cannot work for you. Two of them are ours to fix, and they say so rather than sending you to your DNS panel.

We put these on a marketing page for the same reason we put them in the product: a setup flow that only describes the happy path isn't a setup flow, it's an advertisement.

// YOUR MOVE state: blocked_cdn
www.example.com is behind Fastly, and that makes this impossible.

Cloudflare has to prove you own www.example.com before it can issue a certificate for it, and it does that by reading your DNS. Fastly sits in front of that and hides it, so the check can never succeed — this is a hard limitation of Cloudflare for SaaS, not a temporary failure, and waiting will not fix it. To use the managed edge you would have to take www.example.com off Fastly first. Your site is serving exactly as it did before — nothing routes through us until your DNS points here, and removing that record puts it back.

Permanent. Cloudflare has to read your DNS to prove you own the name, and another CDN hides it. We say so on the first screen instead of the fourth.

// YOUR MOVE state: blocked_apex
example.com is a bare domain, and your DNS provider cannot point one at us.

A bare domain cannot hold a CNAME record — that is a rule of DNS, not a limit we chose. Some DNS providers work around it with an ALIAS or "CNAME flattening" record; your DNS provider does not. The way through is to serve your site from www.example.com instead: a CNAME on www pointing at us, then a 301 redirect from example.com to www.example.com (most hosts have a one-click setting for this). We show you the exact record once we have confirmed we can reach your origin. Search engines follow that redirect and consolidate your ranking on the www address. If you would rather not restructure, leave the managed edge off — everything else in citeworthy works without it. Your site is serving exactly as it did before — nothing routes through us until your DNS points here, and removing that record puts it back.

Permanent as stated, with a way through: serve from www and 301 the bare domain at it. A bare domain cannot hold a CNAME — that is a rule of DNS, not a limit we chose.

// YOUR MOVE state: pending_dns
www.example.com does not resolve to anything yet.

We looked www.example.com up and got no answer at all — no address, no CNAME. Usually that means the name is new, or the record has not propagated yet, or there is a typo in it. Add the CNAME below and check again; DNS changes can take a few minutes to an hour to show up. Your site is serving exactly as it did before — nothing routes through us until your DNS points here, and removing that record puts it back.

"Add a CNAME" is useless advice if the name itself is not live yet, so that case gets its own screen.

// YOUR MOVE state: pending_dns
Add one DNS record, then press verify.

www.example.com currently points at example-app.vercel.app. Nothing changes until you point it at us, and you can undo it at any time by putting the old record back. Your site is serving exactly as it did before — nothing routes through us until your DNS points here, and removing that record puts it back.

The ordinary waiting state. It tells you where the name points today, so you can tell whether you edited the record you thought you did.

// YOUR MOVE state: origin_unreachable
example-app.vercel.app is up, but it is not serving www.example.com.

We fetched https://example-app.vercel.app/ over HTTPS exactly the way the edge does — same address, same SNI, same Host — and it answered 404 for the site root, which a working origin almost never does. This is the failure that looks like success: the machine is reachable, so a plain "is it up" check passes, but the host decides WHICH site to serve from the name it is asked for — and for example-app.vercel.app it is not yours. Managed platforms (Shopify, Squarespace, Webflow and the like) usually need the domain added to the site inside their own dashboard before they will answer for it. Fix that, or point us at the origin name that does serve www.example.com, then check again. Your DNS points at us and the certificate is live, so we are already in the path for www.example.com — we are passing through whatever your origin returns, unchanged. Nothing we do can fix an origin that is not answering for this name; fix it there and press "check origin", or point the DNS record back where it was and we are out of the way as soon as it propagates.

Our own source calls this "the failure that looks like success": the machine is reachable, so any "is it up" check passes, but it is not serving your site. We stay in the path and say so.

// OUR MOVE state: error
The certificate for www.example.com has not been issued.

Cloudflare said: caa_error: CAA record prevents issuance. The most common cause is a CAA record on example.com that only permits certain certificate authorities — if you have one, it needs to allow Let's Encrypt and Google Trust Services. If you do not, this is ours and we will chase it. Your site is serving exactly as it did before — nothing routes through us until your DNS points here, and removing that record puts it back.

Ours to chase — and the detail names the most common customer-side cause first, because a CAA record is something you can fix in a minute and we cannot fix at all.

// OUR MOVE state: not_configured
We cannot set this up right now.

Managed edge provisioning is not configured on this deployment, so we cannot create the certificate for www.example.com. This is on us, not on your DNS — nothing you can do will change it, and nothing about your site has been touched. We are on it.

Entirely ours. Nothing you can do will change it, and the screen says that rather than sending you to your DNS panel to rattle a door that is not locked.

If the first two apply to you, everything else in Citeworthy still works — audits, findings, drafts, Search Console, impact verdicts. You just apply the fixes yourself, which is how the product worked for its whole first year.

// THE PART EVERYONE ASKS ABOUT

Getting out is one record too.

Traffic follows DNS. Point the record back where it was and we are out of the path as soon as it propagates — no ticket, no offboarding call, no export window, and nothing on our side has to agree. Short of that, one button in your dashboard turns us into a plain forwarder within sixty seconds. That number isn't marketing rounding: sixty seconds is how long our edge caches the setting, and it is the shortest interval the platform allows.

start free the operational story → our status page