docs: add Safe Mode enterprise page

[claude]

Requested by Micah Stairs · Slack thread

Before: Safe Mode was undocumented. A search of this repo for "safe mode", "safeMode", "safe-mode" and "SAFE_MODE_BLOCKED" returned zero hits. Two organizations run Safe Mode in production today. A caller who hit a 403 had nothing to read, and a caller whose results were quietly restricted got no signal at all. Several existing pages contradict the behavior: the proxy pages promise an automatic retry through enhanced proxies, the crawl page presents ignoreRobotsTxt as available, and the interact and browser pages teach logins and saved profiles.

After: features/safe-mode.mdx is a user-facing page. It tells what Safe Mode is and why an organization uses it. It then tells what changes for your requests, in groups: proxies, logins and credentials, robots.txt, site restrictions, browser identity, and Threat Protection. It names the requests that succeed with restricted results (extract, search without scrapeOptions, monitoring runs). Cache-only mode has its own section. The page tells team admins how to configure Safe Mode from Enterprise Controls → Safe Mode, including the allowlist and per-request opt-outs. It then covers the safeMode request parameter, billing, and an error reference that tells what to do for each error.

How: The page follows the tone and structure of the sibling enterprise pages (features/key-restrictions.mdx, features/ip-restrictions.mdx, features/threat-protection.mdx). The dashboard steps and control names come from the Enterprise Controls Safe Mode settings in firecrawl-web. The nav entry is under Documentation > Get Started > Enterprise in the v2 and v1 trees of the en block only. The locale trees are untouched: the translation pipeline owns them.

Validated locally: docs.json parses as valid JSON. mint broken-links reports no broken link on the page. scripts/check-extraction-hostile-markdown.sh passes.

Follow-ups, not in this PR:

• Proxy pages: the auto escalation promise on the v2 and v1 proxy pages, enhanced mode and capabilities.mdx.
• Error code pages: rows for the Safe Mode codes in api-reference/errors.mdx and api-reference/introduction.mdx.
• OpenAPI specs: 403, 404 and 500 responses on the scrape family.
• Actions and headers: the login-flow samples and action tables in the advanced scraping guides.
• Profiles and interactive sessions: the interact, browser, fast-scraping and n8n pages.
• Lockdown: the maxAge and "force fresh" claims on fast-scraping and scrape, and the missing v1 lockdown page.
• Threat protection: the "Off means no checks" claim and the credit note.
• Silently restricted endpoints: notes on the extract, search and monitoring pages.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Hjz6hgqrjcrFMszbGrEUqY

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
firecrawl	🟢 Ready	View Preview	Sep 24, 2026, 2:38 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[claude]

CI: Locale literals and extraction-hostile markdown is red, and it is not this PR

The check Locale literals and extraction-hostile markdown fails on this PR (run 35147334471). It is red on main too. Every violation is in a file this PR does not touch.

This PR changes two files

features/safe-mode.mdx (new) and docs.json (two added lines). Nothing else. No locale file is touched.

All 14 violations, none in a file this PR touches

The job failed on its first step, scripts/check-locale-api-literals.sh. Every finding is a translated API literal in a locale tree:

File	Identifier
es/features/change-tracking.mdx	seguimientoDeCambios
es/features/fast-scraping.mdx	seguimientoDeCambios
es/features/search.mdx	seguimientoDeCambios
es/sdks/cli.mdx	seguimientoDeCambios
es/v1/features/search.mdx	seguimientoDeCambios
es/webhooks/events.mdx	rastreo.iniciado
fr/features/change-tracking.mdx	suiviDesModifications
fr/features/monitoring.mdx	suiviDesModifications
fr/sdks/cli.mdx	suiviDesModifications
fr/v1/features/search.mdx	suiviDesModifications
pt-BR/features/change-tracking.mdx	rastreioDeMudan
pt-BR/sdks/cli.mdx	rastreioDeMudan
pt-BR/v0/sdks/node.mdx	dadosRaspados
pt-BR/v1/features/search.mdx	rastreioDeMudan

6 in es/, 4 in fr/, 4 in pt-BR/. Zero name features/safe-mode.mdx or docs.json.

Evidence that main is red

.github/workflows/checks.yml runs on: pull_request only, with no push trigger, so there are no workflow runs on main to point at. The GitHub Actions API returns total_count: 0 for checks.yml filtered to branch=main. Three other lines of evidence:

1. The script fails on pristine main. Run on a clean checkout of 5fe7171 (this PR's base, before my commit): exit code 1, the same 14 findings. Compared against the same script on my branch: the output is byte-identical, diff returns nothing.
2. The previous PR failed the same way. PR #1427 (codex/web-data-api-positioning, a different author, opened about 3 hours before this one) failed the same check with the same violations: run 35128546705.
3. Six consecutive unrelated PRs failed before this one. checks.yml runs 57 through 62 all failed, on six unrelated branches by five different authors. The last green runs were 52 and 53 on fix/locale-api-literals-green at 2026-09-15 17:13 and 17:15. The next locadex sync run failed at 17:36, about 21 minutes later, and it has stayed red since.

This matches the known pattern: each locadex sync reintroduces the translated identifiers because the terms are not pinned as do-not-translate in the General Translation dashboard. Fixing the locale trees here is out of scope for this PR, and the CLAUDE.md guideline forbids editing them by hand.

The extraction-hostile half is clean

That half matters, because a brand new page can genuinely trip it. The job never reached it: it exited at step 1, so scripts/check-extraction-hostile-markdown.sh did not run in CI. I ran it locally on this branch:

$ sh scripts/check-extraction-hostile-markdown.sh
Extraction-hostile markdown checks passed.
exit=0

Other checks on a9aa67c

Check	State
Mintlify Validation (firecrawl) - link-rot	neutral, the known pre-existing broken-link report
Mintlify Deployment	still in progress at the time of writing
Locale literals and extraction-hostile markdown	failure, pre-existing, detailed above

What I validated locally instead

The rendered page could not be checked: docs.firecrawl.dev and *.mintlify.site are blocked by this session's egress policy. So:

• docs.json parses as valid JSON, and features/safe-mode appears exactly twice, in the v2 and v1 trees of the en block, both under Documentation > Get Started > Enterprise. Zero entries in any locale tree.
• All 15 links on the new page resolve: 10 to real .mdx files, 5 to real headings on the page.
• All braces on the page sit inside inline code spans or fenced blocks, so MDX will not read one as a JSX expression.
• No em-dashes and no en-dashes.

Leaving this as a draft. No fix pushed, because there is nothing here for this PR to fix.

---

Generated by Claude Code