BuiltWith vs urlscan: Stack Hints vs Observed Page Behavior

BuiltWith and urlscan.io are often used in the same web-research workflow because both can tell you something technical about a public website.

But they observe the web in very different ways.

A useful modern distinction is:

BuiltWith is strongest when you need a structured technology profile — including current and historical technology detections and changes over time.

urlscan is strongest when you need a browser-observation record of what a particular URL did during a particular scan — requests, responses, page metadata, redirects, screenshot, DOM and related artifacts.

That distinction matters.

A technology profile answers:

What technologies does this website appear to use?

A browser scan answers:

What happened when this URL was loaded in this scanning environment at this time?

Those are not interchangeable claims.

---

The short answer

Use BuiltWith first when your question is:

• What technology stack is associated with this site?
• Which platforms, analytics tools, frameworks or vendors appear to be present?
• Has the site's technology profile changed over time?
• Which domains share certain technology relationships?

Use urlscan.io first when your question is:

• What requests does this page make when loaded?
• Which external domains appear?
• Where does the page redirect?
• What did the rendered page look like in this scan?
• Which DOM, response or network artifacts were observed?
• Are there previous scans of this URL/domain?

Use both when you want to compare:

declared/detected technology posture

with:

observed page behavior

---

Comparison at a glance

The tools overlap at the edges.

Their primary evidence types are different.

---

Start by separating profile from behavior

This is the single most useful concept in the comparison.

Suppose a website is associated with:

WordPress
Cloudflare
Google Analytics
Stripe

That is a technology profile.

Now suppose a browser scan observes:

GET /
302 /login
request to cdn.example.net
request to analytics.example.com
POST to api.example.com
JavaScript bundle
cookie set

That is a behavioral observation.

The two descriptions can be related.

But one does not replace the other.

A technology can be present without appearing in one scan.

A request can occur without proving that the associated vendor is a core part of the site's architecture.

---

BuiltWith: structured technology profiling

BuiltWith's current Domain API provides current and historical technology information for websites, plus additional metadata where available.

Its broader API ecosystem also includes products for:

• technology changes;
• relationships between websites;
• redirects;
• tags and related attributes;
• large-scale datasets;
• live technology detections.

This is important because BuiltWith should no longer be described simply as:

a tool that guesses a CMS.

Its product model is broader.

The useful analytical idea is still the same:

BuiltWith gives you a structured technology-oriented view of a website.

---

What BuiltWith is good at

BuiltWith is especially useful when you need:

• a quick technology inventory;
• current/historical technology detections;
• vendor/platform clues;
• evidence of technology additions/removals;
• broad stack comparison across websites;
• lead/market/competitive technology research;
• a structured machine-readable technology profile.

Typical questions include:

Does this site appear to use Shopify?

Was WordPress detected historically?

When did a technology appear or disappear?

Which analytics or advertising technologies are associated with the site?

Which websites share a technology relationship?

These are profile-oriented questions.

---

BuiltWith history is a major differentiator

BuiltWith's current API explicitly advertises current and historical technology information.

Its Change API also exposes technology additions and removals over time.

That makes it useful for timeline questions.

Example:

2024 — WordPress detected
2025 — Cloudflare added
2026 — Shopify detected

This does not automatically prove a complete migration timeline.

But it can create a strong hypothesis:

the public technology profile changed materially between these periods.

Then you corroborate through:

• archived pages;
• current response analysis;
• urlscan results;
• direct public observations.

---

A BuiltWith detection is a technology observation, not architectural truth

Suppose BuiltWith reports:

React
Cloudflare
Google Tag Manager

A careful statement is:

BuiltWith reports technologies/signals associated with React, Cloudflare and Google Tag Manager for this domain.

Do not jump to:

The entire application is built in React and hosted by Cloudflare.

Why?

Because visible technologies can represent different layers:

• frontend library;
• CDN;
• analytics;
• tag manager;
• payment widget;
• embedded support product;
• historical artifact;
• third-party integration.

The tool gives you technology evidence.

You still need to understand the layer.

---

Technology detection can be historical or current

