Ten weeks of decay: what 60 documented clone hostnames did between 27 July 2026 and 6 October 2026

The finding this study turns on: decay is not one-way

One row of the 60 answers the question on its own, and it is quoted here from its own record rather than described in ours — both observations, both dates, both states in the same three-string vocabulary every page on this site uses. noguhq.shop reproduces NOGU.

We did not observe why it stopped resolving, we make no claim that it was removed, suspended or taken down, and a hostname that stops resolving can be re-pointed at any time — one in this corpus already has. Both observations stay on the record with their own dates, and neither is written as the end of anything. Read noguhq.shop's full dated record, free and check the two quotations above against it word for word.

This is also the reason no row on this index is ever labelled finished: 1 of 60 has been observed quiet and then serving again, and a vocabulary that cannot represent that is a vocabulary that will eventually be wrong on a page somebody relied on.

Every state change on the record, and which way it moved

Since 31 July 2026 — the earliest dated re-check on this record, 67 days before our 6 October 2026 sweep — 20 of the 60 hostnames recorded a state different from the observation before it: 19 moved away from “live, HTTP 200” and 1 moved back to it. Every one of those observations stays on the record with its own date, and none of them is written as the end of anything.

Read a row as two checks and the gap between them: the state we recorded, the date we recorded it, and the state we recorded next. The direction column says which way it moved between those two dates — nothing about who moved it or why.

1 of those changes were recorded on the 6 October 2026 sweep itself, each confirmed on two independent checks; the other 51 hostnames we observed that day repeated the state we had recorded for them before. A server answering 403 or 404 is not a takedown: enforcement means a registry status code (clientHold or serverHold) read back off the domain’s record, and we have read none for this hostname. We record only the state we observed, on the day we observed it.

The rows that were already quiet the first time we re-checked them

These 6 hostnames are counted separately from the table above, and deliberately: the first dated re-check we hold for each of them already found it not serving, so there is no earlier dated status of ours to compare it against. What the record does hold is the day we last observed each one serving.

We did not observe why it stopped resolving, we make no claim that it was removed, suspended or taken down, and a hostname that stops resolving can be re-pointed at any time — one in this corpus already has.

The 8 rows this study cannot speak for

A study that only reports the checks that worked is not a study. On 6 October 2026 our own fetch failed for these hostnames — repeatedly, across several egress paths — so we learned nothing new about any of them, none of their dates moved, and each keeps the finding it already had. A failed check of ours is a fact about our own connection, never about the hostname.

• featherstoneoutdoorhq.shop (Featherstone Outdoor) — not re-checked — our own check failed on 6 October 2026. Its finding of “live, HTTP 200”, dated 29 September 2026, stands unchanged.
• studioadornhq.shop (Studio Adorn) — not re-checked — our own check failed on 6 October 2026. Its finding of “resolves but not serving — HTTP 502”, dated 29 September 2026, stands unchanged.
• brchhome.shop (Branch Furniture) — not re-checked — our own check failed on 6 October 2026. Its finding of “live, HTTP 200”, dated 29 September 2026, stands unchanged.
• noguhq.shop (NOGU) — not re-checked — our own check failed on 6 October 2026. Its finding of “live, HTTP 200”, dated 22 September 2026, stands unchanged.
• luxebitesstore.shop (Luxe Bites) — not re-checked — our own check failed on 6 October 2026. Its finding of “resolves but not serving — HTTP 502”, dated 29 September 2026, stands unchanged.
• truetreasuresinchome.shop (True Treasures Inc) — not re-checked — our own check failed on 6 October 2026. Its finding of “resolves but not serving — HTTP 502”, dated 29 September 2026, stands unchanged.
• muhouse.shop (MUSASHI) — not re-checked — our own check failed on 6 October 2026. Its finding of “live, HTTP 200”, dated 29 September 2026, stands unchanged.
• ekstershop.com (Ekster) — not re-checked — our own check failed on 6 October 2026. Its finding of “live, HTTP 200”, dated 13 August 2026, stands unchanged.

How every observation in this study was taken

• Every check is our own fetch with the cache fully bypassed, and the HTTP status actually read back is what gets recorded — never a cached page, never a third-party score, never an inference from one.
• “Does not resolve” is only written after at least two independent DNS lookups return no answer. One failed lookup is not a finding.
• A check that fails at OUR OWN egress teaches us nothing about the hostname. The row keeps its earlier finding and its earlier date and is annotated as not re-checked — silently date-stamping an incomplete check is the single failure these sweeps exist to prevent.
• A date advances only on a check that completed. That is why the study counts the rows we could not re-check separately, in full view, instead of quietly carrying them as though they had been.
• A dated finding is never deleted and no row is ever removed from the index. When a state changes, the earlier observation stays with its own date; when what a hostname serves changes, the earlier evidence class stays too.
• Three strings describe a state and nothing else may: “live, HTTP 200”, “does not resolve”, and “resolves but not serving — HTTP nnn”. They are the same strings the index, the incident pages and the machine-readable markup all render.

