What Is DataDome? How Bot Detection Works and Why Scrapers Get Blocked

A scraper works perfectly in testing.

Then you point it at a real website and get:

403 Forbidden.

Or a CAPTCHA.

Or the page loads in Chrome but returns something completely different from your script.

You change the IP address. It works for a few requests and gets blocked again.

This is the kind of problem DataDome is built to create for automated traffic.

The important thing to understand is that DataDome does not simply ask:

"Is this IP suspicious?"

Modern bot detection is much closer to:

"Does this IP, network connection, browser, device, request pattern and session all make sense together?"

That distinction explains why switching proxies sometimes helps, why it often does not, and why a scraper that looks perfectly normal at the HTTP level can still fail.

This guide explains how DataDome works, what signals it can use, what a DataDome block looks like, why browsers and scripts behave differently, and where proxies, browser automation and scraping APIs fit into the picture.

What Is DataDome?

DataDome is a bot and online fraud protection platform used by websites, mobile applications and APIs to distinguish legitimate users from automated or malicious traffic.

Website owners use systems like DataDome to reduce activity such as:

• unauthorized scraping;
• credential stuffing;
• account takeover attempts;
• fake account creation;
• inventory abuse;
• payment fraud;
• automated vulnerability scanning;
• aggressive bots;
• unwanted AI agents.

For somebody collecting public web data, DataDome appears on the other side of the equation.

Your request reaches a protected website, but before the application decides what content to return, DataDome can evaluate the request and decide whether it looks legitimate, suspicious or automated.

The result may be:

Allow

The request continues normally.

Device Check

Additional browser/device verification is performed.

CAPTCHA

The client receives an interactive challenge.

Block

The request is rejected.

That is why two requests for exactly the same URL can produce completely different responses.

The URL did not change.

The client did.

How DataDome Works

A useful simplified model looks like this:

Client → protected website/DataDome → detection decision → website

The detection step is where most scraper problems happen.

DataDome can evaluate signals from multiple layers of a connection instead of relying on one simple indicator.

These layers can include:

Layer	Example signals
Network	IP address, ASN, network reputation
TLS	TLS fingerprint and connection characteristics
HTTP	Headers, header consistency, request properties
Browser	Browser fingerprint and environment
Device	OS, hardware and execution signals
JavaScript	Results from client-side checks
Session	Cookies and continuity between requests
Behavior	Timing and patterns of interaction
Reputation	Previous activity associated with infrastructure

No single row necessarily proves that a request is automated.

The value comes from comparing them together.

A residential IP with an impossible browser fingerprint can still look suspicious.

A perfect-looking User-Agent coming from an inconsistent TLS client can still look suspicious.

A real browser generating hundreds of highly repetitive requests can still look suspicious.

That is the fundamental difference between modern anti-bot systems and old IP-blocking systems.

DataDome Detection: The Main Layers

1. IP Reputation

IP reputation is still important.

An IP address may have history.

For example, infrastructure can develop a poor reputation when large amounts of abusive or obviously automated traffic originate from it.

DataDome can consider whether traffic comes from:

• known hosting infrastructure;
• datacenter ranges;
• shared proxies;
• residential proxies;
• free public proxy networks;
• previously suspicious addresses.

But IP reputation is only one signal.

This is why statements like:

"Use a residential proxy and DataDome cannot detect you."

are misleading.

A residential address can make a network request look more like ordinary consumer traffic.

It cannot make the rest of the request automatically consistent.

2. HTTP Headers

Browsers send a recognizable collection of headers.

Automation tools also send headers.

The interesting part is not merely whether a request contains a User-Agent.

It is whether the request makes sense as a whole.

For example, imagine a client claiming to be a recent Chrome version while sending a collection of headers that do not normally match that browser.

Individually, every value may appear reasonable.

Together, they may not.

Modern bot detection can look for these inconsistencies.

Changing only:

User-Agent: Mozilla/5.0...

does not transform a simple HTTP library into Chrome.

3. TLS Fingerprinting

Before HTTP data is exchanged over HTTPS, the client creates a TLS connection.

Different clients can produce different TLS characteristics.

A browser, a Python HTTP library, a command-line client and another runtime may establish encrypted connections differently.

Those patterns can be summarized into fingerprints.

