How to Share a ChatGPT Site for Review or Use

To share a ChatGPT Site, open the Site, review its preview, and use Share to choose an audience your account supports. Publish when ready, then test the resulting URL as an intended visitor before sending it widely. fenbs can keep the review feedback, approved changes, and next steps linked to the Site so the review survives beyond its creation chat.

What are you sharing: a Site, a preview, or code?

First identify the result you have. A working website at a published URL, a preview shown during editing, a screenshot, and a collection of source files serve different purposes. A reviewer looking at a screenshot cannot check a form, while someone receiving source code may need a developer to run it.

OpenAI’s ChatGPT Sites guide↗ (opens in a new tab) documents hosted Sites and their sharing controls. Generating website code in an ordinary answer does not itself prove that you have a published Site. Look for the Site’s own preview, Share, and publishing controls rather than treating any code response as a live website.

Tell the reviewer exactly what the link represents: “Working Site for content review; submissions are test data.” If you are sharing the conversation instead, use the separate ChatGPT sharing guide. For development work around source files, ChatGPT Codex explains the coding side without confusing it with visitor access.

How do you choose an audience and send the link?

1. Open the Site you intend to share. Review its visible content and complete the main visitor journey before changing access.
2. Select Share, then inspect Who has access. Choose the available audience that matches the review, rather than the widest option.
3. If inviting a named reviewer, check the email address and access level before saving. If publishing publicly, confirm that public access is intentional.
4. When the Site is ready, select Publish. After publication, select Visit to open the Site or Copy link to copy its published URL.
5. Send the URL with a short review request: what to test, what is still provisional, and where you want feedback.

Available audiences and sign-in requirements depend on account and workspace controls. Use the options your own dialog presents. If an option is missing, ask the workspace owner to check the relevant permission rather than following a screenshot from another account or widening access as a workaround.

What should you check in the Site before others see it?

Walk through the Site like someone who did not build it. Read every heading, open each destination, and try its controls with ordinary and empty inputs. A polished first screen can conceal a missing confirmation message, a broken download, or a page still filled with sample information.

• Content: replace placeholders and remove client details, internal comments, and information the audience should not receive.
• Behavior: check buttons, navigation, search, forms, downloads, and any action that changes information.
• Presentation: try a phone-size screen, readable text, keyboard navigation, and long labels.
• Data: identify what is sample data, what is live, and what a visitor can submit or change.
• Ownership: name the person who will handle questions, corrections, and requests to remove material.

Write down the unresolved checks so a reviewer does not mistake silence for completion. In fenbs, the work record can hold the Site link beside the tasks still required before broader sharing. Mark a check complete only after someone actually performed it on the version being reviewed.

How do you test access without relying on your own login?

Ask a reviewer to open the published URL using the account you invited. For a public Site, also test in a signed-out browser. Tell them what they should see and ask them to report whether they reached the Site, whether its content appeared, and whether the main action worked.

Distinguish permission to open the Site from access to a service it uses. OpenAI’s workspace administration guide↗ (opens in a new tab) explains that connected-app features have separate controls and use each visitor’s own authorized account. Inviting a person to view the Site does not hand them your connected credentials.

A useful access report says “The page opens, but the document list is empty after sign-in,” not simply “the link is broken.” Capture the account or workspace category and the visible error without circulating private account information. That gives the owner a specific boundary to investigate.

How should reviewers request changes?

Give reviewers a focused question rather than asking whether they like the Site. For example: “Can a first-time visitor find the installation guide and understand which model it covers?” Ask for the page, the action taken, the expected result, and what happened. Include a screenshot when the problem concerns layout.

Separate a suggestion from an approved revision. A reviewer might prefer shorter navigation labels, but the owner still needs to choose which wording becomes current. Collecting that decision outside the creation chat helps the next assistant avoid implementing conflicting comments as though they were all instructions.

How to do this with fenbs

1. Create a free account and add the project behind the Site. Describe the intended audience and the job the Site should help them do.
2. Add the published Site URL to Links and listings. Record the review date and a short description of the version or change set people are reviewing.
3. Add tasks for review findings, with a clear expected result. Keep design preferences separate from broken behavior so each task has an understandable purpose.
4. Record the owner’s choices in Decisions and rules. Connect a supported assistant using Integrations and ask it to read the project context before implementing changes.
5. Save progress with what changed, what was checked, and what still needs a person’s review. Confirm the Site again after the next approved publication.

fenbs does not publish or host the ChatGPT Site. It is useful for the work around the Site; a single disposable preview may need only a short message. It is free for one person, with no credit card, when you want to try keeping one real review and its follow-up work together.

What should you preserve after the review ends?

Save the approved outcome, the reason behind it, and any limitation the next reviewer should know. “Mobile navigation approved; file downloads still need checking” is more useful than “Site reviewed.” When the audience changes from a few colleagues to external visitors, repeat the access and content review rather than relying on the earlier result.

Our AI handoffs topic covers keeping that continuity between sessions. If you change the assistant used to revise the Site, Claude vs ChatGPT covers the broader choice. Preserve the current decisions and outstanding work so changing tools does not reopen every settled review question.