I filed a takedown. Did anything actually happen?
There is a definite answer, and it takes about a minute to find. A domain's registry record carries status codes, and they distinguish a registrar that acted on your report from a registrar that did nothing at all — including the very common case where a routine lock that was there before you filed gets mistaken for a result.
clientHold or serverHold means real enforcement — the domain has stopped resolving worldwide. clientTransferProhibited on its own means nothing has happened: it is the default lock on nearly every registered domain on the internet, it almost certainly predates your filing, and you should escalate rather than wait. pendingDelete or redemptionPeriod is the registration expiring — a different mechanism, and not a response to you.Check the domain you filed against — free
Paste the domain and we'll run the same checks we run in our own case work: whether it still resolves, domain age, impersonation signals, fake-store patterns, phishing markers and payment red flags. You'll see the 0–100 risk score, a plain-English verdict and the two most serious red flags free. The full $2report adds all five with the evidence behind each, plus a 3-step “what to do now” list.
A live check tells you whether it is serving right now. It is not a substitute for reading the status codes below — a site can stop loading for reasons that have nothing to do with your filing.
Where the answer lives
Every domain registration carries at least one status code, and often several. They are returned by a WHOIS or RDAP lookup on the domain — your registrar's lookup page will do, as will any public WHOIS. The codes come in two families, and the difference matters when you are chasing someone:
- Client codes are set by the registrar — the company the domain was bought through. These start with
client…. - Server codes are set by the registry — the operator of the top-level domain itself (the
.shopor.compart). These start withserver…, and they take precedence over client codes, so a registrar cannot quietly reverse one.
So the prefix tells you who acted, and the code itself tells you what they did. Screenshot the record, including the date. If you ever escalate, the sequence of status records over time is the spine of your complaint.
What each code means for your filing
These are the codes that actually come up after an abuse report. Find yours, read the verdict, and act on the last line.
clientHoldEnforcement — it workedReal enforcement. Something happened.
Your registrar set this, and it is the one that actually stops a site. The domain is removed from the DNS zone, so it no longer resolves anywhere in the world — not for you, not for the customer being defrauded, not from any country or network. The website is gone even though the registration still exists.
This is the outcome a takedown request is aiming for. Screenshot the WHOIS record showing the status, with the date — that is your proof the filing worked, and it is the single most useful thing to keep on file.
serverHoldEnforcement — it workedReal enforcement, one level higher up.
Same effect as clientHold — the domain is not activated in the DNS and stops resolving globally — but it was set by the registry that operates the TLD rather than by the registrar. Server codes take precedence over client codes, so a registrar cannot quietly undo it.
Treat it as a stronger, stickier version of clientHold. Record it the same way, with the date.
clientTransferProhibitedNot enforcement — nothing happenedNot enforcement. This is the default lock on nearly every domain.
This is the code people most often mistake for a result, and it is the reason this page exists. It only prevents the domain being transferred to a different registrar. It does not touch DNS, so the clone resolves and sells exactly as it did before. Most registrars apply it automatically at registration as routine anti-hijacking protection — it is on a large share of ordinary, entirely legitimate domains, and it was almost certainly already there before you filed anything.
If this is the ONLY status on the record, nothing has happened. Do not read it as progress and do not wait — that wait is exactly how a clone stays up for weeks. Escalate.
pendingDeleteExpiry — different mechanismA different mechanism entirely — expiry, not enforcement.
The registration is on its way out at the end of its lifecycle. This is what an unpaid or abandoned domain looks like, not what an enforced one looks like. It tells you the registrant stopped paying or walked away; it does not tell you anyone acted on your report.
Don't claim it as a win, and don't rely on it. An operator who wants the name can often still renew or recover it, and abandoning one domain costs a kit operator almost nothing.
redemptionPeriodExpiry — different mechanismAlso expiry — and explicitly reversible.
The domain has been deleted and is in the window where the registrant can still restore it. Like pendingDelete, this is the lifecycle running its course, not a response to an abuse report.
Keep monitoring it yourself rather than closing the case. A domain in this state can come back.
ok / activeBaseline — no action takenThe baseline. No holds, no restrictions.
The standard status for a domain with nothing applied to it. If your clone reads ok and resolves, no registrar or registry action has been taken against it.
Same as clientTransferProhibited-only: escalate rather than wait.
The trap: clientTransferProhibited is not a result
This is the mistake that costs people weeks, so it is worth being blunt about. Someone files a report, checks the WHOIS a few days later, sees a status code sitting there that looks official and restrictive, and concludes the wheels are turning. Then they wait.
clientTransferProhibited only stops the domain being moved to a different registrar. It does nothing to DNS. The clone resolves, loads and takes payments exactly as it did before. Most registrars apply it automatically the moment a domain is registered, as standard protection against domain hijacking — which means it is present on a very large share of completely ordinary, legitimate domains, and it was almost certainly on the clone before you had ever heard of it.
If it is the only status on the record, the honest reading is that no registrar or registry has taken any action. That is not a reason to despair — it is a reason to escalate today rather than wait another fortnight for a lock that is already as set as it is going to get.
pendingDelete and redemptionPeriod are a different mechanism
Both of these mean the registration is running out — the registrant stopped paying, or let it go. It is easy to read as a win, and occasionally it follows real pressure, but it is the domain lifecycle doing its ordinary thing rather than anyone responding to your report.
Two reasons not to bank it. First, redemptionPeriod is explicitly reversible: the registrant can restore the domain during that window. Second, for a kit operator running many storefronts at once, abandoning one domain costs almost nothing — the catalogue, the template and the fabricated reviews are already sitting on the next one. Keep the case open.
A clone that went quiet with no hold on record has probably just moved.
If the site stopped loading but the registry record shows no clientHold and no serverHold, then as far as the registry is concerned nothing was ever done to that domain. Far more often than not the operator simply relocated — repointed the DNS at a new host, moved behind a proxy, or parked it while a replacement goes up on a fresh domain. Relocation and enforcement look identical from a browser, which is why the status record is the thing to check and a blank page is not.
We have watched this from both sides in our own case work. One domain in our teardown stopped resolving between checks and returned a “domain has not been configured” response — consistent with the storefront being pulled, but we did not observe why, and a domain that stops resolving can be re-pointed at any time. We recorded exactly that, and no more.
Practically: before you close a case because “the site is down”, check the status record. If there is no hold, assume the storefront is somewhere else and go looking — the same catalogue on a new domain, or the same domain on a new host.
The escalation ladder
If the record shows no hold, this is the order to work through. It is not arbitrary: each rung expects you to have tried the one before it, and skipping a step is the most common reason a complaint gets bounced back unread.
The registrar
First, always. Nothing else is accepted until this has been tried.
The registrar sponsors the registration and is the party that can set clientHold. For a single domain or a handful, this is the correct first desk. File to their published abuse contact, state plainly how the domain is being used, and attach evidence in which the full domain name is visible in the screenshot itself.
A registrar can decline, or can decide it is not the right party to judge the content. Keep every reply — the refusal is what the next rung needs.
The TLD registry operator
When the registrar has not acted in a reasonable time, or the abuse spans many registrars.
The registry runs the top-level domain itself and can set serverHold, which a registrar cannot undo. Registry abuse contacts are published via ICANN's TLD and operator listings. This rung suits large-scale patterns — the kind where one operator is running many domains at once — better than a single complaint does.
Registries generally expect the registrar to have been approached first, and will often point you back if it hasn't.
ICANN Contractual Compliance
When the registrar or registry ignored an actionable, well-evidenced report.
This is not a takedown service and will not remove the site. It enforces the contract: a registrar's failure to publish abuse contacts, or to investigate and respond to an abuse report, is the kind of thing it acts on. You must show you filed first, include the subsequent correspondence, and explain why you believe the response was inadequate. Use the registrar form or the registry form depending on who failed.
ICANN's authority covers gTLDs (.shop, .com, .info) and does not extend to country-code TLDs like .us or .in, nor to hosts, CDNs or payment providers. For a ccTLD you go to that registry's own published contact instead.
One thing worth internalising from our own case work: registrars and hosts do act — but only on a request that arrives in the shape they require. A request drafted for a registrar abuse desk is routinely rejected by a host, and neither is shaped like a marketplace or ad-platform report form. If a filing came back rejected, the fault is more often the format than the facts.
Three clones, three outcomes, from one case file
We took apart a mass-produced .shop clone kit and published the whole thing in our clone kit teardown — 38 clone domains copying 36 brands, each one re-fetched and date-stamped, and all of them indexed by brand in the documented fake-store index. Three of those domains ended up illustrating the entire point of this page, because all three had a different registry record and a different fate.
clientHold, set the same day the brand published its advisory
Gone. The domain stopped resolving globally. In our case file a registrar set clientHold on a clone the same day the brand went public about it — the fastest result we have observed, and the only timing claim our evidence supports.
A named, publicly documented, correctly filed complaint is the thing that moves a registrar. Not volume, and not persistence.
No registry record of any action at all
One domain simply stopped resolving between our checks, returning a “domain has not been configured” body on two separate cache-bypassed checks. No hold appeared. We did not observe why, and we do not claim credit for it.
Absence of a hold means absence of evidence that anyone acted. Treat a quiet domain as unresolved, not as closed — it can be re-pointed any day.
clientTransferProhibited only — and nothing else, as the record stood through 15 September 2026
Live and selling for as long as its record carried nothing but the default lock. That storefront was first documented live on 27 May 2026 and was last confirmed “live, HTTP 200” on 15 September 2026 — 111 days. On 6 October 2026 its observed state was “does not resolve”. Through 15 September 2026 the only status on its registry record was the routine transfer lock that was there from the start — nobody had filed against that particular one so far as the record showed, and we hold no filing of our own for it. Reading GMO Registry, the .shop registry’s own RDAP record for thewinfieldcollectionco.shop on 22 September 2026, the record carried the status codes “client hold”, “client transfer prohibited” and “inactive”, last changed 17 September 2026 (2026-09-17T06:55:38Z). The registration itself is intact: created 12 May 2026, running to 12 May 2027, and not deleted. That is consistent with the “does not resolve” state we observed ourselves on 6 October 2026. clientTransferProhibited on its own is the routine lock carried by nearly every registered domain and shows nothing by itself. What we record here is the combination, read together: a hold on the registry record, no answer in the DNS on our own checks, and a registration that has neither expired nor been deleted — the name is still registered, it is simply not in the zone. We hold no filing, no correspondence and no reference number for this domain. We do not know who asked for this, or why. A registrar or registry acting after we published is not a registrar or registry acting because we published, and we claim no part in it.
This is the case that teaches the lesson: for as long as the record carried nothing but the default transfer lock, the storefront kept trading. The default lock is not a result, and a domain carrying only that code is a domain no desk has acted on.
Put side by side, the asymmetry is hard to miss. Across three separate brands we found the same asymmetry with zero counter-examples: every domain a brand named publicly and filed against is gone; every unnamed sibling domain is still trading. The third storefront above was first documented live on 27 May 2026 and was last confirmed “live, HTTP 200” on 15 September 2026 — 111 days. On 6 October 2026 its observed state was “does not resolve”. Through 15 September 2026 the only status on its registry record was the routine transfer lock that was there from the start — nobody had filed against that particular one so far as the record showed, and we hold no filing of our own for it. Reading GMO Registry, the .shop registry’s own RDAP record for thewinfieldcollectionco.shop on 22 September 2026, the record carried the status codes “client hold”, “client transfer prohibited” and “inactive”, last changed 17 September 2026 (2026-09-17T06:55:38Z). The registration itself is intact: created 12 May 2026, running to 12 May 2027, and not deleted. That is consistent with the “does not resolve” state we observed ourselves on 6 October 2026. clientTransferProhibited on its own is the routine lock carried by nearly every registered domain and shows nothing by itself. What we record here is the combination, read together: a hold on the registry record, no answer in the DNS on our own checks, and a registration that has neither expired nor been deleted — the name is still registered, it is simply not in the zone. We hold no filing, no correspondence and no reference number for this domain. We do not know who asked for this, or why. A registrar or registry acting after we published is not a registrar or registry acting because we published, and we claim no part in it.
Which is the encouraging half of the finding, oddly. The domains that came down are the ones a brand named publicly and filed against properly. The variable that moved was not luck or volume — it was a correctly addressed request, with evidence attached, sent to the desk that could act on it.
Found a clone and not sure where to start?
If you are earlier in this than “I already filed”, the order of operations matters more than the paperwork does — blocklist first so customers are protected within hours, then work out which desk can actually act. Someone cloned my store — what to do, in order walks the whole sequence, including how to tell a mirror from a scrape-copy before you waste a notice on the wrong mechanism.
And the evidence behind everything on this page is in the clone kit teardown — the domains, the artefacts, the dated re-checks, and what the registry records looked like in each case.
We produce the evidence and the correctly addressed request; on a Takedown Engagement we also submit it to the abuse desks as your authorized agent. We are not a law firm, and filing an abuse complaint is not legal representation. We do not monitor continuously, do not contact the registrant on your behalf, do not recover funds, and do not give legal advice. Nothing here is a guarantee of an outcome or a timeline.
Scam Detective — pay-per-use scam intelligence. One-off checks, no subscription, no account.
Every finding here is an assessment of publicly available information at the time of the check, and is not legal advice. We produce the evidence and the correctly addressed request; on a Takedown Engagement we submit it to the abuse desks as the customer’s authorized agent, which is an administrative act and not legal representation. We do not monitor continuously and never contact the registrant on a customer’s behalf, and no outcome or timeline is guaranteed. Confirm your own trademark position before sending anything adversarial. Domain statuses were captured on 6 October 2026 and may have changed since.
Questions, or are you the brand owner? scam-detective8@mail.acoco.ai