DataDome's documentation specifically references TLS fingerprinting, including JA3 and JA4 information, as part of the data that can be used when evaluating traffic.

This creates an important problem for simplistic scraping setups.

Your HTTP headers might claim:

Chrome on Windows

while the network connection underneath looks nothing like the Chrome version you claim to be using.

Changing an HTTP header does not automatically change the TLS stack beneath it.

This is one reason HTTP-only spoofing eventually hits a ceiling.

4. Browser Fingerprinting

Once JavaScript can execute, anti-bot detection has access to a much richer environment.

A real browser exposes a large amount of information about itself and the device running it.

Potential signals include characteristics related to:

• browser version;
• operating system;
• hardware;
• CPU;
• memory;
• graphics environment;
• supported browser APIs;
• rendering behavior;
• feature support;
• automation artifacts.

The difficult part for automation is not producing one believable value.

It is producing hundreds of mutually consistent values.

Suppose an automated browser claims it is running on one operating system but other parts of its environment behave like another.

Or the reported hardware characteristics do not fit the claimed device.

Or automation modifies common fingerprint properties but leaves secondary signals unchanged.

The browser may look convincing if you inspect five obvious properties.

A detection system does not have to stop at five.

5. Detecting Headless and Automated Browsers

Playwright, Puppeteer and Selenium are incredibly useful.

They are also not invisible.

Launching Chromium gives your scraper a real browser engine, which solves many problems that a basic HTTP client cannot:

• JavaScript execution;
• rendering;
• cookies;
• browser APIs;
• dynamic content;
• navigation state.

But "real browser engine" does not mean "indistinguishable from a normal user."

Automation frameworks can introduce observable differences.

DataDome's own detection documentation explicitly contains detection categories for automated and headless browsers, including browsers driven by Puppeteer, Selenium and Playwright.

That means this simple architecture:

Playwright + proxy

should not be treated as a universal anti-bot solution.

It may work perfectly on one website and fail quickly on another.

6. JavaScript and Device Check

DataDome can also request additional verification from the client.

One mechanism is Device Check.

Instead of immediately presenting a visible CAPTCHA, JavaScript runs in the browser and evaluates the environment.

According to DataDome, its Device Check collects hundreds of signals and performs multiple checks intended to detect automation frameworks, spoofed environments and programmatic access.

For a real visitor, this may happen without any obvious interruption.

For a scraper, it creates an important difference between:

HTTP client

and:

browser capable of executing the expected client-side logic

If your scraper only downloads the initial HTML and ignores everything happening in the browser, it may never reproduce the full interaction expected by the protected site.

7. Behavioral Detection

A technically convincing browser can still behave strangely.

Consider two sessions.

Session A

A user:

• opens a product page;
• spends 14 seconds reading;
• opens another page;
• scrolls;
• returns;
• searches;
• opens a result.

Session B

A crawler:

• requests product 1;
• 300 ms later requests product 2;
• 300 ms later requests product 3;
• repeats this hundreds of times.

Both sessions can use Chrome.

Both can use residential IP addresses.

Their behavior is obviously different.

Behavioral detection allows an anti-bot system to consider patterns rather than individual requests.

This matters especially at scale.

A scraper that succeeds once is not necessarily a scraper that can sustain 100,000 requests.

8. Session Consistency

Modern websites are stateful.

Cookies, browser state, IP addresses and request history all form part of a session.

Automation becomes easier to detect when those elements contradict each other.

For example:

• the IP changes constantly while the same session cookie remains;
• a browser identity changes halfway through a session;
• navigation suddenly jumps through unrelated resources;
• cookies expected from an earlier step never appear;
• every request behaves like a brand-new visitor.

This is why blindly rotating an IP for every request can sometimes make a scraper less believable rather than more believable.

Rotation is useful.

Continuity is useful.

The correct choice depends on the workload.

What Does a DataDome Block Look Like?

DataDome does not have to respond to every suspicious request in the same way.

There are several outcomes you may encounter.

403 response

The clearest signal is an HTTP 403 Forbidden response.

But do not assume every 403 on the internet comes from DataDome.

Always inspect the actual response.

CAPTCHA page

Instead of the target page, the response may contain a DataDome challenge.

Device Check

The browser may perform an invisible verification before access continues.

