The dormant web counter that could have owned your site

A few weeks ago we picked up a domain at auction. The site behind it had been offline since 2018, but the domain itself carried real backlink history: over a hundred live referring sites, a couple of them with Ahrefs domain ratings north of 90, a scatter of university faculty pages, small-business homepages, and one old public-service site in South Africa.

None of that surprised us. What did surprise us was why they were still linking. The site used to run a free web counter, a small script embed that visitors would drop into their own page HTML to display a live view count. Fifteen years later, those embeds are still on the page. They still fire on every visit. They just fetch nothing, because the endpoint has been dead for seven years.

Which means the moment we bought the domain, we controlled what those hundreds of visitor browsers loaded. That is the story.

How the counter worked, in plain English

Free web counters were everywhere in the early 2000s. You would sign up on the counter provider’s site, pick a username, and paste a snippet like this into your own site’s HTML:

<a href="https://provider.example/" rel="noopener">
  <script src="https://provider.example/pphlogger.js.php?id=jsmith"></script>
  <noscript>
    <img src="https://provider.example/pphlogger.php?id=jsmith&showme=y">
  </noscript>
</a>

Every visit to your page ran two things. It fired a request to the image URL, which incremented your counter and returned an image showing the current total. And it loaded the JavaScript file, which used document.write to inject an image tag into your page.

That second part is the interesting one. The JavaScript file executes on your visitor’s browser. It has the same permissions as the rest of your page’s code. It can write anything into the DOM. It can call any URL. It can read your visitor’s cookies for your own site if you loaded it in-page without an iframe.

Whoever owns the counter provider’s domain controls that JavaScript file. In 2003, the original operator was serving up an image tag and nothing else. In 2026, the domain was for sale.

A dormant script is exactly the sort of thing a routine review catches and nothing else does. That is what our WordPress security services are for, and if something has already been exploited, our malware removal service picks it up from there.

What we could have done, if we were bad actors

We bought the domain to rebuild the tool as a modern free counter. But the same purchase could have gone very differently. Here is a short list of what a bad actor could have done from day one:

• Credit card skimmer. On any e-commerce site that still had the counter embedded, inject a Magecart-style script into the checkout page. Read the card number, CVV, and address, ship it to a domain the attacker owns.
• Credential harvester. On any login page or portal, add a fake password field or intercept the form submit before the browser posts.
• SEO poison. Inject links to a spam network on every page that ran the counter, cheaply weaponising a hundred university and small-business sites into a link farm.
• Redirect chain. If a visitor arrived from a search engine, bounce them through a click-fraud chain before the real page loaded.
• Cryptomining. Silently run a cryptominer in the visitor’s browser while they read the page. Small cost per visit, big cost when the counter fires on hundreds of pages every day.
• Malware dropper. Serve up an exploit kit targeting outdated browsers, or fingerprint the visitor and only attack the vulnerable ones.

None of these would have set off an alarm on the sites that embedded the counter. Their WordPress site, their Wix site, their static HTML, would look identical in the page source. The malicious code lives on our server, not theirs. Their content security policy (if they even had one) probably allowed us because we had been trusted since 2003.

This is not theoretical. It has already happened.

Dormant third-party dependencies are a common attack path. A few well-known examples:

• In 2018 the analytics library Feedify was compromised and used to skim payment data from a chain of e-commerce sites.
• In 2020 a compromised JavaScript CDN shipped skimmer code to hundreds of Magento sites via bundled extension updates, documented by Sansec.
• In 2023 Polyfill.io was bought by a Chinese CDN and turned into a mass-injection tool, hitting more than 100,000 sites overnight.

Each time the pattern was the same. A useful, trusted, third-party script. A change of ownership. New code shipped from the same URL. Users had no idea until researchers noticed.

Why this matters especially when a company shuts down

When a service goes dark, most site owners do not remove the embed. They notice the counter is not rendering, they might tut about it, and they leave the code in the page. It costs them nothing while the domain sits dormant.

It costs them everything the moment the domain changes hands. And domains change hands quietly. The counter provider’s DNS record does not blast out a notification when the WHOIS changes. The site inheriting the embed has no built-in way to know.

So the moment you notice a service has shut down, remove the code. Then the moment you inherit a site from a former agency or a departing colleague, audit what third-party code is running on the pages you own. It is the cheapest, highest-impact security work you will do in a quarter.

How to audit your own site in 20 minutes

You do not need a security team. You need a browser and a clear afternoon.

• Open your homepage in a fresh Chrome or Firefox window. Right-click, choose View Page Source. Search the raw HTML for <script src and <iframe. Every result is a third-party dependency you should recognise.
• Open DevTools (F12) and go to the Network tab. Reload the page. Sort by domain. Every domain you do not recognise is a candidate for removal.
• Search for “counter”, “widget”, “tracker”, “stats”, “hitcounter”, “webring”. These are all common names for embeds that were popular a decade or two ago and often still sit dormant.
• Check your WordPress functions.php, footer.php, or theme options. A depressing number of themes still hard-code a legacy embed.
• Look at your Cloudflare or Cloudflare-equivalent access logs. Look for outbound requests you do not recognise firing on every page load.

If you find something that fits the pattern (small utility, shut down years ago, embed still fires), remove the code, redeploy, and check your Content Security Policy blocks its domain going forward. Do not wait to see who buys the domain next.

What we did with the domain, since you are wondering

We rebuilt the counter. Same URLs, same query parameters, same image tag output. Every site still embedding the snippet now sees a live SVG counter again with no code change on their end.

Starting from zero would have been misleading, so we queried the Ahrefs API for every referring site, scanned the top 500 by traffic for the embed pattern, extracted the counter IDs still in the wild, and seeded each counter with the referring domain’s all-time Ahrefs traffic estimate. That is our best proxy for how many visits the counter would have accumulated if the endpoint had kept working. The seeded totals are visible on the counter itself; nothing is faked, and the source of the number is documented on the site.

We did this because it was the honest option. It is also the option that treats the small-business owner whose old about-us page still embeds the counter as someone worth respecting. Their counter did not get reset by a domain change. Their visitor traffic estimate is grounded in real data.

Where we can help

The audit is not just for old sites. If you inherited a WordPress site from another agency, run one before you make your first change. If your business changed hands, run one on the first day. If a supplier goes into administration, check whether they were serving code on your pages, and if so, block the domain the same afternoon.

The takeaway

You do not control the code you did not write. You control the code you choose to load. Every third-party script on your site is a trust decision, and trust decisions expire when the company you trusted stops existing.

If you learn one thing from this piece: the moment a service you rely on shuts down, remove the code. Do not wait for the domain to change hands. Do not assume it will stay parked. Do not trust that a security researcher will notice before an attacker does.

If you want a second pair of eyes on your site, that is what we do. And if you spot a dormant counter, tracker, or widget still fetching from a domain that should not exist any more, treat it like a fuse. Because that is exactly what it is.