Custom Scan

Custom Scan finds websites by the files they serve rather than by the technology they run. You type a file name, an asset path, or the host an asset loads from, and it returns every site carrying that footprint.

Why it exists

Tech Lookup works from a catalogue of named technologies. Someone has to write a detector for a technology before it can appear there, and that is the right trade almost every time: the catalogue is curated, it knows what things are called, and it can tell you market share and country splits.

But a catalogue can only contain what has been catalogued. These are all real questions it cannot answer:

• Who runs one specific version of a library, rather than the library
• Who loads assets from one specific third-party host
• Who has a plugin or theme installed that nobody wrote a detector for
• Who is running something too new to have been catalogued yet

Custom Scan searches the raw asset index underneath the catalogue. Nothing has to be named or classified first. If a site loads the file, you can find the site.

There is no list to pick from, by design

Tech Lookup gives you a picker because there are around 55,000 named technologies and browsing them is useful. Custom Scan does not, because the index holds tens of millions of distinct file names and the overwhelming majority of them are one-off build hashes belonging to a single website. A dropdown would be unusable and a browse page would be noise.

So you type the footprint. If you are not sure what to type, Finding the right footprint shows you how to get one from a site you already know.

What it costs

Searching is free and unlimited. You get a live count, ten sample sites and optional filters without spending anything, so you can try several footprints and keep the one that works.

Downloading the results costs one credit, flat, whether the footprint matches two hundred sites or two million.

Which tool should I use?

Most lead lists should start with Tech Lookup. Custom Scan is what you reach for when it comes up short.

Every asset is indexed three ways, and the mode you pick decides what "matches" means. Pick the wrong one and you will get a number that is technically correct and useless.

File name

An exact match on the file itself, wherever it is served from.

woocommerce.css
swiper.js
jquery-1.12.4.min.js

This is the fastest mode and the right default. Use it when the file has a distinctive name, and especially when the name carries a version number.

A file name is only the last segment of the path. That matters more than it sounds: some CDNs put the recognisable name in the middle of a URL, like static.cloudflareinsights.com/beacon.min.js/v833cc..., where the file name is the hash at the end and beacon.min.js is a directory. If an exact name search returns far less than you expect, try it as a path instead.

File path

Matches a folder anywhere in an asset's path, so one query covers every file a plugin, theme or framework ships.

/wp-content/plugins/elementor/
/_astro/
/node_modules/

You do not have to get the slashes right. wp-content/plugins/elementor and a whole pasted URL both reduce to the same thing. The slashes are then enforced on both ends, which is what stops a path from matching the middle of some other word.

Path searches scan wider than the other two modes, so they take a couple of seconds rather than a fraction of one. That is the cost of the flexibility.

Asset host

An exact match on the hostname an asset loads from.

static.parastorage.com
cdn.shopify.com
browser.sentry-cdn.com

This is how you find a SaaS platform, a CDN, or a third-party script vendor: the sites do not host the file, they load it from somewhere, and that somewhere is the signal.

www. is not stripped here. For a website domain, www.example.com and example.com are the same site. For an asset host they are two different hosts serving different traffic, so folding them would silently merge two footprints. Enter the host exactly as it appears.

You can paste almost anything

Whatever you paste is reduced to the form the index actually holds, so you do not have to clean it up first. All of these work:

Case never matters. The index is stored lowercase and your query is folded to match, so Swiper.js and swiper.js are the same search.

The hard part of Custom Scan is not running the search, it is knowing what to type. Here is how to get a footprint you can trust.

Take it from a site you already know

The reliable method is to look at one site that definitely runs the thing you are hunting, and read what it loads.

1. Open a site you know runs it
2. Open your browser's developer tools and go to the Network tab
3. Reload the page and filter to JS or CSS
4. Look for a file, folder or host that belongs to the thing rather than to that particular site

Step 4 is the judgement call. You are looking for something the vendor controls and the site owner does not.

Good footprints are stable across every install:

• /wp-content/plugins/<plugin-slug>/: the folder is fixed by the plugin's own name
• cdn.vendor.com: the vendor's own host
• vendor-widget.min.js: a distinctively named file shipped by the vendor

Bad footprints vary from site to site and will find almost nothing:

• app.4f3a91.js: a build hash, unique to one deployment
• main.css, style.css, script.js: generic names shared by millions of unrelated sites
• Anything with the site's own domain in it

Try two or three and compare

Searching is free, so the practical method is to run several footprints for the same thing and look at the spread before you spend a credit on any of them.

All three of these find WordPress:

Sixteen times between the widest and the narrowest, and each is a true answer to the question it was asked. The first two are directories WordPress is built around, so they are close to the whole population. The third is a single optional script that most themes never load.

If two footprints for the same thing return wildly different numbers, the larger one is usually the better search. If they agree closely, you can be fairly confident you have found something stable.

Start from the examples

The search page carries three worked examples for each mode. They are there to be clicked, and they are chosen to show what a good footprint looks like in each of the three shapes.

When a search returns nothing

Nothing is a real, checked answer, not an error. The usual causes, in order of likelihood:

• A typo. Check the spelling first.
• Too specific. A file name with a version or hash in it may genuinely exist on only a handful of sites. Try the folder it sits in instead.
• Wrong mode. A name that is really a directory segment will not match as a file name. Try it as a path.
• Not JavaScript or CSS. The index covers the JS and CSS a site serves. Images, fonts, HTML and server-side files are not in it.

A search gives you a count, ten sample sites, and an honest note about how much of the match set your plan would actually deliver. All of it is free.

A footprint count is a floor, not a population

This is the single most important thing to understand before you export.

Always: a site serving woocommerce.css runs WooCommerce.

