The Document That Isn't There Until You Run It
Fetch a URL and for a long time what came back was the thing itself: the words, the number, the table. Increasingly what comes back is scaffolding, a promise that content will show up once a program runs.
HTTP GET requests a resource, and decades of tooling assume the resource is text, HTML that already contains what a person would see. That assumption held because servers used to build the page before sending it. Data got assembled into markup on a machine somewhere, and the bytes you got back were the finished thing. Fetching and reading were the same act.
A growing share of pages don't work that way anymore. The server sends a near-empty shell: a stylesheet, a loading spinner, a script tag. The script runs in a browser, calls an API, and only then does anything resembling content appear on screen. The HTML you fetched isn't the document. It's a set of instructions for producing the document, and the instructions only execute if something agrees to run them.
I pulled up a USGS earthquake event page not long ago looking for a magnitude and a location. What came back was font-face declarations, a spinner, and a noscript tag pointing at a real-time data feed. The magnitude, the coordinates, the timestamp, none of it touches the static markup. It lives behind an API call a browser makes after the page loads. Fetch that URL with curl and you get a page that is, factually, about nothing. Not because curl failed. The document you wanted was never at that address, only a pointer to where it gets built.
That's the part worth sitting with: curl did exactly what was asked, retrieve the bytes at the URL. The failure sits upstream, in the belief that the bytes at a URL and the content a person would see are the same claim. They used to be, closely enough that nobody bothered to separate the ideas. Client-side rendering broke the equivalence without changing the vocabulary. We still say "fetch the page" as if that names one operation, when for pages like this it names two: get the shell, then execute it against a live backend that may or may not still be answering.
Web archives inherit the same trap. Save a client-rendered page and you've saved the shell, not what appeared on screen. A crawler that doesn't run the scripts and replay the API calls gets a spinner frozen in time, an artifact that looks like a failed capture when it's actually a faithful capture of an object that was always incomplete on its own. Some archives can execute the scripts and record what comes back, but that's a far harder promise than "store these bytes," and it degrades as the backend drifts from what it was on capture day. A static page from ten years ago still says what it said. A ten-year-old snapshot of a client-rendered page might replay against an API that's since changed shape or gone dark.
Citing a URL carries an implicit claim: I looked here, and this is what was there. For a page that assembles itself at runtime, that claim quietly shifts. You're not citing content anymore, you're citing a location where content used to get produced, under conditions you didn't record and mostly can't recover. Two people citing the same event page a year apart aren't necessarily disagreeing about the facts. They may just have hit the backend at different points in its life, or one of them still had the JavaScript run and the other didn't.
None of the tools are wrong. A URL is an address, not a guarantee. It's just that for twenty years the two were close enough to treat as one, and a lot of infrastructure got built on top of not noticing the gap.
The address still resolves. Whether anything answers is a separate question.