The short answer.
Could not fetch urlis a network failure, not a formula failure. The page was never retrieved, so your XPath was never run.- The request comes from Google's servers, not your browser. No cookies, no session, and an IP range plenty of sites block.
- Rewriting the XPath cannot fix it. If you are still editing the second argument, you are debugging the wrong half of the formula.
- If the site blocks Google's fetcher by policy, there is no formula that works, and that is the real finding.
Your formula worked for six months. Nothing changed in the spreadsheet. Today every row says Could not fetch url, and pasting the same URL into a browser tab loads the page instantly.
Both of those things are true at once, and the reason is that they are not the same request.
What the error actually reports
IMPORTXML runs in two stages. First Google's infrastructure makes an HTTP request for the URL. Then, if that returns parseable markup, your XPath is evaluated against it.
Could not fetch url is the first stage failing. It is a single message covering several distinct outcomes: the request was refused, it was redirected somewhere that could not be followed, it timed out, it returned a non-HTML content type, or it returned a body too large or too malformed to parse.
The practical consequence is the one people miss for hours: your XPath was never evaluated. Rewriting it, simplifying it, or copying a fresh one from DevTools changes nothing, because that argument has not been reached.
Why the browser is a misleading test
When you load the page yourself you send a request with your residential IP, a full browser user-agent, whatever cookies and sessions you have, and a JavaScript engine that finishes the job. When Sheets loads it, the request comes from a Google data centre IP, with a bot user-agent, no cookies, no session, and no JavaScript.
Anything in the following list is enough to make one succeed and the other fail:
- A CDN or WAF (Cloudflare, Akamai, and similar) challenging non-browser traffic.
- An explicit block on Google's fetcher IP ranges, which is common on sites that have been scraped heavily.
- Content behind a login, a paywall, a cookie wall, or a region gate.
- A redirect chain that ends somewhere the fetcher will not follow.
- Rate limiting that trips when a spreadsheet asks for 400 URLs at once.
- The page returning a non-HTML content type, or an error page with a 200 status.
Note the last two. A sheet full of IMPORTXML formulas is not one request, it is hundreds, arriving together from the same source. Sites that tolerate one visitor routinely rate-limit that pattern, which produces the specific and confusing symptom of some rows working.
Diagnose it in three checks
1. Separate a fetch failure from an empty result
Replace your XPath with something that matches almost any page:
=IMPORTXML("https://example.com", "//title")If this still says Could not fetch url, the page is unreachable and the XPath is irrelevant. If it returns the title, your fetch is fine and you have a different problem: an XPath that matches nothing, which reports as Imported content is empty instead.
2. Check whether the site serves HTML at all
Open the page and use View Source, not Inspect Element. View Source shows what a fetcher receives. Inspect Element shows what the browser built afterwards, including everything JavaScript added. If View Source is a near-empty shell, no fetcher will ever get your data from that URL.
3. Test one URL, not four hundred
Put a single formula in an empty sheet. If one URL works alone and fails inside your full sheet, you are being rate limited, not blocked, and the fix is throughput rather than access.
What actually fixes it
| Cause | Fix | Works? |
|---|---|---|
| Transient timeout | Wait, then force a recalculation | Often |
| Rate limiting from too many rows | Fewer formulas, staggered | Often |
| Redirect or trailing-slash mismatch | Use the final URL, not the redirecting one | Sometimes |
| JavaScript-rendered page | Find an underlying JSON endpoint, if one exists | Sometimes |
| CDN or WAF challenge | Nothing inside Sheets | No |
| Deliberate block on Google's fetcher | Nothing inside Sheets | No |
| Login or paywall | Nothing inside Sheets | No |
The bottom four rows are the honest part of this article. A large share of Could not fetch url errors on commercial websites, which is to say most of the pages anyone wants firmographic data from, are policy decisions by the site. No spreadsheet formula negotiates with a WAF.
When you need the data anyway
If the URL is genuinely unreachable by a plain fetch, the remaining options are: find an official API, find the JSON endpoint the page's own JavaScript calls, or use something that fetches differently from a Google data centre.
That last one is what a scraping layer is for, and it is worth being clear about what it buys you. It is not magic: a site determined to block automated access will still block it. What it does is retry sensibly, rotate how requests are made, fall back through several methods when the first one is refused, and tell you per row which URLs failed and why, instead of leaving an error string in a cell. ReplyLabs does this from the same spreadsheet, and only charges for rows that come back with data. We compared the two approaches directly in IMPORTXML versus a managed enrichment step.
And sometimes the correct answer is that this data is not obtainable at a price worth paying, which is a much better place to arrive at in ten minutes than in two days.