BuiltWith's usefulness depends heavily on time.

A technology seen historically may no longer be present.

A current detection may describe:

• the main site;
• one route;
• an embedded third party;
• a recently changed architecture.

Always keep:

technology
time/state
source

together.

Avoid flat statements such as:

The company uses WordPress.

Prefer:

BuiltWith reports WordPress in the site's historical technology profile during period X.

or:

BuiltWith currently reports technology X for the domain at the time checked.

---

BuiltWith relationship data is useful but easy to overread

BuiltWith also exposes website relationship data.

This can surface shared attributes between websites.

That can be useful for:

• vendor relationships;
• infrastructure/technology overlap;
• ecosystem discovery.

But shared technology is usually weak evidence of common ownership.

Example:

site-a.com
site-b.com
→ both use Google Analytics

That does not prove:

same operator.

Even a more specific shared identifier may require context.

Treat relationship data as:

a pivot candidate

until corroborated.

---

urlscan.io: browser-observation records

urlscan.io works differently.

Its API allows users to:

• submit URLs for scanning;
• retrieve results;
• retrieve screenshots;
• retrieve DOM snapshots;
• search existing scans by attributes such as domains, IPs, ASNs and hashes.

A scan represents what urlscan observed when it loaded a URL in its scanning environment.

That makes the unit of evidence:

this scan, at this time, under this scan configuration

rather than:

this domain's overall technology profile.

---

What a urlscan result can contain

Current urlscan result data can include information about:

• requested URL;
• final page;
• redirects;
• page status;
• network requests;
• response metadata;
• domains;
• IP addresses;
• TLS/certificate context;
• cookies;
• JavaScript/resources;
• page metadata;
• screenshot;
• DOM snapshot;
• derived statistics and labels.

This makes urlscan particularly valuable when the page's actual observed loading behavior matters.

---

urlscan is stronger when relationships emerge during page load

Suppose a page loads resources from:

cdn.vendor-a.com
analytics.vendor-b.com
auth.vendor-c.com
api.example.net

urlscan can help you observe that network behavior.

The strong statement is:

During scan X, the page requested resources from domains A, B and C.

The weak statement is:

The company owns A, B and C.

Network dependency and organizational ownership are different things.

This distinction is essential.

---

Existing scan vs new scan is an important operational choice

urlscan supports two fundamentally different workflows:

Search existing scans

You inspect observations that already exist.

This can be relatively low-interaction from your perspective.

Submit a new scan

You ask urlscan to load the target URL.

That creates a new browser visit from urlscan's infrastructure.

This is a meaningful operational difference.

Before submitting a scan, ask:

• Do I actually need a new observation?
• Does a recent scan already exist?
• Is the target sensitive?
• Could a scan reveal investigative interest?
• Which visibility mode is appropriate?

Do not submit automatically just because the button exists.

---

Scan visibility is part of the methodology

urlscan currently supports three visibility modes:

• public
• unlisted
• private

These modes matter.

Public

The scan can be visible on the front page and in public search/results.

Use this only when public visibility is appropriate.

Unlisted

The scan is hidden from normal public pages/search but can still be visible to vetted security researchers and companies using urlscan Pro.

That means:

unlisted is not the same as private.

This distinction is easy to miss.

Private

The scan is only visible to the submitting user, unless the scan ID is shared, and is subject to retention/deletion rules.

If the URL contains sensitive information, private handling may be required.

---

Never submit secrets inside URLs

A URL can contain:

• session tokens;
• password-reset tokens;
• private document IDs;
• API keys;
• customer identifiers;
• invitation links.

A scan service will load the submitted URL.

Before submission, inspect the full URL.

Do not send secrets to a third-party scanner.

If the research question can be answered from:

• existing scans;
• public homepage;
• sanitized URL;

prefer the least sensitive option.

---

urlscan can preserve a useful scan-specific visual record

The screenshot and DOM snapshot are analytically valuable because they capture a representation of the page during that scan.

That can help answer:

• Was a login page rendered?
• Did the page display a brand?
• Did the DOM include a particular element?
• Did the page redirect before rendering?
• Was a suspicious resource loaded?

