The agent handed you a URL and said it's live. It probably is. What it didn't tell you is who can open it, how long it lasts, whether the address is guessable, and what happens to it when you revise — four defaults chosen for you, none of them announced.
The agent finished, published the page, and handed you a URL. It's live — that part is almost always true.
What the confirmation didn't mention is that publishing involved four decisions, and something made all four of them for you.
This got much more common in 2026. Publishing capability arrived in agent surfaces across the board — tool integrations, connectors, agent-facing APIs, documentation written specifically for models to read. The step that used to mean opening a browser and dragging a file now happens inside a sentence.
That's a genuine improvement, and it introduces one specific gap. Dragging a file into a browser puts you in front of the settings. You see whether there's a visibility toggle, whether an expiry is preselected, what the address looks like before you commit. Even if you don't change anything, you've seen the defaults.
An agent doing it for you skips that screen entirely — that's the point of it. So the defaults still apply, still get chosen, and now nobody has looked at them. The response says published because publishing is what happened; four settings rode along underneath, and there's no natural place in a one-line confirmation to surface them.
Nothing here is a failure. It's just that the efficiency and the visibility came out of the same screen.
Do this one first because it subsumes several others, and do it in a private or incognito window rather than your normal browser.
This matters more than it sounds. Signed in, your session quietly satisfies whatever check the page might have — a workspace membership, an account, a domain restriction. The page opens instantly and looks public. Your recipient, holding the same URL with none of your credentials, may get a sign-in wall instead.
That mismatch is the single most common way a link fails after being sent, and it's invisible from the sender's side by construction. It's the same mechanism behind share links that won't open for the person you sent them to: the link assumes the reader is you.
What you're reading in the private window:
Look at the URL as text, and ask one question: could someone arrive here by guessing?
Agent-facing hosts split on this. Some derive the address from your filename or title — clean, memorable, and guessable by anyone who could guess the title. Others generate a long random string, which is unmemorable and effectively unguessable.
Both are legitimate. A public marketing page wants a readable address. A client deliverable generally doesn't, because a readable address is one somebody can reach without you having sent it to them. The failure mode is inheriting the wrong one silently — and it's a real one, given that index.html is the correct name for a web root and also a spectacularly bad basis for a client-facing URL.
Worth being precise about what unguessable buys you, though: it defeats guessing and crawling, not forwarding. Anyone who has the link has full access and can pass it on invisibly. That trade is the difference between a custom short link and an unguessable one, and it's a real decision rather than a strictly-better option.
Ask what window was set, or check the service.
Agent-facing publish tools skew short, and for a defensible reason: their commonest case is an agent producing a preview during a build loop, and a host that kept every one of those forever would fill up with abandoned pages. Short windows are the right default for that.
They're the wrong default for a deliverable. A client opening the link two weeks later and finding nothing is worse than not having sent it, because now it looks like the work vanished.
The reverse case is just as real. If the page contained a draft, a real client name, or a figure that was still moving, permanent is the wrong default and a short window is the feature. The point is knowing which one you got.
These get conflated constantly and they're independent properties.
Openable is about access — can someone holding the URL see it. Findable is about discovery — can someone who's never seen the URL arrive via a search result.
A page can be effectively hidden today purely because nobody knows the address, and appear in results later because nothing ever instructed crawlers to skip it. Unguessable is not no-index. The instruction has to actually be on the page.
So: does what your agent published carry a no-index instruction, or is it merely obscure? For anything with a client's name on it, you want the instruction and not the obscurity.
Save this one for last because it's the one that decides whether sending the link now is safe at all.
Two behaviours, identical from the chat window:
A new page per publish. Every revision produces a fresh URL. The link you already sent keeps working and keeps showing the old version — which is worse than breaking, because nobody is alerted. Your client reads last Tuesday's numbers and has no way to know.
An update in place. The address stays; the contents change. The link you sent in March shows the current version in September, and the person holding it never has to do anything.
The first is fine while you're iterating alone. It stops being fine the moment the URL has left your hands. So the ordering that saves you: find out which one you have before the link goes out, not when you need to correct something.
If it's the first, the workaround is to publish once at the end rather than throughout — and to accept that a correction means a new link and a follow-up message to everyone holding the old one.
miinideck publishes private and no-index by default, on an unguessable link, with optional password and expiry — and a re-upload replaces the file while keeping the same URL, so a revision never orphans a link you already sent.
Each check is cheapest at a different moment, and the order reflects that rather than importance.
The private window comes first because it's one action that surfaces the most, and because it's the only check nothing else substitutes for. The address is next because it's free — you're already looking at the URL. Expiry and indexing follow because both are usually adjustable after the fact if you catch them. The revise question comes last because it's the one you most want answered before the link goes out, and putting it at the end is how you avoid sending first and discovering after.
Ten seconds for all five. The alternative isn't a disaster — it's a follow-up email explaining that the link they've been using shows an old version, which is a small, avoidable, entirely self-inflicted cost.
That publishing arrived in agent surfaces everywhere in 2026 isn't a threat to anything — it's confirmation that handing work over as a link is now the default expectation rather than a workaround. Enough people wanted this step gone that several products removed it in the same year.
What it changes is where the friction sits. It used to be at how do I get a link at all — and that's genuinely solved now. It has moved one step downstream, to who can open it, how long it lives, and whether it's still the right link after you revise. Those questions didn't used to need asking, because the screen you did the publishing on had already answered them in front of you.
Now something answers them on your behalf, quickly and usually well. Which is a good deal, as long as somebody looks.
It looked like a URL. You sent it. It doesn't exist — and never did. Why models produce link-shaped text when you ask them to share something, how to spot it in one second, and what actually has to happen for a real link to exist.
ChatGPT Sites hosts what you build and gives you access controls — owner only, named workspace members, the whole workspace, or the public internet. There's no rung for one outside client. Here's the shape of that gap and the route round it.
The steps take about ten seconds. The cost is less obvious: unpublishing permanently retires that artifact's ability to be published, and deletes its stored data. Here's how to do it, what it takes with it, and what to reach for when access only needs to end for now.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.