DNS, zones, workers, and 301 vs 410 — the real stack behind parked-domain SEO

The five layers, explained simply

Open preview

When you type a domain into a browser, five things have to agree before a single byte of HTML comes back. Most SEO advice treats the chain as a single thing called 'the redirect.' It is not. Knowing which layer you are touching is the difference between a fix that lasts and one that silently breaks the next time anyone touches a registrar panel.

The trap: a registrar 'URL forwarding' toggle changes layer one's nameserver and inserts the registrar's redirect service. A Cloudflare redirect rule changes layer four. A Worker changes layer five. All three look like 'a redirect' from the outside; they fire in completely different parts of the request lifecycle and they fail in completely different ways. See our domain forwarding explainer for when a simple 301 is fine and when it is not.

If you do not know which one is currently serving the response, you do not know what will happen the next time the registrar's parking service gets revamped.

What 'proxied' actually means, and why parked domains point at 192.0.2.1

On Cloudflare, every DNS record has an orange-or-grey cloud icon. Orange means 'proxied' — DNS queries return Cloudflare's anycast IPs, traffic flows through Cloudflare's edge, and Workers / Rules can intercept it. Grey means 'DNS only' — Cloudflare returns the real IP and gets out of the way; nothing edge-level fires.

A parked domain has no origin server. There is nothing to point an A record at — and yet, a Worker can only run on a hostname that resolves through Cloudflare's edge, which requires a proxied DNS record. The widely-used solution is to point A records at 192.0.2.1, an address from RFC 5737's TEST-NET-1 range reserved for documentation.

The IP does not route anywhere on the real internet. Cloudflare proxies the record (so Workers fire), but no traffic ever reaches the placeholder — every request is terminated at the edge and answered by the Worker.

The parked-domain stack explainer covers the strategy side of when this setup pays off.

Failure mode #1: a grey-cloud (DNS-only) record. The Worker never fires; the browser asks 192.0.2.1 for the page, the connection hangs, the user sees a timeout. Always orange-cloud for parked-domain placeholders.

Failure mode #2: a real IP from before the domain was parked, left in the zone. The Worker fires for the proxied records but a stray A record pointing at an old VPS that has since been re-leased to somebody else is now serving whatever that VPS serves on your hostname. Audit the zone every time a domain enters the parked portfolio — delete anything that is not the placeholder.

410 vs 301 vs 302 vs 404 — the equity-pass comparison

Open preview

All four are HTTP response codes. All four can be served from any of the layers above. The difference is what each one signals to a crawler and how long the URL stays in the index.

The boring truth: 410 is the most under-used code in SEO. People reach for 404 because they have heard of it, or 301 because 'redirects can never hurt' — both wrong defaults for severing a toxic profile.

410 is the only code that explicitly tells Google 'do not keep this URL around, do not pass signals through it, drop it.' Per RFC 9110 (the current HTTP semantics spec) and Google's own crawling documentation, 410 is processed faster than 404 and does not pass PageRank.

The Cloudflare request pipeline — phase order matters

If a domain has more than one rule (a Redirect Rule and a Worker, or a Page Rule and a Worker, etc.), which one wins? Cloudflare's request pipeline runs in a fixed published order. Earlier phases can short-circuit later ones, but later phases can override earlier ones if the request still reaches them.

The simplified phase order for a parked-domain stack:

Why this matters for a portfolio: people set up a 'redirect all paths to canonical' Redirect Rule in the dashboard years ago, then deploy a Worker that is supposed to 410 a few toxic paths. The Redirect Rule short-circuits the Worker — every path 301s, the Worker never runs, the toxic 410 list is dead code. The fix is to delete the dashboard rule and let the Worker handle everything. One source of truth per domain.

The corollary: a Worker that fires before the cache means responses can be customised per-request but cannot be cached cheaply by default. For a parked-domain Worker that returns small bodies (a 410 message, a short HTML handoff page, a 301 with a Location header), this is fine — the response is tiny and the Worker invocation budget is generous. For a Worker that does heavier work, add explicit cache-control headers.

The surgical pattern — one Worker, two verdicts per domain

Open preview

The reason a Worker beats every other layer for parked-domain work is that one domain frequently needs different verdicts on different paths. The apex got hit with an injection attack and inherited 100,000 Indonesian-gambling URLs; the /blog/ subdirectory is clean editorial content with real inbound editorial links. A single dashboard-level 301 cannot express that. A Worker can.

The pattern, shape-only (your routing table will be domain-specific):

Rule ordering is the whole game. The toxic-pattern matchers go first — they are the only rules that should be allowed to 410 a path. The path-specific 301s (e.g. keep /blog/ alive) go next. The default 301 to canonical runs only if nothing earlier matched. Every new toxic pattern you discover is one regex added to the top of the list; one re-deploy and the rule is live on every domain in the portfolio that includes that pattern set.