But the scan is not universal.

The result may differ because of:

• geography;
• timing;
• cookies;
• user agent;
• target behavior;
• bot detection;
• A/B testing;
• authenticated state;
• JavaScript timing.

Write:

The urlscan observation rendered X under scan Y.

Not:

Every visitor sees X.

---

Historical urlscan searches add a time dimension

urlscan's search capabilities can query historical scans.

This is useful because browser behavior changes.

You may compare:

scan 2025
scan 2026

and observe:

• new external domains;
• changed redirect path;
• different page title;
• different certificate;
• changed script set;
• new screenshot;
• different final URL.

This creates a browser-observation timeline.

That is different from BuiltWith's technology-change timeline.

The two can complement each other.

---

BuiltWith history and urlscan history are not the same history

This deserves explicit separation.

BuiltWith historical evidence

Answers:

Which technology signals were associated with the site over time?

urlscan historical evidence

Answers:

What did individual page scans observe over time?

Example:

BuiltWith:

2025 — WordPress detected
2026 — Next.js detected

urlscan:

2025 scan — wp-content assets requested
2026 scan — _next/static assets requested

Together, the evidence becomes more persuasive.

But they remain separate sources.

---

One page scan may not represent the whole domain

Suppose you scan:

https://example.com/

The homepage may not expose:

• checkout stack;
• authenticated application;
• support portal;
• blog CMS;
• marketing subdomain.

Therefore:

urlscan did not observe technology X on homepage scan Y

does not prove:

the domain does not use technology X anywhere.

This is a major difference from domain-oriented profiling products.

The unit of analysis matters.

---

BuiltWith domain profiles can also hide route-specific behavior

The reverse limitation exists too.

A domain-level profile can summarize technologies across observed site signals.

It may not tell you:

• exactly which request triggered a third-party resource;
• the order of redirects;
• the DOM state during one page load;
• the precise response associated with one URL.

If the question is behavioral, move to a behavioral tool.

---

Worked example 1 — suspected technology migration

Question:

Did example.com migrate from WordPress to a modern JavaScript framework?

BuiltWith

Historical profile:

2024 — WordPress
2026 — Next.js

This creates a strong technology-change hypothesis.

urlscan historical scans

Older scan:

/wp-content/
/wp-includes/

Current scan:

/_next/static/

Now you have two different evidence layers.

Archive corroboration

Wayback captures show the old and new page structures.

Calibrated conclusion

BuiltWith's historical technology profile and independent browser/archive observations are consistent with a migration from a WordPress-based public frontend to a Next.js-based frontend between the observed periods.

Avoid:

The company's backend migrated from PHP to Node.js.

The public evidence may not support that.

---

Worked example 2 — external dependency investigation

Question:

Which third parties does this login page contact?

BuiltWith can tell you about technologies associated with the site.

That may include:

• analytics;
• identity providers;
• CDN technologies.

But the direct question is behavioral.

Use urlscan.

A scan may show requests to:

idp.example.net
analytics.vendor.com
cdn.vendor.com

Your conclusion should be:

During the scan, the login page requested resources from these domains.

Then classify those domains by role.

Do not assume they are all data processors or corporate partners without further evidence.

---

Worked example 3 — competitive technology research

Question:

Which ecommerce technology do 500 public websites appear to use?

This is a BuiltWith-style problem.

You need:

• structured technology classification;
• bulk comparison;
• technology history;
• scalable profiling.

Submitting 500 individual browser scans may be unnecessary and operationally noisier.

urlscan would become useful only for:

• ambiguous cases;
• behavior verification;
• sample validation;
• specific page-level questions.

The broader method should match the dataset problem.

---

Worked example 4 — phishing page

Question:

What does this suspicious page do when loaded?

urlscan is likely the more useful first lens.

You may need:

• redirect path;
• requested resources;
• screenshot;
• DOM;
• response details;
• related domains.

BuiltWith can still add:

• stack hints;
• provider/vendor context;
• historical technology clues.

But page behavior is the core question.

---

Worked example 5 — no urlscan result