This is particularly confusing during debugging because the page may eventually work in your normal browser without you ever seeing a CAPTCHA.

Block page

Traffic considered sufficiently suspicious can receive a direct block response.

Different behavior in Chrome and your scraper

This is one of the strongest clues that the problem is not the URL itself.

If:

Chrome → content

but:

requests/cURL/custom script → challenge

the difference is likely somewhere in the client, network identity, browser execution or session.

Why Changing the IP Address Is Not Enough

A proxy changes an important part of the request:

where the traffic appears to originate.

That is valuable.

But it does not automatically change:

• your HTTP implementation;
• TLS fingerprint;
• browser environment;
• JavaScript execution;
• browser fingerprint;
• cookies;
• request timing;
• navigation behavior;
• session logic.

Think about the full stack:

**IP

• TLS
• HTTP
• browser
• device
• session
• behavior**

A proxy primarily changes the first layer.

That can be enough when IP reputation is the reason a request fails.

It is not enough when several layers disagree.

Datacenter vs Residential Proxies With DataDome

There is no universal "DataDome proxy."

Different proxy types solve different networking problems.

Datacenter proxies

Datacenter IPs are fast, inexpensive and extremely useful for many automation workloads.

Their disadvantage on heavily protected consumer websites is that their network origin is easier to classify as hosting infrastructure.

This does not mean every datacenter request gets blocked.

It means the IP itself may contribute less evidence that the client resembles an ordinary consumer.

Residential proxies

Residential proxies route requests through IP addresses associated with consumer internet connections.

That can provide a more appropriate network profile for workloads involving public consumer-facing websites.

But residential IP does not equal human.

DataDome explicitly documents models capable of identifying automated traffic routed through residential proxies.

The useful way to think about residential proxies is therefore:

better network identity

not:

automatic bot protection bypass

ISP proxies

ISP proxies can offer stable sessions while using IP space associated with consumer ISPs.

For workflows requiring a consistent identity over a longer session, that stability can be valuable.

Again, the rest of the client still matters.

Why Constant Proxy Rotation Can Backfire

"Rotate more often" sounds like obvious advice.

It is not always correct.

Imagine a website session lasting five minutes.

A real user would normally keep the same network identity for most of that session.

If your automation changes country or network every three requests while preserving the same cookies and account session, that combination can be unnatural.

For some workloads, rotating sessions are appropriate.

For others, sticky sessions produce more coherent behavior.

A proxy strategy should match the structure of the application you are accessing.

What About CAPTCHA Solvers?

CAPTCHA is not necessarily the beginning of DataDome's decision process.

It can be one response after other detection has already marked the session as suspicious.

That distinction matters.

Solving a CAPTCHA does not automatically repair:

• a suspicious browser fingerprint;
• an inconsistent TLS stack;
• poor IP reputation;
• impossible session behavior.

DataDome has publicly discussed detecting CAPTCHA farms and automated environments even after a challenge has been solved.

So treating CAPTCHA solving as the entire problem misses the larger system around it.

Why a Scraper Can Work Today and Fail Tomorrow

This is another common source of confusion.

Nothing in your code changes.

Suddenly the success rate falls.

That does not necessarily mean the target redesigned its website.

Bot-management systems continually change detection logic.

Other variables also change:

• IP reputation evolves;
• browser versions update;
• website policies change;
• traffic volume increases;
• your request pattern changes;
• a target enables stricter protection for a specific endpoint.

Scraping against modern anti-bot systems is therefore an operational problem, not a one-time configuration problem.

DataDome and Playwright

Playwright is useful when a website requires genuine browser execution.

It can load JavaScript, interact with pages and maintain browser state.

That makes it dramatically more capable than a simple HTTP request library for modern websites.

But Playwright does not automatically make traffic human.

The protected site may still evaluate:

• browser characteristics;
• automation artifacts;
• network identity;
• sessions;
• request frequency;
• behavior.

This is why a Playwright scraper can succeed in development and become unreliable at scale.

Browser automation solves browser execution.

It does not solve every anti-bot layer around the browser.

DataDome and Puppeteer

The same principle applies to Puppeteer.

Using Chromium gives the crawler a much richer client environment than raw HTTP.

That is useful for:

