Where does it go? traces URLs by talking to web servers the same way a simple, non-browser program would. This keeps it fast, safe, and lightweight, but it also means it cannot behave exactly like a real web browser. Below is an honest overview of what the bot can and cannot trace.
1. What the bot handles well
- Standard HTTP redirects, such as
301, 302, 303, 307, and 308 status codes.
- The non-standard HTTP
Refresh header (for example, Refresh: 0; url=https://example.com).
- HTML
<meta http-equiv="refresh"> redirects.
- Simple JavaScript redirects where the destination is readable in the page source, such as:
window.location.replace("https://example.com")
window.location.href = "https://example.com"
location.assign("https://example.com")
window.open("https://example.com", "_self")
- Redirect services that fetch an internal endpoint returning the target URL as plain text.
2. What the bot cannot trace
- Dynamic JavaScript and SPAs. Single-page applications (React, Vue, Angular, etc.) often decide the redirect inside JavaScript files that are loaded after the initial page. The bot does not execute JavaScript, so it cannot follow these redirects.
- Cloudflare and anti-bot challenges. Pages protected by Cloudflare, captchas, or Turnstile challenges require a real browser session. The bot cannot solve those challenges.
- Redirects triggered by user interaction. Buttons, cookie-consent flows, and manually clicked links are not followed.
- Redirects hidden in WebSockets or authenticated APIs. If a page swaps the destination through a private API call, the bot will not see it.
- Content behind logins or session cookies. The bot does not authenticate with third-party services.
3. Safety limits that can also affect traces
- Private and local destinations (such as
localhost, 192.168.x.x, or company-internal domains) are blocked to prevent abuse of the server.
- Certain file types, such as executables, archives, and known risky MIME types, are refused before or during the trace.
- There is a maximum redirect count and a request timeout for each hop, so intentionally slow endpoints cannot hang the bot.
Important: Because the trace is done server-side, the final destination shown may differ from what you see in a normal browser. Some sites serve different responses to bots, require JavaScript, or protect themselves with anti-bot measures. The bot adds a note to each result reminding you of this limitation.
4. What happens with an untraceable redirect
When the bot detects a page that looks like a redirect but cannot extract the destination, it marks the trace as potentially incomplete and shows a warning. You will see the last reachable URL, plus a message explaining that a JavaScript or challenge-based redirect may have stopped the trace early.
5. Future improvements
In the future a headless-browser fallback may be added for URLs that absolutely require JavaScript. This is currently not planned for simplicity and resource usage reasons.
6. Contact
If you believe a URL should be traceable and is not, or if you have questions about a specific result, please email wdig-bot@chaoskjell44.dev.