You search urlscan and find no historical scan.

That does not mean:

the site never existed.

It means:

no matching scan was found under the search conditions and available dataset.

You may then decide whether a new scan is appropriate.

Always separate:

not observed

from:

did not exist

---

Worked example 6 — BuiltWith reports a vendor, urlscan does not observe it

This can happen.

Possible explanations include:

• vendor loaded only on another route;
• technology detection based on historical data;
• vendor conditionally loaded;
• cookie-consent state prevented loading;
• geo-dependent content;
• BuiltWith detection is stale;
• urlscan scan did not trigger the feature.

Do not call the sources contradictory immediately.

Ask whether they observed:

• the same page;
• at the same time;
• under comparable conditions.

---

Page behavior is time-sensitive

urlscan observations are particularly time-bound.

A page can change between scans because of:

• deployment;
• campaign rotation;
• malicious infrastructure takedown;
• CDN changes;
• consent state;
• target evasion;
• redirects;
• DNS changes.

Always record the scan UUID and time.

Do not copy only the extracted domain list.

The scan ID is part of provenance.

---

Technology profiles are time-sensitive too

BuiltWith profiles can also change.

The platform's Change API explicitly exists to expose technology additions and removals.

For important findings, preserve:

• lookup date;
• technology name/category;
• first/last observed context where available;
• current vs historical state.

Avoid turning a technology profile into a timeless company attribute.

---

URL submission can create evidence — and exposure

This is an important difference from BuiltWith.

A normal BuiltWith lookup is a query against BuiltWith's technology dataset.

A new urlscan submission asks a third-party scanner to visit a URL.

That can:

• create new scan data;
• contact the target;
• generate logs on the target;
• expose the URL according to visibility settings.

So the two tools have different operational footprints.

Search existing scans first when that is sufficient.

---

Public scanning can accidentally publish research targets

If you submit:

https://secret.example.com/invite?token=ABC

as a public scan, you have potentially turned a sensitive URL into public scan metadata.

That can be worse than the original investigative problem.

Before every submission:

1. inspect URL;
2. remove unnecessary query strings where possible;
3. choose visibility deliberately;
4. understand retention/access;
5. avoid submission entirely if the artifact is sensitive.

This is not just privacy hygiene.

It is part of responsible OSINT method.

---

Evidence independence matters

Suppose BuiltWith says:

Google Analytics

and urlscan observes a request to:

www.google-analytics.com

That is useful corroboration.

The observations are different:

• BuiltWith technology classification;
• urlscan network request.

Now suppose two different technology databases both report Google Analytics.

That may be less independent.

Different evidence layers create stronger corroboration than repeated labels.

---

A practical decision matrix

This table indicates the strongest first lens.

The second tool may still improve the answer.

---

A repeatable combined workflow

If the question needs both profile and behavior:

1. Define the page/domain question

Example:

Has this public web application changed stack, and what third-party behavior is visible now?

2. Query BuiltWith

Record:

• current technologies;
• historical technologies;
• detected changes;
• lookup time.

3. Search existing urlscan results

Before creating a new scan, inspect whether a recent suitable scan already exists.

4. Decide whether a new scan is justified

If yes:

• sanitize URL;
• choose visibility;
• record scan configuration/UUID.

5. Inspect the scan

Focus on:

• final page;
• redirects;
• requests;
• domains/IPs;
• screenshot;
• DOM;
• relevant responses.

6. Compare the evidence layers

Example:

BuiltWith: Stripe detected
urlscan: request to js.stripe.com observed

This is stronger than either alone.

7. Preserve time

Keep the BuiltWith lookup date and urlscan scan time separate.

8. Corroborate high-value claims

Use:

• live response inspection;
• archive history;
• DNS;
• official vendor/site documentation.

9. Stop when the question is answered

Do not expand every third-party request into a new investigation.

---

How to write the conclusion

Bad:

BuiltWith and urlscan prove the site runs on Next.js and sends data to Vendor X.

Better:

BuiltWith reported Next.js in the site's technology profile at the time checked, while urlscan scan X observed _next/static resources and requests to Vendor X during that page load.