• client-rendered applications;
• dynamic pages;
• JavaScript navigation;
• content loaded after initial HTML;
• applications requiring cookies or browser state.

But the browser, IP and behavior still need to form a coherent session.

Puppeteer is a browser automation framework.

It is not an invisibility layer.

The Scraping Stack That Actually Matters

Instead of asking:

"Which proxy bypasses DataDome?"

it is more useful to think in layers.

Problem	Relevant layer
Poor IP reputation	Proxy/network
Wrong location	Geo-targeted proxy
JavaScript required	Browser/rendering
Dynamic content	Browser/rendering
TLS inconsistency	HTTP/browser stack
Browser fingerprint mismatch	Browser environment
Session instability	Cookie/session management
Excessive request pattern	Crawl architecture
CAPTCHA/challenge	Challenge handling
Constant anti-bot maintenance	Managed scraping infrastructure

This makes troubleshooting much faster.

You stop trying to solve every problem by replacing the proxy.

Three Ways to Collect Data From a DataDome-Protected Site

For legitimate data collection where you are permitted to access the target, there are broadly three architectures.

1. Build the scraper yourself

You control everything:

• HTTP client;
• browser;
• proxy;
• session;
• retry logic;
• parsing;
• rendering;
• monitoring.

Advantages:

Maximum control.

Disadvantages:

Maximum maintenance.

This makes sense when your workflow is unusual enough to justify owning the entire stack.

2. Use proxies with your own browser or scraper

Architecture:

your scraper → proxy network → target

This lets you keep control of the application while outsourcing network infrastructure.

It is useful when your primary problems involve:

• IP reputation;
• geographic targeting;
• concurrency;
• network rotation;
• stable sessions.

Geonode Residential Proxies, for example, support geographic targeting and both rotating and sticky session configurations.

But your application remains responsible for everything above the proxy layer.

3. Use a Scraping API

Architecture:

your application → scraping API → target

Instead of maintaining browsers, proxy selection and extraction infrastructure yourself, you send the URL to a service designed for web data collection.

This is often a better fit when the real requirement is:

"Give me the page content."

rather than:

"I want to maintain an anti-bot/browser infrastructure team."

Geonode's Scraper API, for example, can return rendered page content as HTML or Markdown and provides JavaScript rendering, managed proxy infrastructure, geo-targeting, batch processing and crawling.

The important distinction is ownership of complexity.

With proxies:

you control the stack.

With a scraping API:

the scraping platform manages more of the stack.

Neither model is universally better.

They solve different engineering problems.

Proxy vs Browser vs Scraping API

Solution	Changes IP	Executes JS	Manages browser	Handles extraction	Your maintenance
Proxy only	Yes	No	No	No	High
Playwright + proxy	Yes	Yes	You	You	High
Puppeteer + proxy	Yes	Yes	You	You	High
Scraping API	Managed	Yes, if supported	Managed	Managed	Lower

This is why telling somebody to "just use residential proxies" is incomplete advice.

Sometimes that is exactly what they need.

Sometimes the proxy is only one piece of a much larger problem.

How to Troubleshoot DataDome Blocks

When requests start failing, do not change ten things simultaneously.

Diagnose the layer.

Problem: Works in browser, fails in script

Possible areas to investigate:

• JavaScript execution;
• HTTP/TLS client differences;
• browser fingerprint;
• cookies;
• session state.

Changing the IP may have no effect if the failure originates in the client.

Problem: Works initially, then gets blocked

Look at:

• request rate;
• repeated navigation patterns;
• IP/session rotation;
• growing IP reputation problems;
• session consistency.

The first request and the thousandth request are not equivalent.

Problem: Datacenter IP fails, residential works

Network reputation is probably an important part of the decision.

That still does not prove other signals are being ignored.

Problem: Residential proxy also fails

Do not immediately conclude that the residential proxy is bad.

Investigate:

• browser/client fingerprint;
• TLS characteristics;
• JavaScript requirements;
• cookies;
• request patterns;
• session design.

Problem: CAPTCHA appears repeatedly

A CAPTCHA loop can indicate that the broader session continues to look suspicious.

Treat the challenge as a symptom, not necessarily the root cause.

Problem: Different countries produce different results

Check whether:

• the site itself behaves differently by geography;
• content availability changes;
• cookie state remains consistent;
• IP geolocation matches the intended session.