Not always: a site running WooCommerce serves woocommerce.css.

The implication only runs one way. Themes rename files, optimisation plugins concatenate them, and CDNs rewrite paths, so one file only ever finds the sites still serving it under that name.

What this means in practice: treat the count as the part of the population you can prove, not as a market-share figure. If you need "how many sites run X" as a number you would put in a deck, that is a Tech Lookup question. If you need "give me the sites I can positively identify by this signal", that is what Custom Scan is for.

Filters

Filters are optional and collapsed by default, because the common case is a bare footprint search. Open them to narrow by:

• Country: up to five
• TLD: up to five

Filters apply when you press Search, so there is no separate Apply step, and they carry through to the export. The count you see is the count you get.

An empty result with filters on means something different from an empty result without them, and the page says which: "nothing serves this file at all" versus "sites serve it, but none in the countries you picked".

Sample websites

Ten rows, with domain, country, TLD and asset type. They are a sample of the match set, not the top ten by anything, because there is no ranking here. Use them to sanity-check that the footprint found what you meant it to find before you spend a credit.

The reach warning

When a footprint matches more than your plan can export, the page says so before you buy:

This is broader than one report can carry. Your plan exports 100,000 rows, so you would receive 5.5% of these matches for the same 1 credit.

This is not a block. A deliberate "the first 100,000 sites loading jQuery" export is a legitimate thing to want. It is there because the credit costs the same either way, and a narrower footprint usually tells you more for the same money.

When something is unavailable

If a query fails, the page says it could not read the answer. It will never show you a zero it did not actually verify. A count of nothing and a count we could not get are different states, and they look different.

One credit, whatever the size

An export costs a single credit whether the footprint matches two hundred sites or two million. There is no per-domain charge, and no separate bulk credit.

Re-running the same footprint in the same billing period does not charge you again. That is keyed on the search mode and the normalised footprint, and filters are deliberately not part of the key, so you can pull woocommerce.css unfiltered, then again narrowed to Germany, then again narrowed to .de, all for the one credit you already spent.

How many rows you get

Your plan sets the ceiling:

If the footprint matches more than that, you get the ceiling and the page tells you the share beforehand.

What is in the file

A CSV with ten columns:

Company data lands on roughly one in five rows. Measured across four real exports it ranged from 12% to 22% depending on the footprint. Do not read a mostly-empty company column as a broken export. It is the coverage of the underlying company data against an unranked slice of the web.

This is lower than a Tech Lookup export, and the reason is structural rather than a defect: Tech Lookup ranks by popularity before it enriches, and popular sites are far more likely to have a company record. Custom Scan has no ranking, so it takes an ordinary slice of the match set and gets the ordinary rate.

Where the file goes

Every export lands in My Reports, saved with the search mode and footprint that produced it, alongside your Tech Lookup and Keyword Scan reports. You can re-download it as many times as you like at no extra cost.

If something goes wrong

A failed export does not consume a credit. If a report fails after the credit was taken, it is refunded automatically.

Exposure lives at the level of the exact file and the exact host. That is the level Custom Scan searches, which makes it a different instrument from a technology catalogue for this kind of work.

Scope, first

The index holds the JavaScript and CSS a site serves. So it maps client-side exposure and third-party inclusion. It does not see server-side files, configuration, response headers, or anything a page never links to. It is not a scanner and it does not touch the target. Everything is answered from a crawl we already have.

Counts are a floor rather than a census, for the reasons in Reading your results. Read a result as "at least this many, positively identified", never as "exactly this many".

Enumerate the affected build, not the library

Version numbers live in file names, which is what lets you scope an advisory to the build it actually names.

jquery-1.12.4.min.js     377,673 sites
jquery-1.11.3.min.js     232,719 sites

A catalogue would tell you how many sites run jQuery, which is a much larger number and not the question. Where a project ships versioned file names, this is the most precise instrument you have.

If the version is in the path rather than the file name, as in /ajax/libs/foo/1.2.3/, use a path search instead.

Measure supply-chain blast radius

When a third-party host is compromised or quietly changes hands, every site loading from it inherits the problem. One host search sizes the population.

polyfill.io          16,016 sites
cdn.polyfill.io       9,866 sites

polyfill.io was the subject of a widely reported 2024 supply-chain incident, and as of the current crawl those sites still have it on the page. That is the shape of the query worth keeping: after any vendor incident, the host is the search.

Map third-party dependency surface

Useful before you need it, so you already know the scale when something happens.

cdnjs.cloudflare.com   5,833,844 sites
cdn.jsdelivr.net       4,363,936 sites
unpkg.com              1,356,171 sites

Size plugin exposure

A plugin ships its assets from the same folder on every install, so one path search gives you the affected population for an advisory against it.

/wp-content/plugins/revslider/   2,248,932 sites

Check the footprint before you trust a zero. Some plugins ship no front-end JavaScript or CSS at all, so their folder never appears in the index and a search returns nothing. That is a gap in what the index can see, not evidence the plugin is rare. If a plugin you know is widely installed returns zero, it is almost certainly one of these. Verify against a site you know has it.

A practical workflow

1. Get the exact file, path or host from an affected installation
2. Search it, free, and check the sample rows look like what you expect
3. Try one broader footprint for the same thing and compare. If they differ a lot, the wider one is closer to the real population
4. Add country or TLD filters if you are scoping to a jurisdiction
5. Export once; re-pull with different filters in the same period at no extra cost

Responsible use

The output is a list of domains that publicly serve a given file, derived from an ordinary web crawl. It is the same information anyone gets by viewing source. Use it for research, notification and defensive inventory. StackScan's Terms of Service apply.