If data transfer significance matters, go further:

The scan demonstrates a network request to Vendor X, but the purpose and content of that request require separate analysis.

This preserves the boundary between:

• observation;
• inference;
• conclusion.

---

Common mistakes

Mistake 1 — Treating BuiltWith as only a CMS detector

Its current API includes current/historical tech, changes and other datasets.

Mistake 2 — Treating urlscan as a general "technology detector"

Its strongest evidence is scan-specific browser behavior.

Mistake 3 — Treating one urlscan scan as the whole domain

A scan represents one URL under one set of conditions.

Mistake 4 — Treating BuiltWith historical tech as current truth

Keep technology state/time explicit.

Mistake 5 — Submitting a URL when an existing scan is enough

Avoid unnecessary interaction.

Mistake 6 — Using unlisted as if it means private

urlscan explicitly distinguishes them.

Mistake 7 — Submitting URLs containing secrets

Inspect query strings and tokens first.

Mistake 8 — Treating a third-party request as ownership

A dependency is not a corporate relationship.

Mistake 9 — Calling source disagreement an error too quickly

The tools may observe different routes, times and layers.

Mistake 10 — Ignoring scan UUID/time

Provenance belongs to the finding.

Mistake 11 — Treating vendor detection as full architecture

Public stack signals do not reveal hidden backend systems automatically.

Mistake 12 — Expanding every observed domain

Only pivot when the original research question justifies it.

---

Which tool should you open first?

Use BuiltWith first when the uncertainty is:

What technologies are associated with this website, now or historically?

Use urlscan first when the uncertainty is:

What happened when this URL was loaded in a browser-like scanning environment?

Use both when the uncertainty is:

Do the structured stack profile and observed page behavior support the same technical story?

That is the cleanest distinction.

---

Related OSINT.dev tools

BuiltWith

Best for:

• current technology profiles;
• historical technology profiles;
• technology changes;
• structured vendor/platform discovery.

urlscan.io

Best for:

• browser-observed requests;
• redirects;
• screenshots;
• DOM;
• scan-specific page metadata;
• historical scans.

Tech Stack Snapshot

OSINT.dev's native Tech Stack Snapshot provides a deliberately narrower, explainable first-party fingerprint of one public HTTP response.

It is useful when you want:

• a quick native observation;
• conservative technology signals;
• confidence labels;
• no browser execution.

Use BuiltWith when you need broader/historical profiling.

Use urlscan when browser behavior matters.

Redirect Chain & Response Inspector

Use OSINT.dev's native redirect runner when the question is specifically:

What HTTP redirect chain occurs?

That keeps a focused technical question from being buried inside a larger browser scan.

---

The core principle

BuiltWith and urlscan describe two different views of the public web.

BuiltWith — what technologies does the site appear to use, including historically?

urlscan — what did this particular page load do during this scan?

A strong investigation keeps those meanings separate.

Then it combines them when useful:

profile → observed behavior → time → corroboration

The goal is not to collect more technical labels.

The goal is to know whether a finding came from:

• a technology dataset;
• a live/browser observation;
• a historical scan;
• a direct response;
• an inference.

Once that distinction is preserved, BuiltWith and urlscan stop looking like competing tools.

They become complementary evidence layers.

---

References

Official/current product documentation used in this comparison:

• BuiltWith API — current and historical technology information
  https://api.builtwith.com/

• BuiltWith Domain API
  https://api.builtwith.com/domain-api

• BuiltWith Change API
  https://api.builtwith.com/change-api

• BuiltWith Relationships API
  https://api.builtwith.com/relationships-api

• urlscan.io — API Documentation
  https://urlscan.io/docs/api/

• urlscan.io — Quickstart Guide
  https://docs.urlscan.io/guides/quickstart

• urlscan.io — Scanning API
  https://docs.urlscan.io/apis/urlscan-openapi/scanning

• urlscan.io — Scan Visibility Levels
  https://docs.urlscan.io/pages/visibility

• urlscan.io — Result API Reference
  https://urlscan.io/docs/result/