Hit a ChatGPT Sites usage limit? Your Sites aren't gone. Here's how to tell the ones that are just pages, which travel, from the ones that need Sites underneath them.
You've built a handful of Sites in ChatGPT: a proposal for one client, a monthly report for another, a launch page, maybe a small tool. Then ChatGPT tells you you're approaching a usage limit. Or a client writes back to say the link you sent last week has stopped opening for them.
The first thing to know: nothing has been deleted. The second: some of those Sites are just pages, and pages can live anywhere. The rest need Sites underneath them, and moving those would break them.
This page is about telling the two apart.
Here's OpenAI's documentation, word for word:
"Plan-specific usage limits apply across all Sites during the beta. ChatGPT shows the current limits and notifies you as you approach one. Reaching a limit can prevent you from creating a Site, adding storage, or keeping a high-usage Site public, but you can still edit and manage existing Sites."
That sentence makes three separate points, and people tend to merge them into one scary one:
The third point is the one a client notices. They don't see your usage meter. They see a link that used to open.
The documentation doesn't give one number for everyone, because there isn't one. The limits depend on your plan, they apply during the beta, and ChatGPT shows you the current figures as you get close. Sites is available on Plus, Pro, Business, Enterprise and Edu plans, so your numbers depend on which of those you're on.
So we're not going to print a number here. A figure copied from a forum post is exactly the kind of fact that's wrong by next month, and it would send you to the wrong decision.
The one fixed figure the documentation does give is per-Site storage: a D1 database of up to 10 GB per Site, and R2 object storage with no fixed limit. (Checked against OpenAI's Sites documentation on 14 September 2026. Their page is the source of truth if it has changed since.) That's a storage figure, not the usage limit, and it's the reason the next section matters. D1 and R2 are where a Site keeps data, and data is what doesn't travel.
Sort your Sites by one question: does this Site need Sites to be running underneath it while someone is looking at it?
| What the Site does | What it uses | Can it move as a file? |
|---|---|---|
| Shows a proposal, report, one-pager, launch page or slide-style walkthrough | Content only: HTML, CSS, JavaScript, images | Yes |
| Runs a calculator or interactive chart on numbers already in the page | Content only | Yes |
| Saves what visitors type (entries, bookings, responses) | A D1 database for saved records | No |
| Lets visitors or you upload files | R2 object storage | No |
| Shows different things depending on who's looking | Workspace identity, or Sign in with ChatGPT | No |
The top two rows are what OpenAI's documentation calls content-led pages with no persistent state. For a lot of people who build Sites for clients, that's most of their Sites. A proposal doesn't need a database. A monthly report doesn't need to know who's reading it.
The bottom three rows are applications. The page you see is only the front of them. Lift the HTML out and you get the front with nothing behind it: a form that submits nowhere, an upload button that goes nowhere, a dashboard with no data.
If you can't tell which row a Site is in, run the test in the next section. Opening the exported file on its own answers it in about ten seconds.
This part is already written up in detail, so here's the short version. In the conversation that built the Site, ask for the full HTML as a single self-contained file, with the CSS and JavaScript inlined, save it, and open it locally. The exact wording and what to check are in the line that gets the work out. If the local copy comes up blank or half-styled, the self-contained export checklist covers what usually leaks. It's written for Claude, but it applies to any AI tool's output.
Once the file opens on its own, put it on a static host and send the new link.
Two things are different when you're moving because of a limit rather than sharing for the first time:
The address changes once. The people who have the old Site link need the new one. Send it before you do anything to the original. After that first switch, a host that lets you replace the file at the same address means the link stops changing. A report that goes out every month keeps the same link instead of becoming a new link each time.
Deleting is final. OpenAI's documentation is explicit: "You can't restore a deleted Site." Don't delete the original to make room until the moved copy has opened correctly for the person it's meant for.
Drop the exported .html (or a ZIP, if the page came as several files) and get an unguessable, no-index link that opens for anyone you send it to. They don't need an account. When the next version comes, replace the file and the link stays the same.
Leave them on Sites, and make room around them.
If a Site that needs a backend has outgrown your plan, the honest next step is a real deployment. It isn't a static host, and that includes us. Vercel, Netlify and Cloudflare are built for exactly that job and will serve you far better than we would. Cloudflare also happens to sell a database and object storage under the same two names, D1 and R2. That's worth knowing if you end up rebuilding, but it doesn't mean anything carries over automatically.
Moving isn't automatically the right answer, even for a page that could move.
Stay when the Site needs saved records, uploads or sign-in. That's what Sites gives you without having to build a backend.
Stay when your audience will sign in. Sites can now invite named viewers from outside your workspace, where external invitations are available. The documentation says invited visitors must sign in with the account that received access, and describes external invitations as rolling out to Plus, Pro, Business and Enterprise. If the problem was that a Site could no longer stay public, and the real audience is three people who already use ChatGPT, an invitation keeps everything where it is. The documentation doesn't say invited-only Sites are exempt from usage limits, so treat this as a sharing choice, not a way around the limit.
Move when the person on the other end won't sign in, or the page is the kind of thing a client forwards to people you've never met. A reviewer at a bank or a client's finance team often won't create an account to look at one page. For them, a link that opens without signing in is the delivery. What your client actually sees is worth reading before the first one goes out.
ChatGPT Sites can now invite a named viewer from outside your workspace — but they have to sign in with the account you invited. If your client won't, here's the shape of what's left and the route round it.
The AI tool built the page. Sending it to a client is a second job: stripping the construction site, making it read as yours, and putting it behind a private link. A practical checklist for turning AI output into a client-ready handoff.
A disabled Publish button isn't one bug — it's four different situations wearing the same grey. Two of them are permanent, two clear in a minute. Here's how to tell which one you're looking at, and how to get the page to the person waiting for it either way.
miinideck turns a single HTML file into an unguessable link with optional password and expiry. Default-private, never indexed.