What a decay study does not establish

This list is the important half of the page. What a research note declines to say is the part you cannot check for yourself:

• Not that any hostname was removed, suspended, seized or taken down. A registry status code is a fact about a domain's record, not an account of who did what: on 22 September 2026, 29 September 2026 and 6 October 2026 we read those records back for the hostnames that do not resolve, every one of those rows carries that reading as its own dated observation, and none of it tells us who asked for it, why, or whether anyone filed anything at all. We claim no part in any of it.
• Not why any state changed, in either direction. We observed that it changed and on what date. We did not observe why it stopped answering, and we did not observe why it answered again.
• Not that a filing, a complaint or anything else caused a change. We do not know what was filed against these addresses, by whom, or whether anything was.
• Not what any of these hostnames is serving today. Every figure here is counted from a dated check; re-check before relying on any of it.
• Nothing about who registered anything. No registrant identity, no intent, no criminality — and no registrar, hosting provider, network, name server or IP for any hostname on the list.
• Not a prediction. A rate of change measured over one window on one corpus is a description of that window, not a forecast for yours.

We describe what each page serves; we make no assertion about any registrant’s intent or criminality, and nothing here is legal advice.

What is out there under your own name, today

Every row counted on this page belongs to somebody's brand. If you want the same question asked about yours, this is the one-time version: we generate the lookalike names from your own domain, resolve every one, fetch everything that answers, and report only what we confirm resolving — dated, with the readings behind each row and a takedown request drafted for you to send.

Or find out where your own brand stands — free

Before any of that: run the free exposure preview on your own domain — a live lookup that returns an exposure score, a plain-English verdict and the real lookalike candidates we find, each with the state we observed on it. No email, no card, no account, and if we find nothing live today that is exactly what it says. Or check whether your brand is already on the index, hostname by hostname.

The records this study was counted from

• The index itself — 60 documented hostnames across 56 brands, grouped by the brand each one reproduces, with the state we observed and the date beside every row.
• The .shop clone kit teardown — the build most of these hostnames were running when we documented them, one production line pointed at many brands at once.
• A free scanner's reading against our own, on the same day — why a score and a dated artefact record answer different questions.
• Did my takedown actually work? — reading registry status codes, and why clientTransferProhibited alone is not enforcement. It is also why nothing on this page calls a quiet hostname a takedown.
• Who we are, how each copy is verified, and what we refuse to promise.

The short version

How many of the 60 documented hostnames were live at the last check?

31 were “live, HTTP 200” when we last checked them, 19 did not resolve, 2 resolved but did not serve, and 8 could not be re-checked because our own fetch failed — so those keep their earlier finding and their earlier date. Those figures are counted on 6 October 2026 and are not a claim about what any address is doing today.

How many changed state, and in which direction?

Since 31 July 2026 — the earliest dated re-check on this record, 67 days before our 6 October 2026 sweep — 20 of the 60 hostnames recorded a state different from the observation before it: 19 moved away from “live, HTTP 200” and 1 moved back to it. Every one of those observations stays on the record with its own date, and none of them is written as the end of anything.

What does it mean when one of these hostnames stops resolving?

It means one thing: on the date we checked it, two independent DNS lookups returned no answer. We never write it as a removal, a suspension or a takedown. Where we have also read the registry's own record back — on 22 September 2026, 29 September 2026 and 6 October 2026, for the hostnames that do not resolve — that reading is recorded separately, with its own date, on the row it belongs to; it does not change the state we observed, and it does not tell us who asked for it or why. We record only that it stopped resolving, on the date we checked it, and a hostname that stops resolving can be re-pointed at any time.

Has a hostname on this list ever come back?

Yes. noguhq.shop was observed “does not resolve” on 31 July 2026 and “live, HTTP 200” on 2 September 2026, 33 days later, serving the same clone-kit build. Both observations stay on the record with their own dates. We attempted a further check of it on 6 October 2026 and our own fetch failed, so that pair of readings is the most recent record we hold for it and we state nothing about what it is serving now. We did not observe why it stopped resolving, we make no claim that it was removed, suspended or taken down, and a hostname that stops resolving can be re-pointed at any time — one in this corpus already has.

Why do you publish the rows you could not check?

8 rows are annotated “not re-checked” because our own fetch failed, and each keeps the finding and the date it already had. A failed check of ours is a fact about our own egress, never about the hostname, and it may never advance a date. Counting them in plain sight is the only honest way to report a sweep.

Can I buy this as a file, or have it re-run for my brand?

The whole index is free to read, hostname by hostname, with every artefact and every earlier observation. A weekly re-check of one brand you name is $149/month: the same cache-bypassed check every Tuesday, emailed with what each hostname answered and the date. It is observations, dated — not continuous monitoring, not detection, and we do not file takedowns or contact anyone on that plan.