Image-extension 410s are a quiet hero. Spam-injection attacks frequently create hotlinked-image URLs (/wp-content/uploads/2019/random-spam.jpg) that show up in Google Images and inherit a long tail of crawl. A single image-extension regex in the rules array kills the lot.

Advanced routing gotchas — sidebar for portfolio workflows

If you manage a parked portfolio through an automated control plane instead of clicking each domain manually, there are four traps worth knowing before they cost you an afternoon.

Two more, less common but expensive when they bite: not every management interface exposes every routing surface, so confirm that the surface you are using can actually read and change the records you care about. And a pending zone can exist in configuration while registrar nameserver changes are still propagating, which makes the route look correct but inert.

Real example: severing 159k inbound links while preserving an editorial subdomain

Composite case from a recent portfolio audit. A defensive domain (call it example-lawfirm.com — sanitized; not the real name) was registered in 2009, ran a legitimate small-firm site through 2015, then sat with a stale WordPress install. Somewhere between 2017 and 2024 it caught an injection attack that pumped roughly 159,000 inbound links — predominantly Indonesian-gambling anchor text, judi/togel/slot variants — at hotlinked-image URLs and a handful of script-injected paths.

Discovery was straightforward: a Google Search Console new-property verification showed the impression chart was dominated by Indonesian gambling queries on /wp-content/uploads/ paths and a few /casino-* tokens. A backlink audit (Ahrefs export) confirmed the magnitude — six-figure refdomains weighted overwhelmingly to TLDs and IPs from spam-vendor clouds.

If you are inheriting a domain like this, our Wayback diligence walkthrough and aged-domain value guide cover the pre-acquisition checks.

Naïve fix: 301 the entire domain to the lawfirm's current canonical. This is the move that gets the receiving site demoted. Even with Google's SpamBrain discounting most of the spam cluster, a six-figure burst of overtly-toxic anchor text pointed at the canonical via 301 is exactly the kind of signal that gets a manual action escalated post-March-2026.

Actual fix, deployed via the single portfolio Worker:

One — the apex (example-lawfirm.com and www) got a blanket 410. Every path on the apex, every status code, every crawler — gone. Two — a /blog/ subdirectory that had ~8 editorial pages with legitimate inbound links from law-school faculty pages and bar-association blog posts kept its 301 to the canonical's matching /blog/ path.

Three — image-extension regex 410ed every /wp-content/uploads/*.jpg hotlink. Four — the toxic-token regex 410ed every path containing judi|togel|slot|gacor|casino|viagra (etc.).

Five — the default for the apex stayed 410, so even if a new injection vector appeared on an unguessed path, the verdict was already 'gone.'

Result, four weeks in: the spam cluster's impression-share on the apex dropped to effectively zero (Google honoured the 410 quickly — far faster than the same domain spent in 404 limbo earlier in the audit). The /blog/ paths still passed their (modest, legitimate) editorial equity through to the canonical.

The canonical's backlink profile showed no detectable inheritance of the gambling cluster — the 410 on the apex severed the inheritance, and the 301 only ran on the eight URLs whose link profiles were verified clean.

Monthly checklist for portfolio managers

A parked-domain portfolio is not a one-time setup. The injection vectors evolve, the registrar UIs change defaults, the NS pairs rotate. Run this checklist once a month on every defensive domain you own — the whole pass takes 15 minutes for a small portfolio and an hour for a large one.

One. dig NS for every domain → confirm the nameservers still point at the edge you expect. Registrars occasionally flip a domain to their parking nameservers if a credit-card renewal fails or a policy changes.

Two. curl -sI https://domain/ for every domain → confirm the status line is the one you expect (301 to canonical OR 410 OR 200 with the human-handoff page). Any unexpected status is a configuration drift.

Three. Review the DNS records in each zone → confirm there are no stray A/AAAA records pointing at an unexpected real IP. Anything unexpected is either an oversight or somebody else's box answering on your hostname.

Four. Pull a Search Console impression report for each apex → look for query clusters in languages or topics you do not own. A spike of foreign-language queries on a domain that has not had real content in five years is the early-warning signal for a new injection vector.

Five. Refresh the toxic-pattern list → add any new tokens you saw in the audit. One policy update, every domain in the portfolio inherits the protection. The renew-forever rule covers the registrar-side calendar that keeps the policy operational year over year.

Six. Verify the routing layer is still active. Account-level changes or dashboard edits can silently change response behavior. The smoke test is the curl from step two — if the status line changes, inspect the routing surface first.