Does DataDome Detect Residential Proxies?

It can.

This is explicitly reflected in DataDome's detection documentation.

That does not mean every residential proxy request is blocked.

If it did, legitimate users behind shared consumer networks would create enormous false-positive problems.

The more accurate statement is:

A residential IP is one signal, not proof of a human visitor.

Modern detection combines it with other evidence.

Does DataDome Detect Playwright?

DataDome documents detection models covering browsers instrumented through automation frameworks including Playwright, Puppeteer and Selenium.

That does not mean every Playwright session is automatically blocked.

It means the assumption:

"Playwright uses a real browser, therefore it cannot be detected"

is incorrect.

Does DataDome Use Browser Fingerprinting?

Yes.

Browser and device fingerprinting form part of DataDome's detection architecture.

This lets the system compare information exposed by the browser and execution environment instead of trusting simple identifiers such as the User-Agent header.

Does DataDome Use TLS Fingerprinting?

DataDome documentation references TLS fingerprints and recommends JA3 and JA4 fingerprints as signals available to its protection API integrations.

This matters because the TLS connection is created before ordinary web application logic sees the request.

A scraper can therefore have perfectly edited HTTP headers while still exposing a different lower-level network fingerprint.

Does DataDome Use Machine Learning?

DataDome describes its threat-detection models as machine-learning based and continuously updated.

Machine learning is not magic.

Its practical value here is the ability to combine many signals and patterns instead of relying on one static rule such as:

block IP after 100 requests.

Can DataDome Block AI Agents?

Yes.

The bot-management market is increasingly expanding beyond traditional scrapers into AI agents and LLM crawlers.

DataDome now explicitly supports identifying and authenticating commercial bots and AI agents, while unauthenticated automated traffic can be subjected to its threat-detection policies.

This is likely to become increasingly important as more AI systems browse and interact with websites directly.

Can You Bypass DataDome?

This is usually the wrong engineering question.

There is no permanent header, proxy type or browser flag that makes a modern detection system disappear.

A configuration that works for one endpoint at one traffic volume may fail:

• on another endpoint;
• at a larger scale;
• with another browser version;
• after detection models change.

For legitimate web data workloads, the more sustainable question is:

What part of my scraping stack is causing the request to be classified as automation, and do I want to maintain that layer myself?

Sometimes the answer is network infrastructure.

Use a suitable proxy setup.

Sometimes the answer is rendering.

Use a browser.

Sometimes the answer is the entire operational stack.

Use a managed scraping API.

And sometimes the right answer is to use an official API or another authorized data source instead.

DataDome vs Cloudflare

DataDome and Cloudflare overlap in parts of the bot-management market, but they should not be treated as identical products.

Cloudflare offers a broad infrastructure platform that includes CDN, DNS, WAF, DDoS mitigation and bot-management capabilities.

DataDome is more specifically focused on bot and online-fraud detection across websites, mobile applications and APIs.

From the perspective of a scraper developer, however, the lesson is similar:

modern anti-bot protection operates across multiple layers.

A working strategy cannot rely solely on changing one HTTP header.

DataDome vs CAPTCHA

DataDome is not a CAPTCHA service.

CAPTCHA is one possible response after detection.

The actual system deciding whether a client is suspicious sits before that.

This distinction matters because developers often spend enormous effort trying to "solve the CAPTCHA" while ignoring the signals that caused the challenge to appear.

The better question is:

Why was this session challenged in the first place?

When Residential Proxies Make Sense

Residential proxies are useful when the networking layer matters.

Examples include legitimate workloads involving:

• geo-specific public content;
• localized search results;
• regional pricing;
• product availability;
• market research;
• distributed web collection.

They are especially useful when you want to keep full control of your own scraper.

Geonode's Residential Proxies provide residential IP routing with geographic targeting and configurable session behavior.

But a proxy should remain what it actually is:

network infrastructure.

It is not a browser.

It is not a CAPTCHA system.

It is not a scraping engine.

And it does not automatically repair a broken fingerprint.

When a Scraper API Makes More Sense

A Scraper API becomes attractive when anti-bot maintenance is starting to dominate development.

You should at least consider a managed API when your team spends more time on:

