← All posts

How to Fix the 'Please Enable JavaScript' Error When Scraping

GUIDES · JUL 19, 2026 · 5 MIN READ

Your scraper runs, the request succeeds, and the response contains a polite little message: "Please enable JavaScript to continue" or "You need to enable JavaScript to run this app." The actual content is nowhere. Meanwhile the same page loads perfectly in your browser.

Here is the part most guides get wrong: this message has two completely different causes, and they need completely different fixes. If you apply the fix for the wrong one, you will burn hours adding a headless browser only to get blocked anyway, or adding stealth tricks to a page that just needed rendering.

Let's diagnose which one you have, then fix it.

The Two Things That Produce This Message

Cause 1: a JavaScript-rendered page (the innocent case). The site is a Single Page Application built with React, Vue, or similar. The server sends a nearly empty HTML shell plus a script bundle, and the browser builds the page client-side. The "enable JavaScript" text lives in a <noscript> tag as a fallback for browsers with JS turned off. Your HTTP client does not run JavaScript, so the fallback is all you see. Nobody is blocking you. The content simply is not in the HTML.

Cause 2: a bot challenge (the adversarial case). An anti-bot layer like Cloudflare, DataDome, or PerimeterX flagged your request as automated and served a challenge page instead of the real one. The challenge runs JavaScript to probe your environment, and the page tells you to enable JavaScript because the check cannot complete without it. Cloudflare's version is the famous "Just a moment..." interstitial. Here, someone absolutely is blocking you, and rendering alone will not save you.

Same error text on your screen. Opposite problems underneath.

Diagnose It in 60 Seconds

You can tell the cases apart from the response itself. Check these signals in order.

1. The status code. A noscript fallback comes with a normal 200 OK. Challenges usually come with 403 or 503.

import requests

r = requests.get("https://example.com/page")
print(r.status_code, len(r.text))

2. The response headers. A cf-ray header or server: cloudflare means Cloudflare is in the path. cf-mitigated: challenge is a direct confession that you got challenged.

3. The body markers. Grep the HTML for these strings:

Marker in the body Verdict
<noscript>You need to enable JavaScript JS rendering (innocent)
<div id="root"></div> or id="app" with little else JS rendering (innocent)
Just a moment... Cloudflare challenge
cf-chl, _cf_chl_opt, challenge-platform Cloudflare challenge
Checking your browser before accessing Challenge (older Cloudflare wording)
datadome, geo.captcha-delivery.com DataDome challenge

4. The control test. Fetch the page from your local machine with a real browser User-Agent. If it still returns the shell, it is client-side rendering. If it works locally but fails from your server, IP reputation is involved, which points to a challenge. Datacenter IPs from AWS or cheap VPS ranges carry low trust with every anti-bot vendor; in my experience running fetch infrastructure at link.sc, IP reputation alone explains the majority of blocks people misdiagnose as something else.

Fix for Cause 1: The Page Renders Client-Side

Before you reach for a browser, open DevTools on the page and watch the Network tab. Most SPAs pull their data from a JSON API like /api/products?page=1. If that endpoint answers without auth, call it directly. It is faster and more stable than rendering, and it skips this whole problem.

If there is no usable API, you need something that executes JavaScript. Playwright is the standard choice:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("https://example.com/page")
    page.wait_for_selector(".article-body")  # wait for real content
    html = page.content()
    browser.close()

The wait_for_selector line matters. Waiting for load fires before client-side data arrives, and you get the shell again from inside a browser. Wait for an element that only exists once real content has rendered. I covered the wait strategies in more depth in how to scrape JavaScript-rendered websites.

This fix is complete for the innocent case. No proxies, no stealth plugins, no fingerprint games needed.

Fix for Cause 2: You Are Being Challenged

This is where the misdiagnosis gets expensive. People see "enable JavaScript," add vanilla Playwright, and still get the challenge page, because anti-bot vendors detect standard headless browsers through navigator.webdriver, missing plugins, and headless rendering quirks. Running JavaScript was never the real test. Looking like a human was.

Challenges score you on several layers at once:

  • TLS fingerprint. Python requests has a handshake that identifies it as a script before a single header is sent. curl_cffi fixes this by impersonating Chrome's TLS fingerprint, and it clears a surprising share of soft blocks on its own.
  • Browser environment. For harder challenges you need a stealth browser (patched Chromium, or a hardened Firefox like Camoufox) that hides automation tells.
  • IP reputation. If you are on a datacenter IP, none of the above may be enough. Residential or mobile IPs carry the trust that datacenter ranges lost years ago.

Escalate cheapest-first: curl_cffi, then a stealth browser, then a stealth browser on residential IPs. Do not start at the top; a full browser is 10 to 100x slower and more expensive than plain HTTP. The full ladder is in curl_cffi vs. headless vs. stealth browser, and the Cloudflare-specific mechanics are in how to scrape Cloudflare-protected sites.

One caveat that belongs in every post like this: escalate for public pages only. Do not use these techniques to get around logins, paywalls, or a site that has clearly told you to go away.

The Trap: Both Causes at Once

Plenty of sites are both. A React app behind Cloudflare gives you the challenge first, and once you clear it, the noscript shell, and only after rendering, the content. This is why "I added Selenium and it still shows the JavaScript message" is such a common dead end. You solved rendering but not reputation, or reputation but not rendering.

The practical consequence: diagnose after every change. If the marker in the body switched from cf-chl to <div id="root">, you made progress. Same message, different problem.

Or Skip the Ladder Entirely

Maintaining this decision tree per domain is real, ongoing work: sites change protection vendors, wait strategies rot, and IP pools go stale. The link.sc fetch API runs the escalation for you. It starts with fast HTTP using real browser TLS fingerprints, moves up to a stealth browser with smart waits when a page needs JavaScript, and remembers which method each domain requires so repeat fetches skip straight to what works.

curl -X POST https://api.link.sc/v1/fetch \
  -H "x-api-key: lsc_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/page", "format": "markdown"}'

You get clean markdown back whether the page was a plain document, a React shell, or sitting behind a challenge. The "please enable JavaScript" message becomes something you never see again.

Tired of diagnosing which wall you hit? Get a free link.sc API key and let one endpoint handle rendering, fingerprints, and challenges for you.