• browser upgrades;
• retry logic;
• proxy orchestration;
• rendering;
• extraction;
• session handling;
• failed requests;

than it spends using the data itself.

With Geonode Scraper API, an application can send URLs and receive extracted HTML or Markdown while the service manages rendering and proxy infrastructure behind the request.

The trade-off is straightforward:

Building yourself gives more control.

Using an API removes infrastructure work.

Choose based on what your product actually needs.

FAQ

What is DataDome?

DataDome is a bot and online-fraud protection platform designed to identify automated and malicious traffic across websites, mobile applications and APIs.

How does DataDome detect bots?

It combines multiple signals including IP reputation, HTTP and browser fingerprints, TLS characteristics, device information, behavioral patterns and machine-learning detection models.

Why does DataDome block my scraper?

There is rarely one universal reason. The IP address, HTTP/TLS client, browser environment, JavaScript support, session consistency or request behavior can all contribute.

Does DataDome use CAPTCHA?

Yes, CAPTCHA can be one response to suspicious traffic. DataDome can also perform an invisible Device Check or directly block requests.

What is DataDome Device Check?

Device Check is an additional verification mechanism that runs client-side checks without necessarily requiring visible user interaction. It evaluates device and execution signals and can allow, challenge or block the client depending on the result.

Does changing my User-Agent bypass DataDome?

Changing the User-Agent modifies only one HTTP value. It does not automatically change the TLS connection, browser environment, device fingerprint, cookies or behavior.

Can DataDome detect headless Chrome?

DataDome specifically documents detection categories for headless and automated browsers, including browsers instrumented through Puppeteer, Selenium and Playwright.

Can DataDome detect Playwright?

It can identify characteristics associated with browser automation, including Playwright-driven environments. Using Playwright does not automatically mean a session will be blocked, but it should not be considered inherently invisible.

Can DataDome detect Puppeteer?

Yes, DataDome documents detection models covering Puppeteer-based automation and Puppeteer Extra Stealth.

Can DataDome detect residential proxies?

DataDome has detection models related to traffic routed through residential proxies. A residential IP can still be useful because it changes the network identity, but it does not make automated traffic automatically legitimate.

Are residential proxies better than datacenter proxies for DataDome-protected sites?

Residential proxies can provide a network identity closer to ordinary consumer traffic, which may be useful on consumer-facing sites. The correct choice still depends on the target, workload and other detection layers.

Do I need a browser to scrape a DataDome-protected site?

Not every protected page requires a browser. However, websites relying on client-side rendering or Device Check may require genuine JavaScript execution and browser state that a basic HTTP client cannot provide.

Why do I get 403 errors from DataDome?

A 403 can indicate that the request was classified as suspicious or automated. Verify that the response actually comes from DataDome before assuming the anti-bot system is responsible.

Why does the page work manually but not in Python?

Your normal browser and Python HTTP library produce very different network, TLS, HTTP, JavaScript and browser environments. An anti-bot system can observe some of those differences.

Why does my scraper work for a few requests and then stop?

Possible causes include behavioral detection, rate patterns, IP reputation changes or inconsistent sessions. Anti-bot systems can evaluate activity across multiple requests rather than judging every request in isolation.

Does rotating proxies solve DataDome?

Not by itself.

Rotation changes the network identity. It does not automatically change the browser fingerprint, TLS client, JavaScript environment or request behavior.

Is a Scraping API better than proxies?

They solve different problems.

Use proxies when you want control of your scraper and primarily need network infrastructure.

Use a Scraping API when you want more of the browser, proxy, rendering and extraction infrastructure managed for you.

The Bottom Line

The most useful thing to understand about DataDome is that there is no single "bot signal."

Modern anti-bot detection looks across layers.

A request is not just an IP address.

It is:

an IP
making a TLS connection
sending HTTP headers
from a browser or application
inside a session
with a history
and a pattern of behavior.

The more those pieces agree with each other, the more coherent the client looks.

That is why switching an IP can fix one problem and leave five others untouched.

It is why Playwright solves JavaScript execution without solving every detection problem.

And it is why managed scraping APIs exist in the first place.

If you need full control, build the stack yourself and use proxies as network infrastructure.

If you mainly need reliable web content without maintaining browsers and proxy orchestration, use a scraping API.

The important part is knowing which layer you are actually trying to fix.