25 ChatGPT-5.5 Prompts for Website QA, Privacy Reviews, Accessibility Checks, and Stakeholder Approval

Use ChatGPT-5.5 as a Structured Reviewer, Not as a Compliance Stamp

Website QA, privacy review, accessibility checking, and stakeholder approval fail most often when reviewers look at different evidence and use different definitions of “ready.” The prompts in this article are designed to make ChatGPT-5.5 act as a structured review partner: it should inspect the same evidence package your team provides, separate facts from assumptions, classify risk, ask for missing proof, and produce an approval-ready issue log. That is materially different from asking a model to “check my website” and accepting a confident summary without reproducible findings.

This approach is especially useful for teams reviewing conventional websites, landing pages, product microsites, documentation portals, and ChatGPT Sites before sharing them internally, with named external viewers, or publicly. OpenAI describes ChatGPT Sites as a public-beta feature for creating, previewing, publishing, and sharing interactive websites and lightweight applications from Work on the web or from Work or Codex in the desktop app. Because Sites can be owner-only, internally shared, shared with named external viewers, or public when the workspace permits it, the review prompt must always identify the intended audience before judging risk.

For practical QA, the model should be given evidence rather than vague instructions. A strong review package includes the page URL or staging link if available, screenshots for key states, the intended user journeys, form fields, error states, browser and device targets, copy decks, analytics and tag inventories, cookie banner behavior, known third-party scripts, accessibility notes, and the exact approval decision being requested. If the site is a ChatGPT Site, include the planned sharing mode, whether public publishing is allowed in the workspace, whether named external viewers are invited, and whether the Site contains forms, uploaded files, links, authentication behavior, or third-party content.

OpenAI’s ChatGPT Sites documentation makes the approval context important. Named external viewers can receive view-only access without joining the workspace, and OpenAI states they cannot edit or publish the Site. Enterprise and Edu administrators must enable Sites for the relevant role and separately enable the permission to invite external visitors. The review implication is direct: a prompt should not merely ask whether “external sharing is safe.” It should ask whether the specific audience setting, invitation list, in-Site behavior, embedded links, forms, and data collection match the business purpose and whether a human owner has retested access after every sharing change.

For ChatGPT Website Quality Assurance, AI-Generated Code Is Creating a New Software Bottleneck: Complete Guide to Validation, Testing, and Quality Assurance for AI-Assisted Development is the most relevant adjacent resource. The AI-assisted development quality guide explains why validation, testing, and review capacity become bottlenecks when software is produced faster, which is the operating problem these QA prompts address.

For AI Accessibility Review, 40 ChatGPT-5.5 Prompts for UX Designers: User Journey Mapping, Wireframe Descriptions, Usability Testing Scripts, and Design System Documentation is the most relevant adjacent resource. The UX prompt collection includes usability testing and design-system documentation patterns that complement this masterclass’s keyboard, contrast, semantic, and inclusive-interaction reviews.

What Evidence to Provide Before You Ask for a Review

A useful prompt starts with the artifacts that a human reviewer would need. If the model lacks the artifact, it should say so and treat any conclusion as provisional. For example, it can flag that a newsletter form appears to collect email addresses from a screenshot, but it cannot verify downstream retention, processor contracts, consent logging, or deletion workflows unless you provide those details. The goal is to prevent the model from filling gaps with plausible but unverified assumptions.

• Scope statement: Define the pages, flows, environments, languages, devices, and browsers in scope. Example: “Review the pricing page, signup modal, and confirmation email in the staging environment for US desktop and mobile users.”
• Audience and access model: State whether the site is private, internal, shared with named external viewers, or public. For ChatGPT Sites, include the intended audience setting and whether workspace controls allow public publishing or external invitations.
• User journeys: Provide the expected steps for core tasks, such as account creation, form submission, file download, appointment booking, support escalation, or stakeholder demo review.
• Data map: List every field, cookie, analytics tag, file upload, embedded third-party service, outbound link, and backend destination known to the team.
• Visual and code evidence: Supply screenshots, page text, component states, console errors, network observations, HTML snippets, design tokens, or accessibility scan outputs where available.
• Policy constraints: Provide internal requirements, brand rules, legal disclaimers, launch criteria, takedown requirements, and any jurisdiction-specific obligations that reviewers must apply.
• Approval request: Specify whether you need a go/no-go recommendation, an issue triage table, a stakeholder signoff memo, or a rollback-readiness review.

For ChatGPT Sites, include one additional evidence block: “sharing and publication controls.” OpenAI states that Sites can be restricted to owner and admins, shared internally, shared with named external viewers, or made public when the workspace allows it. OpenAI also warns that removing a direct invitation does not necessarily remove access granted through another audience setting. A review prompt should therefore request a retest plan that checks the intended visitor experience after publishing, after inviting a viewer, and after removing access.

Why Prompt-Based Review Does Not Certify Compliance

A prompt can help identify risk, but it cannot certify legal compliance, accessibility conformance, security assurance, or privacy adequacy on its own. Compliance depends on facts outside the visible page: contracts, retention schedules, processor roles, consent records, age-screening requirements, jurisdiction, accessibility test coverage, assistive-technology behavior, incident-response procedures, and administrative controls. The model can organize evidence and highlight missing proof; it should not declare that a site is compliant merely because the supplied screenshots look acceptable.

Operational rule: Treat every AI-generated review as a draft assessment. A named human owner must accept, reject, or escalate each finding before launch, external sharing, public publishing, or stakeholder approval.

This caution matters for ChatGPT Sites because OpenAI’s documentation identifies specific risk areas that require pre-publication review. Public or shared Sites should be checked for confidential information, uploaded files, forms, links, authentication behavior, third-party content rights, and visitor data collection. OpenAI also states that ChatGPT Sites does not support data residency or inference residency at launch. If your organization has residency commitments, regulated-data boundaries, or customer contractual restrictions, a prompt can help surface the conflict, but only your legal, security, and governance teams can decide whether the use case is permitted.

The same applies to sensitive data. OpenAI’s Sites documentation says Sites must not process protected health information or payment-card data except through an appropriate third-party payment processor, and must not target children below the applicable age of digital consent. A prompt should be written to detect signs of these use cases, request proof of the payment processor or age-screening design where relevant, and escalate the decision. It should not invent an exception, approve a workaround, or assume that a form is harmless because it has a short label.

Define Severity Before the Model Reviews Anything

Severity should be defined before the review begins, because different teams use the same labels differently. A marketer may call a broken hero image “critical” before a campaign launch, while a security reviewer reserves “critical” for unauthorized data exposure. The most reliable approach is to define severity by user impact, business impact, data risk, legal risk, accessibility exclusion, and reversibility. Then require the model to classify every finding against that rubric and explain its evidence.

Severity should also include a confidence rating. If the model sees direct evidence, such as a screenshot showing an unlabeled field or provided HTML showing missing alt text, it can mark confidence as high. If it infers risk from a description without logs, screenshots, or policy text, it should mark confidence as medium or low and request more evidence. This prevents teams from treating speculation and verified defects as equivalent.

Require Reproducibility, Not Just Observations

Every actionable finding should include reproduction steps. A reviewer should be able to follow the same path, see the same result, and confirm the fix. For website QA, reproduction steps should include environment, page, account state, device class, browser, viewport if relevant, input data, expected result, actual result, and supporting evidence. For privacy review, reproducibility may mean documenting the path from form submission to observed network request or policy mismatch. For stakeholder acceptance, it may mean mapping a business requirement to a visible page state.

Recommended finding format:
- Finding ID:
- Severity:
- Confidence:
- Evidence supplied:
- Assumptions:
- Reproduction steps:
- Expected result:
- Actual result:
- Affected users or stakeholders:
- Recommended fix:
- Human owner:
- Approval decision needed:
- Retest evidence required:

This structure makes prompt output usable in issue trackers, release meetings, and stakeholder approval packets. It also forces the model to expose uncertainty. If a finding cannot be reproduced from the supplied evidence, the prompt should require the model to label it as “needs verification” rather than presenting it as a confirmed defect.

Preserve Human Approval and Administrative Control

The final decision should remain with accountable humans because the consequences of publishing are organizational, not conversational. A launch manager may accept a low-risk copy issue; a privacy lead must decide whether visitor data collection is acceptable; an accessibility owner should validate assistive-technology impact; an Enterprise administrator controls whether roles may publish or invite external viewers; and a legal or security reviewer may block use cases involving confidential, regulated, or third-party-controlled material.

For ChatGPT Sites, approval should also distinguish content approval from access approval. A Site may have accurate content but the wrong audience setting. A named external viewer may be appropriate for a client demo, while public access may be inappropriate for the same Site. OpenAI states external viewers do not become workspace members and cannot edit or publish, but view-only access still exposes whatever the Site displays or collects. Your prompt should therefore ask for a human decision on both dimensions: “Is the content approved?” and “Is this sharing mode approved?”

The prompts in the next sections follow a consistent pattern: intended outcome, variables to replace, a filled example, and an explanation of how to use the output. When you adapt them, keep the evidence package, severity rubric, reproducibility requirement, and human approval line intact. Those four controls are what turn ChatGPT-5.5 from a general writing assistant into a disciplined review partner for website launches and ChatGPT Sites publishing decisions.

Prompts 1–9: Functional, Content, Access, and Regression QA

Use these prompts when a website or ChatGPT Site is close enough to preview that reviewers can click through real flows, inspect copy, and make access-control decisions. OpenAI’s ChatGPT Sites documentation describes Sites as a way to create, preview, publish, and share interactive websites and lightweight applications, but it also places responsibility on owners and administrators to review confidential information, uploaded files, forms, links, authentication behavior, third-party content rights, and visitor data collection before sharing or publishing.

For ChatGPT Testing Prompts, 30 ChatGPT Prompts for AI Agent Safety Testing: Red-Team Your Autonomous Systems Before They Red-Team You is the most relevant adjacent resource. The autonomous-agent safety-testing collection demonstrates evidence-based red-team, containment, and verification prompts that can be adapted to high-risk website interactions.

For Website Launch Checklist, How to Build and Deploy a Full Web App with Codex Sites — From Prompt to Production in Under 10 Minutes is the most relevant adjacent resource. The prompt-to-production Codex Sites tutorial provides a concrete deployment lifecycle against which navigation, forms, analytics, permissions, and regression checks can be scheduled.

1. Prompt: Functional Smoke Test for the Main User Journey

Use case: Run this prompt when the site first reaches a clickable preview or staging state. The goal is to catch broken core journeys before deeper privacy, accessibility, or stakeholder review begins.

You are reviewing a website for functional smoke-test readiness.

Site or preview URL: {site_url}
Primary audience: {primary_audience}
Core journey to test: {core_journey}
Critical pages or screens: {critical_pages}
Known constraints: {constraints}

Test the journey as a cautious reviewer. Produce:
1. Pass/fail status for each step.
2. Evidence observed, including page names, labels, visible messages, and URLs when available.
3. Assumptions you made because access, credentials, or data were missing.
4. Severity for each issue: blocker, high, medium, or low.
5. Reproduction steps for every failed or questionable item.
6. A recommendation: approve for broader review, approve with conditions, or stop and fix first.
Do not infer success when a step was not directly tested.

Variables: Use {site_url} for the preview or published URL; {primary_audience} for buyers, employees, applicants, students, or external clients; {core_journey} for the one journey that must work; and {constraints} for missing logins, test data, or unsupported browsers. Example: “Request a product demo from homepage to confirmation message.”

Expected output: A step-by-step smoke-test report with a decision at the end. The useful output is not “looks good”; it is a traceable list of what was clicked, what appeared, what failed, and whether the site is ready for wider review.

Verification step: A human reviewer should repeat every blocker and high-severity reproduction path in a clean browser session. Do not advance to stakeholder approval until the primary journey works without unexplained assumptions.

2. Prompt: Navigation and Link Integrity Review

Use case: Use this prompt to test menus, footer links, calls to action, cross-page links, and external destinations. This is especially important before a Site is shared externally, because named external viewers can use the Site even though OpenAI states they cannot edit or publish it.

Act as a navigation and link QA reviewer.

Site URL: {site_url}
Pages to inspect: {page_list}
Required navigation paths: {nav_paths}
External domains expected: {expected_external_domains}
Audience setting being tested: {audience_setting}

Review navigation and links. Return:
1. A table of every tested link or navigation element.
2. Source page, link text, destination, and whether it opened correctly.
3. Any unexpected external domain, download, sign-in wall, blank page, loop, or 404-like behavior.
4. Severity and user impact for each issue.
5. Reproduction steps with browser, viewport, and audience state.
6. Assumptions and items that require administrator or owner confirmation.
7. Approval recommendation for navigation readiness.

Variables: Set {page_list} to “homepage, pricing, docs, contact, privacy, terms” or your actual structure. Set {audience_setting} to owner-only, internal, named external viewers, or public if that reflects the current review state.

Expected output: A link inventory focused on user impact. It should flag destinations that unexpectedly expose documents, require authentication, trigger downloads, or route users away from the promised workflow.

Verification step: Retest all broken and unexpected links manually in signed-in and signed-out states where applicable. If a link reaches third-party content, confirm that marketing, legal, or security approved that destination and its visitor-data implications.

3. Prompt: Forms and Validation Behavior Review

Use case: Run this prompt for contact forms, waitlists, feedback forms, account requests, file uploads, and newsletter signups. OpenAI’s Sites guidance warns that public or shared Sites should be reviewed for forms, uploaded files, authentication behavior, and visitor data collection; this prompt turns that warning into a concrete test plan.

You are reviewing website forms for usability, validation, and data-risk issues.

Site URL: {site_url}
Forms to test: {forms}
Allowed data types: {allowed_data_types}
Prohibited data types: {prohibited_data_types}
Test inputs to try: {test_inputs}
Expected success state: {expected_success_state}

For each form, test normal, missing, malformed, excessive, and prohibited inputs. Report:
1. Field-by-field validation behavior.
2. Error messages and whether they are clear, specific, and non-sensitive.
3. Whether prohibited data appears requested, accepted, echoed, logged visibly, or encouraged.
4. File-upload behavior if present.
5. Confirmation, notification, or redirect behavior after submission.
6. Severity, reproduction steps, assumptions, and owner approval required before launch.

Variables: For {prohibited_data_types}, include protected health information, payment-card data, secrets, credentials, children’s data, or other restricted categories for your organization. OpenAI states that Sites must not process protected health information or payment-card data except through an appropriate third-party payment processor, and must not target children below the applicable age of digital consent.

Expected output: A form-risk report that separates ordinary UX defects from sensitive-data problems. A missing required-field message may be medium severity; a form inviting card numbers or health data should be escalated according to organizational policy.

Verification step: Have the form owner confirm the business need for each field and the privacy owner confirm that collection, retention, and disclosure language match the actual behavior.

4. Prompt: Responsive Behavior Across Viewports

Use case: Use this prompt when reviewers must confirm that the site works on phones, tablets, laptops, and large displays. Responsive QA should test the same task across viewports, not merely inspect whether the homepage “looks fine.”

Act as a responsive website QA reviewer.

Site URL: {site_url}
Critical journeys: {critical_journeys}
Viewports to test: {viewports}
Browsers or devices available: {browsers_devices}
Components of concern: {components}

For each viewport, review layout and task completion. Return:
1. Whether each critical journey can be completed.
2. Navigation, menu, modal, form, table, media, and call-to-action problems.
3. Text clipping, overlap, hidden controls, horizontal scroll, unreadable spacing, or blocked content.
4. Evidence with page, viewport, and visible symptom.
5. Severity and reproduction steps.
6. Assumptions and items requiring design or engineering approval.

Variables: Use real viewport targets such as “390 x 844 mobile, 768 x 1024 tablet, 1366 x 768 laptop, 1920 x 1080 desktop.” For {components}, list hero sections, pricing tables, embedded media, navigation drawers, cookie banners, or forms.

Expected output: A matrix showing whether each core task survives each viewport. The best findings identify exactly where a button disappears, a menu traps the user, or a form becomes unusable.

Verification step: Reproduce high-impact issues on at least one physical device or a controlled browser emulator. Engineering should verify the fix at the failing viewport before stakeholders review the page again.

5. Prompt: Content Accuracy and Claims Review

Use case: Use this prompt before marketing, legal, product, or executive stakeholders approve public copy. It helps catch unsupported claims, stale pricing language, incorrect feature descriptions, and ambiguous commitments.

You are reviewing website content for accuracy and approval risk.

Site URL or content excerpt: {site_or_excerpt}
Approved source material: {approved_sources}
Claims requiring extra scrutiny: {sensitive_claims}
Audience: {audience}
Jurisdictions or markets: {markets}

Review the content and produce:
1. A list of factual claims, promises, comparisons, numbers, availability statements, and legal-sensitive statements.
2. Whether each claim is supported by the approved source material.
3. Any missing caveat, ambiguity, outdated wording, or overbroad statement.
4. Severity and business risk.
5. Suggested safer wording that preserves the intended message.
6. Assumptions and the accountable approver for product, legal, privacy, security, or marketing.

Variables: Paste approved launch notes, product requirement documents, legal disclaimers, pricing source text, or release documentation into {approved_sources}. If no source exists for a claim, instruct the model to mark it unsupported rather than rewrite it as fact.

Expected output: A claim-by-claim review with proposed wording. For example, “available to all customers” should be flagged if availability actually depends on plan, workspace control, region, surface, or rollout.

Verification step: Route each high-risk claim to the named owner. Do not rely on ChatGPT to validate legal truth, product availability, pricing, or regulatory wording without an authoritative source and human approval.

6. Prompt: Analytics and Event Instrumentation QA

Use case: Use this prompt to verify that key events are measurable without collecting unnecessary personal data. Analytics QA should connect business questions to event names, triggers, consent behavior, and privacy review.

Act as an analytics instrumentation QA reviewer.

Site URL: {site_url}
Measurement goals: {measurement_goals}
Expected events: {expected_events}
Consent or privacy requirements: {consent_requirements}
Analytics tools in scope: {analytics_tools}
Data that must not be collected: {restricted_data}

Review instrumentation and return:
1. Whether each expected event fires at the correct user action.
2. Event name, trigger condition, page, and observed parameters if available.
3. Missing, duplicate, premature, or misleading events.
4. Any restricted data visible in event names, parameters, URLs, form fields, or logs available to the reviewer.
5. Severity, reproduction steps, assumptions, and privacy-owner approval needed.
6. A launch decision for analytics readiness.

Variables: Define {measurement_goals} as decisions, not vanity metrics: “measure demo-start to demo-submit conversion” is better than “track clicks.” In {restricted_data}, include email addresses, phone numbers, account IDs, health data, payment-card data, secrets, and free-text form contents unless explicitly approved.

Expected output: A practical instrumentation checklist showing which events can be trusted and which could create privacy or reporting risk. It should distinguish a missing event from an event that fires before consent or includes excessive data.

Verification step: Confirm findings with your analytics debugger, tag manager preview, browser developer tools, or server-side telemetry available to the team. Privacy or security must approve any event that includes user identifiers or form-derived values.

7. Prompt: Role and Audience Access Review

Use case: Use this prompt for ChatGPT Sites or any website with audience-based visibility. OpenAI documents that a Site can be restricted to its owner and admins, shared internally, shared with named external viewers, or made public when workspace settings allow it; Enterprise and Edu administrators must enable Sites for the relevant role and separately enable external visitor invitation permissions.

You are reviewing role and audience access for a website or ChatGPT Site.

Site URL: {site_url}
Intended audience setting: {intended_audience}
Roles to test: {roles_to_test}
Named external viewers, if any: {external_viewers}
Content that must remain restricted: {restricted_content}
Administrator constraints: {admin_constraints}

Produce an access review:
1. Expected access for each role or audience.
2. Observed access, including signed-in, signed-out, internal, external, and owner/admin states where testable.
3. Any mismatch between intended and observed access.
4. Content, forms, files, or admin-like controls exposed to the wrong audience.
5. Severity, reproduction steps, assumptions, and administrator questions.
6. Human approval decision required before sharing or publishing.

Variables: Use role names that match your workspace governance, such as owner, admin, editor, internal viewer, named external viewer, and signed-out visitor. Do not treat an external viewer as a workspace member; OpenAI states named external viewers receive view-only access and do not gain editing or publishing rights.

Expected output: An access matrix that identifies where sharing intent and actual reachability differ. The report should also flag cases where removing a direct invitation may not be enough because another audience setting could still grant access.

Verification step: Test with separate accounts or clean sessions representing each audience. After every sharing change, retest reachability because OpenAI notes that removing a direct invitation does not necessarily remove access granted through another audience setting.

8. Prompt: Signed-Out Visitor Experience Review

Use case: Use this prompt before public launch or when stakeholders need to know what unauthenticated visitors can see. Signed-out testing catches accidental login walls, exposed draft content, broken public calls to action, and unclear authentication prompts.

Act as a signed-out visitor QA reviewer.

Public or preview URL: {site_url}
Pages to test while signed out: {pages}
Tasks a signed-out visitor should complete: {allowed_tasks}
Tasks that should require sign-in or invitation: {restricted_tasks}
Expected audience setting: {audience_setting}

Using a clean signed-out session, report:
1. Pages reachable without authentication.
2. Tasks completed successfully while signed out.
3. Tasks blocked, redirected, or shown an invitation or sign-in requirement.
4. Any restricted content, form, file, admin control, or private data visible while signed out.
5. Confusing messages, loops, or dead ends.
6. Severity, reproduction steps, assumptions, and launch recommendation.

Variables: Set {allowed_tasks} to public browsing, reading documentation, submitting a public inquiry, or viewing a marketing page. Set {restricted_tasks} to editing, publishing, viewing client-only materials, accessing internal dashboards, or submitting sensitive workflows.

Expected output: A signed-out access report that proves what a public visitor can and cannot do. A correct block should still be reviewed for clarity: users need to know whether to request access, sign in, or return to public content.

Verification step: Repeat the test in an incognito or private browsing session with cache cleared. For public Sites, confirm that the visible content contains no confidential information, unapproved files, private forms, or third-party content that has not been cleared.

9. Prompt: Deployment Regression Review

Use case: Run this prompt after a deployment, republish, permission change, content update, or rollback. Regression review is narrower than full QA: it compares what changed against what must not break.

You are conducting a deployment regression review.

Environment or URL before change: {before_url_or_notes}
Environment or URL after change: {after_url}
Change summary: {change_summary}
Areas expected to change: {expected_changes}
Areas that must not change: {must_not_change}
Known prior approvals: {prior_approvals}
Rollback or takedown contact: {rollback_contact}

Compare the post-change site against expectations. Return:
1. Confirmed intended changes.
2. Unexpected visual, functional, content, access, analytics, privacy, or form changes.
3. Any previously approved item that appears altered.
4. Severity, reproduction steps, evidence, and assumptions.
5. Whether rollback, takedown, hotfix, or approval re-review is recommended.
6. The accountable human decision-maker for release acceptance.

Variables: Use {must_not_change} for protected flows such as pricing language, privacy links, form consent text, access settings, analytics consent behavior, and stakeholder-approved copy. Add {rollback_contact} so urgent findings have an owner instead of becoming a launch-room debate.

Expected output: A regression delta that separates intended release changes from accidental breakage. The report should be short enough for a release manager to act on and detailed enough for engineering, security, privacy, or marketing to reproduce.

Verification step: Recheck all blocker and high-severity findings against the live or staged deployment target. If the change affected audience settings, sharing, forms, or visitor data collection, require explicit approval from the responsible owner before treating the deployment as complete.

Prompts 10–18: Privacy, Data Handling, and Accessibility Review

Use the next nine prompts when a website, landing page, prototype, or ChatGPT Site is close enough to publish that privacy, data collection, inclusive design, and approval risk can be reviewed against visible evidence. OpenAI’s ChatGPT Sites documentation specifically calls for review of confidential information, uploaded files, forms, links, authentication behavior, third-party content rights, and visitor data collection before a Site is shared or published. These prompts turn that review into repeatable questions with severity ratings, evidence requests, assumptions, reproduction steps, and a named human decision.

Operational boundary: These prompts support review and triage. They do not certify legal compliance, accessibility conformance, data protection compliance, or security safety. Ask ChatGPT-5.5 to identify issues, missing evidence, and decision points; keep approval with legal, security, accessibility, privacy, product, or workspace administrators.

10. Prompt: Privacy Notice and Visitor Disclosure Review

Intended outcome: Identify whether the page explains what data is collected, why it is collected, who receives it, and what visitors should expect before they submit a form, upload a file, authenticate, or interact with embedded third-party tools. This is especially important for public or externally shared Sites because OpenAI’s Sites guidance warns teams to review visitor data collection and forms before sharing.

Variables to replace: {site_url_or_description}, {audience}, {data_collected}, {privacy_notice_text}, {approval_owner}.

Review this website privacy notice as a decision-support reviewer, not as legal counsel.

Site or page: {site_url_or_description}
Audience: {audience}
Known data collected: {data_collected}
Privacy notice text or link: {privacy_notice_text}
Human approval owner: {approval_owner}

Filled example:
Site or page: External beta feedback form for a ChatGPT Site shared with named client reviewers
Audience: Enterprise client reviewers outside our workspace
Known data collected: Name, company email, free-text feedback, browser metadata from analytics, optional screenshot upload
Privacy notice text or link: "We use your feedback to improve the demo. Do not submit confidential information."
Human approval owner: Privacy counsel and product owner

Tasks:
1. Create a table with privacy disclosure topics: data collected, purpose, optional vs required fields, third-party processors or embeds, analytics, uploaded files, retention statement, contact channel, and sensitive-data warning.
2. For each topic, mark Evidence found, Missing evidence, Assumption, Severity, and Recommended fix.
3. Identify any mismatch between the visible form behavior and the notice.
4. Provide reproduction steps for every observation.
5. List questions the human approval owner must answer before launch.
6. End with one of: Approve, Approve with changes, Block pending privacy review, or Insufficient evidence.

For AI Privacy Impact Assessment, 25 ChatGPT-5.5 Prompts for Privacy-First ChatGPT Ads Campaigns: Research, Creative Briefs, Measurement, and Optimization is the most relevant adjacent resource. The privacy-first ChatGPT Ads prompt collection models consent, measurement, data minimization, and review questions that transfer well to a website privacy-impact assessment.

11. Prompt: Data-Flow Inventory for Forms, Analytics, and Integrations

Intended outcome: Produce a practical data-flow inventory that shows where visitor information originates, where it is transmitted, where it is stored, who can access it, and which gaps require confirmation. This is useful before sharing a Site externally because view-only access does not remove the need to review forms, links, authentication behavior, and connected services.

Variables to replace: {page_or_feature}, {inputs}, {integrations}, {storage_locations}, {review_scope}.

Build a data-flow inventory from the evidence below.

Page or feature: {page_or_feature}
Visitor inputs: {inputs}
Known integrations: {integrations}
Known storage locations: {storage_locations}
Review scope: {review_scope}

Filled example:
Page or feature: Partner onboarding landing page with demo request form
Visitor inputs: Name, work email, company, region, free-text use case, consent checkbox
Known integrations: CRM form endpoint, analytics tag, calendar booking link
Known storage locations: CRM lead object and internal notification email
Review scope: Public pre-launch privacy and security review

Tasks:
1. Create a data-flow table with columns: Step, Data elements, Source, Destination, Trigger, Storage or transit only, Access roles, Retention question, Evidence, Assumption, Severity.
2. Identify hidden or implied flows, including analytics, email notifications, file links, embedded calendars, and authentication redirects.
3. Flag any field that could collect confidential, regulated, or unexpected sensitive information.
4. Provide reproduction steps for validating each flow manually.
5. State what evidence is still required from engineering, marketing operations, privacy, or the workspace admin.
6. Provide an approval recommendation and assign each open question to a human owner.

Explanation: The model should not invent destinations or storage behavior. Require it to label unknowns, because unsupported assumptions about where data goes are more dangerous than an incomplete inventory that clearly names the missing evidence.

12. Prompt: Secret, Token, and Confidential Information Exposure Check

Intended outcome: Detect visible secrets, internal URLs, unreleased product details, credentials, environment names, screenshots, customer identifiers, or confidential text before the page is shared with internal viewers, named external viewers, or the public. OpenAI’s Sites documentation emphasizes reviewing public or shared Sites for confidential information before distribution.

Variables to replace: {review_materials}, {known_secret_patterns}, {allowed_public_terms}, {sharing_mode}.

Act as a security reviewer checking for accidental exposure in website content and assets.

Review materials: {review_materials}
Known secret patterns or naming conventions: {known_secret_patterns}
Allowed public terms: {allowed_public_terms}
Planned sharing mode: {sharing_mode}

Filled example:
Review materials: Page copy, HTML snippets, visible JavaScript, screenshots, downloadable PDF, sample API response
Known secret patterns or naming conventions: sk-, pk_live, Bearer, internal-api, staging.company.local, customer IDs beginning CUST-
Allowed public terms: Published product names and public documentation URLs
Planned sharing mode: Named external viewers first, then public if approved

Tasks:
1. Inspect the materials for credentials, API keys, tokens, private URLs, customer data, employee-only instructions, unreleased pricing, internal project names, and confidential screenshots.
2. For each finding, provide Evidence, Exact location, Why it matters, Severity, Reproduction steps, and Recommended remediation.
3. Separate confirmed exposures from suspicious strings that require human verification.
4. Identify assets that should be regenerated, redacted, replaced, or removed.
5. Provide a final recommendation: safe to share, safe after redaction, or block.
6. Name the accountable human approver for security sign-off.

Explanation: This prompt is deliberately broad because secrets can appear in visible text, alt text, console examples, PDFs, screenshots, JSON samples, or pasted troubleshooting output. Treat “suspicious but unconfirmed” as a work queue for a security reviewer rather than a model-made determination.

13. Prompt: File Upload and Attachment Risk Review

Intended outcome: Evaluate whether file upload fields, screenshot attachments, resume submissions, document drop zones, or feedback uploads could collect more sensitive information than the team intends. OpenAI’s Sites guidance calls out uploaded files as a review area and states that Sites should not process protected health information or payment-card data except through an appropriate third-party payment processor.

Variables to replace: {upload_purpose}, {accepted_file_types}, {user_instructions}, {processing_path}, {prohibited_data}.

Review this file upload experience for privacy, security, and launch risk.

Upload purpose: {upload_purpose}
Accepted file types and limits if known: {accepted_file_types}
Visible user instructions: {user_instructions}
Known processing or storage path: {processing_path}
Prohibited data categories: {prohibited_data}

Filled example:
Upload purpose: Optional screenshot attachment for beta feedback
Accepted file types and limits if known: PNG or JPG; size limit not yet documented
Visible user instructions: "Attach a screenshot if helpful."
Known processing or storage path: Uploaded file is sent with feedback ticket to support queue
Prohibited data categories: Credentials, customer personal data, health information, payment-card data, confidential client systems

Tasks:
1. Identify foreseeable sensitive data that users may accidentally upload.
2. Evaluate whether the instructions clearly prohibit confidential, regulated, or payment-card information.
3. Flag missing safeguards, including file type explanation, size expectation, malware handling owner, access roles, deletion path, and support escalation.
4. Provide severity, evidence, assumptions, and reproduction steps for each issue.
5. Draft safer upload instructions in plain language.
6. End with required human approvals from privacy, security, legal, support, or product.

Explanation: The prompt asks for foreseeable misuse, not only intended use. If an upload field is optional, the safer launch decision may be to remove it until retention, access, malware handling, and deletion responsibilities are documented.

14. Prompt: Retention, Deletion, and Access Questions Before Launch

Intended outcome: Convert vague data handling into specific launch-blocking questions about how long data is kept, who can see it, how deletion requests are handled, and what evidence supports the answer. This is important because a page can look harmless while still creating long-lived records in CRM, analytics, email, logs, or support tools.

Variables to replace: {collected_data}, {systems_involved}, {current_policy_text}, {request_channels}.

Create a retention and deletion readiness review for this website.

Collected data: {collected_data}
Systems involved: {systems_involved}
Current policy or notice text: {current_policy_text}
Visitor request channels: {request_channels}

Filled example:
Collected data: Demo request details, consent checkbox state, analytics identifiers, calendar booking details
Systems involved: Website form handler, CRM, marketing automation, analytics dashboard, account executive email
Current policy or notice text: "We may contact you about your request."
Visitor request channels: [email protected] and support portal

Tasks:
1. Create a question register with columns: Data category, System, Retention period known?, Deletion process known?, Access owner, Evidence, Assumption, Severity, Human owner.
2. Identify where retention may differ across primary records, backups, logs, analytics, and email notifications.
3. Flag any missing visitor-facing explanation that could affect launch approval.
4. Provide manual verification steps for confirming retention and deletion behavior.
5. Recommend whether launch should proceed, proceed with documented exceptions, or wait for privacy approval.
6. Do not invent retention periods; mark them unknown unless evidence is provided.

Explanation: This prompt is valuable precisely because it forces “unknown” into the open. A model-generated retention period is not evidence; a policy, system configuration, vendor setting, or administrator confirmation is evidence.

15. Prompt: Third-Party Content, Brand, and Licensing Rights Review

Intended outcome: Identify images, icons, fonts, testimonials, logos, embedded media, datasets, quotes, partner names, and screenshots that may require permission before external sharing or public publishing. OpenAI’s Sites guidance includes third-party content rights as a pre-sharing review item.

Variables to replace: {content_inventory}, {planned_audience}, {known_permissions}, {brand_claims}.

Review this website for third-party content rights and brand-approval risk.

Content inventory: {content_inventory}
Planned audience: {planned_audience}
Known permissions or licenses: {known_permissions}
Brand, partner, customer, or testimonial claims: {brand_claims}

Filled example:
Content inventory: Customer logo strip, stock hero image, embedded YouTube video, analyst quote, product UI screenshot, icon set
Planned audience: Public launch page after named external stakeholder review
Known permissions or licenses: Stock image license unknown; customer logo permission pending; icon set from open-source package
Brand, partner, customer, or testimonial claims: "Trusted by Acme Bank" and a quote from a webinar attendee

Tasks:
1. Build a rights-risk table with Item, Location, Claimed owner, Permission evidence, License limits, Required attribution, Risk, Severity, Reproduction steps, and Human approver.
2. Flag content that should be removed or replaced before external review.
3. Identify claims that imply endorsement, partnership, certification, customer status, or performance proof.
4. Separate legal-rights questions from marketing-accuracy questions.
5. Draft a stakeholder approval checklist for brand, legal, marketing, and product.
6. Provide a launch recommendation without inventing permission status.

Explanation: This prompt prevents a common failure mode: treating a stakeholder preview as harmless even though external viewers can see unapproved logos, screenshots, or claims. Named external viewing is still disclosure to people outside the workspace.

16. Prompt: Keyboard Navigation and Focus Order Audit

Intended outcome: Check whether a user can operate the page with a keyboard alone, follow focus order, activate controls, escape overlays, and complete the primary task without a mouse. The prompt is not an accessibility certification; it creates a reproducible manual test plan and issue log.

Variables to replace: {page_url_or_flow}, {primary_tasks}, {components_to_test}, {browser_context}.

Create a keyboard-only accessibility review for this website flow.

Page or flow: {page_url_or_flow}
Primary tasks: {primary_tasks}
Components to test: {components_to_test}
Browser and device context: {browser_context}

Filled example:
Page or flow: Public demo request page
Primary tasks: Open menu, read pricing summary, complete form, submit request, recover from validation errors
Components to test: Header navigation, modal video, dropdown, form fields, consent checkbox, submit button, confirmation message
Browser and device context: Desktop Chrome and Safari; no mouse

Tasks:
1. Provide a step-by-step keyboard test script using Tab, Shift+Tab, Enter, Space, Escape, and arrow keys where relevant.
2. Create an issue table with Component, Expected behavior, Observed evidence to collect, Severity, Reproduction steps, Impacted users, and Fix suggestion.
3. Flag missing visible focus indicators, focus traps, skipped controls, unexpected tab order, keyboard-inaccessible menus, and modal escape failures.
4. Identify assumptions that require human testing.
5. Provide a pass, pass with fixes, or block recommendation for accessibility approval.

Explanation: Ask the model for a test script before asking for conclusions. Keyboard problems must be reproduced by a human tester, because screenshots and page descriptions often miss focus order, trapped focus, and interactive state changes.

17. Prompt: Color Contrast and Visual Hierarchy Review

Intended outcome: Review whether text, buttons, links, states, alerts, and visual emphasis are understandable without relying only on color or low-contrast styling. This helps designers and marketers separate aesthetic preference from usability risk before stakeholder approval.

Variables to replace: {screens_or_css}, {brand_constraints}, {critical_elements}, {known_user_contexts}.

Review color contrast and visual hierarchy for launch risk.

Screenshots, CSS tokens, or page description: {screens_or_css}
Brand constraints: {brand_constraints}
Critical elements: {critical_elements}
Known user contexts: {known_user_contexts}

Filled example:
Screenshots, CSS tokens, or page description: Hero page screenshot, form screenshot, error state screenshot, CSS color tokens for text, link, button, warning, disabled state
Brand constraints: Must use navy and electric blue; accent yellow is optional
Critical elements: Primary CTA, pricing caveat, consent checkbox label, validation errors, external-link warning
Known user contexts: Mobile visitors, low-brightness screens, older stakeholders reviewing projected slides

Tasks:
1. Identify text, links, buttons, icons, alerts, disabled states, and form errors that may have insufficient contrast or unclear emphasis.
2. Create a table with Element, Location, Evidence provided, Risk, Severity, Reproduction steps, and Design recommendation.
3. Flag places where meaning depends on color alone.
4. Evaluate whether the visual hierarchy supports the primary task or hides legal, privacy, pricing, or error information.
5. List measurements or tools a human designer should use to confirm contrast.
6. End with an approval recommendation and required design owner decision.

Explanation: The model can reason from screenshots and color tokens, but measured contrast should be verified with appropriate accessibility tools. Require the output to distinguish “needs measurement” from “confirmed failure” so the design team receives a testable action list.

18. Prompt: Screen-Reader Structure and Plain-Language Error Message Review

Intended outcome: Evaluate heading order, landmarks, labels, alt text, form instructions, error messaging, and confirmation messages so assistive-technology users can understand the page and recover from mistakes. This prompt also checks whether error messages are written in plain language rather than vague blame-oriented text.

Variables to replace: {page_structure}, {form_fields}, {error_messages}, {confirmation_states}, {approval_owner}.

Review screen-reader structure and plain-language messages for this website.

Page structure, headings, or HTML summary: {page_structure}
Form fields and labels: {form_fields}
Current error messages: {error_messages}
Confirmation or success states: {confirmation_states}
Human approval owner: {approval_owner}

Filled example:
Page structure, headings, or HTML summary: Header nav, hero H1, feature sections, FAQ accordion, demo request form, footer links
Form fields and labels: Name, work email, company, role dropdown, free-text message, consent checkbox
Current error messages: "Invalid input", "Required", "Something went wrong"
Confirmation or success states: "Thanks, we'll be in touch."
Human approval owner: Accessibility lead and product manager

Tasks:
1. Review heading sequence, landmark clarity, link purpose, button names, image alt text, form labels, required-field indicators, error association, and confirmation clarity.
2. Create an issue table with Item, Evidence, Assumption, Severity, Reproduction steps, Impacted users, and Recommended fix.
3. Rewrite each error message in plain language that states what happened, how to fix it, and what data the user should not enter if relevant.
4. Flag vague messages, visual-only instructions, placeholder-only labels, repeated link text, unlabeled icons, and ambiguous confirmation states.
5. Identify what must be tested with a screen reader by a human reviewer.
6. End with an accountable approval decision: approve, approve after copy and markup fixes, or block pending accessibility review.

Explanation: This prompt links structure and copy because inaccessible forms often fail in both places: the markup does not expose the right relationship, and the text does not tell the user how to recover. Keep the final decision with an accessibility owner, especially when the flow collects visitor data or handles external stakeholder submissions.

Prompts 19–25: External Acceptance, Sign-Off, Launch Control, and Post-Change Governance

Use the final seven prompts after functional, privacy, and accessibility findings have been triaged, because these prompts turn review evidence into accountable launch decisions. OpenAI documents that ChatGPT Sites can be owner-only, internally shared, shared with named external viewers, or public when the workspace permits it; that makes the approval record as important as the technical test result, especially when a Site will be shown to clients, partners, prospects, or the public.

19. Prompt: External Client Acceptance Test for Named Viewers

Intended outcome: Confirm whether an external client, reviewer, agency, or partner can complete the intended acceptance test without gaining broader workspace access, editing rights, or publishing rights. This is especially relevant because OpenAI states that named external viewers receive view-only access, do not join the workspace, and cannot edit or publish the Site.

Variables: {site_name}, {external_viewer_role}, {test_scenarios}, {audience_setting}, {known_limitations}, {evidence_links}.

Act as an external client acceptance-test coordinator for {site_name}.

Context:
- External viewer role: {external_viewer_role}
- Intended audience setting: {audience_setting}
- Test scenarios: {test_scenarios}
- Known limitations or exclusions: {known_limitations}
- Evidence available: {evidence_links}

Produce:
1. A client acceptance-test checklist grouped by scenario.
2. The evidence the client must capture for each pass/fail result.
3. Any assumptions about access, authentication, device, browser, or region.
4. Severity for each failed scenario: blocker, high, medium, or low.
5. Reproduction steps for every failure.
6. A sign-off question requiring a named human decision: accept, accept with exceptions, or reject.
7. A warning if the test appears to rely on edit, publish, workspace membership, or public access when the expected mode is named external viewing.

Filled example: Use {site_name} as “Partner Demo Portal,” {external_viewer_role} as “client procurement reviewer,” {audience_setting} as “named external viewers only,” and {test_scenarios} as “open the demo, review pricing disclaimer, submit non-sensitive inquiry form, download public PDF.” Ask the model to flag any scenario that would expose internal drafts, confidential uploaded files, or workspace-only links.

Explanation: The prompt separates acceptance testing from permission testing. A client can approve the experience only if the intended viewer path works; the workspace owner or admin must still verify that the sharing configuration is correct and that alternate audience settings do not keep the Site reachable after a direct invitation is removed.

20. Prompt: Stakeholder Sign-Off Packet

Intended outcome: Convert QA, privacy, accessibility, and business-review evidence into a packet that non-technical stakeholders can approve without losing traceability. Use this prompt when legal, security, marketing, sales, product, or executive reviewers need a concise decision record rather than a raw bug list.

Variables: {release_scope}, {stakeholders}, {open_findings}, {resolved_findings}, {launch_date}, {decision_options}.

Act as a release-governance editor preparing a stakeholder sign-off packet for {release_scope}.

Inputs:
- Stakeholders: {stakeholders}
- Open findings: {open_findings}
- Resolved findings with evidence: {resolved_findings}
- Target launch date: {launch_date}
- Allowed decision options: {decision_options}

Create:
1. A one-page approval summary.
2. A table of open findings with severity, owner, business impact, user impact, and recommended decision.
3. A table of resolved findings with evidence and verifier.
4. A list of assumptions that stakeholders are being asked to accept.
5. A list of decisions that require legal, privacy, security, accessibility, or executive approval.
6. Reproduction steps for any unresolved user-visible issue.
7. A final sign-off block naming the accountable human approver for each function.

Filled example: Use {stakeholders} as “VP Marketing, Product Owner, Security Lead, Privacy Counsel, Support Manager” and {decision_options} as “approve, approve with documented exception, defer launch.” The output should make it obvious that a marketing approval does not substitute for privacy or security approval.

For Stakeholder Approval Workflow, The Complete Guide to Codex Approval Policies — Controlling AI Autonomy in Enterprise Environments is the most relevant adjacent resource. The Codex approval-policy guide explains bounded authority and explicit approval conditions, helping teams turn a vague stakeholder sign-off into an accountable release gate.

21. Prompt: Risk Acceptance Memo for Unresolved Findings

Intended outcome: Document a conscious decision to launch with a known issue, defer a fix, or restrict availability. This prompt is not a way to downgrade serious findings; it is a way to make the accountable owner, expiration date, compensating control, and review trigger explicit.

Variables: {finding_id}, {finding_description}, {severity}, {affected_users}, {compensating_controls}, {expiration_date}, {risk_owner}.

Act as a risk-review facilitator. Draft a risk acceptance memo for {finding_id}.

Finding:
- Description: {finding_description}
- Severity: {severity}
- Affected users or visitors: {affected_users}
- Evidence and reproduction steps: [paste evidence]
- Proposed compensating controls: {compensating_controls}
- Risk owner: {risk_owner}
- Expiration or re-review date: {expiration_date}

Return:
1. A plain-language risk statement.
2. Why this is or is not acceptable for the planned audience.
3. Required evidence before acceptance.
4. Assumptions and dependencies.
5. Conditions that automatically revoke acceptance.
6. Mitigation tasks, owners, and due dates.
7. A final approval line for the named risk owner.

Filled example: For a low-severity issue, use “decorative image lacks ideal alternative text but page content remains understandable” and set a two-week remediation date. For a high-severity issue, such as a form collecting unnecessary personal data without disclosure, instruct the model to recommend “do not accept without privacy approval and remediation,” not to rationalize the launch.

Explanation: The memo should preserve the original severity and evidence. A risk owner can accept business risk, but cannot turn the prompt into legal advice, privacy certification, security assurance, or accessibility conformance proof.

22. Prompt: Rollback and Takedown Readiness Review

Intended outcome: Verify that the team can stop, restrict, or reverse a problematic launch quickly. OpenAI’s Sites documentation distinguishes sharing modes, including public and named external access, so rollback planning should include both technical deployment steps and audience-control changes.

Variables: {site_name}, {current_audience}, {rollback_trigger}, {rollback_owner}, {communications_channels}, {verification_steps}.

Act as a launch-readiness reviewer for rollback and takedown planning.

Site: {site_name}
Current or planned audience: {current_audience}
Rollback triggers: {rollback_trigger}
Rollback owner: {rollback_owner}
Communications channels: {communications_channels}
Existing verification steps: {verification_steps}

Produce:
1. A rollback checklist ordered by urgency.
2. Audience-control actions to verify, including public, workspace, group, and direct external invitations where relevant.
3. Evidence required to prove the Site is no longer reachable by unintended viewers.
4. Communications drafts for internal teams and affected external stakeholders.
5. Assumptions that must be manually verified by the Site owner or workspace admin.
6. Severity mapping from incident trigger to rollback action.
7. A final go/no-go recommendation for rollback readiness.

Filled example: Use {rollback_trigger} as “confidential roadmap text found in a public page, broken lead form for all visitors, or privacy notice mismatch.” Ask the model to produce separate actions for “restrict to owner/admins,” “remove named external viewer,” and “verify the URL from a fresh session,” without assuming one action removes every possible access path.

Explanation: OpenAI warns that removing a direct invitation does not necessarily remove access granted through another audience setting. This prompt therefore requires independent verification after each sharing change, such as checking the intended visitor experience from the relevant signed-in or signed-out context.

23. Prompt: Website Incident Simulation Tabletop

Intended outcome: Rehearse how the team would respond to a privacy, security, availability, misinformation, or accessibility incident before launch. The simulation should produce decisions, evidence gaps, and escalation paths rather than a theoretical incident-response essay.

Variables: {incident_scenario}, {site_audience}, {data_collected}, {response_team}, {time_constraints}, {regulatory_or_contractual_concerns}.

Act as an incident tabletop facilitator for a website launch.

Scenario: {incident_scenario}
Audience: {site_audience}
Data collected or displayed: {data_collected}
Response team: {response_team}
Time constraints: {time_constraints}
Regulatory or contractual concerns: {regulatory_or_contractual_concerns}

Run the tabletop:
1. Timeline the first 15 minutes, first hour, and first business day.
2. Identify required evidence, logs, screenshots, form submissions, and configuration records.
3. Assign roles for containment, communications, legal/privacy review, technical remediation, and executive updates.
4. List assumptions that must be validated.
5. Classify incident severity and explain why.
6. Provide reproduction or confirmation steps.
7. End with accountable human decisions: contain, continue monitoring, notify stakeholders, or take down.

Filled example: Use “an external reviewer reports that a shared Site exposes an internal-only link and a form field requests unnecessary personal information” as {incident_scenario}. Include privacy counsel and the workspace admin in {response_team}, because the response may require both content remediation and access-setting verification.

Explanation: This prompt aligns the launch team before pressure arrives. It should not claim whether a notification law applies; it should identify which facts counsel or privacy professionals need to decide notification, contractual reporting, or takedown obligations.

24. Prompt: Access Recertification After Sharing Changes

Intended outcome: Reconfirm who can reach the Site after any permission, audience, role, workspace, group, or external-invitation change. This matters because Enterprise and Edu administrators must enable Sites for relevant roles and separately enable the permission to invite external visitors, while Site-level sharing may still create multiple paths to access.

Variables: {site_name}, {intended_access_matrix}, {recent_changes}, {test_accounts}, {admin_controls}, {exceptions}.

Act as an access recertification analyst for {site_name}.

Inputs:
- Intended access matrix: {intended_access_matrix}
- Recent sharing or role changes: {recent_changes}
- Test accounts or viewer personas: {test_accounts}
- Relevant admin controls: {admin_controls}
- Approved exceptions: {exceptions}

Create:
1. A recertification test plan by persona.
2. Expected result and prohibited result for each persona.
3. Evidence to capture for successful and failed access attempts.
4. Assumptions about workspace membership, named external viewer status, public access, and sign-in state.
5. Severity for each mismatch.
6. Reproduction steps for any unintended access or unintended denial.
7. A human approval statement for the Site owner and, where required, workspace admin.

Filled example: Use personas such as “owner,” “workspace admin,” “internal viewer,” “named external client,” “former external client,” and “anonymous signed-out visitor.” Ask the model to treat “former client can still access through public sharing” as a critical recertification failure if the intended audience is named external viewers only.

Explanation: Access recertification should test the actual experience, not just the intended configuration. The prompt also forces teams to distinguish Site audience controls from any authentication behavior built into the Site itself; both can affect visitor experience, but they are not the same control.

25. Prompt: Final Publish or No-Publish Decision

Intended outcome: Produce a launch decision that weighs evidence, unresolved findings, access mode, privacy posture, accessibility status, rollback readiness, and accountable approvals. This prompt should be used only after the team has gathered actual test results and reviewed sensitive-use restrictions.

Variables: {launch_scope}, {audience}, {evidence_packet}, {open_risks}, {required_approvals}, {rollback_status}, {decision_deadline}.

Act as a release decision chair. Make a publish/no-publish recommendation for {launch_scope}.

Inputs:
- Planned audience: {audience}
- Evidence packet: {evidence_packet}
- Open risks: {open_risks}
- Required approvals: {required_approvals}
- Rollback readiness: {rollback_status}
- Decision deadline: {decision_deadline}

Return:
1. Recommendation: publish, publish with restrictions, delay, or do not publish.
2. The evidence supporting the recommendation.
3. Blockers that must be resolved before publication.
4. Non-blocking issues and accepted risks.
5. Assumptions and missing evidence.
6. Required human approvers and the exact decision each must make.
7. Post-publication monitoring and rollback triggers.
8. A short executive summary that does not overstate compliance, privacy, security, or accessibility assurance.

Filled example: Use {audience} as “public visitors” and include an open issue stating “form collects contact details, but privacy notice has not been approved.” The expected model behavior is to recommend delay or restricted launch pending privacy approval, not to treat the issue as cosmetic because the site otherwise works.

Explanation: The final decision prompt should be conservative when evidence is missing. OpenAI’s Sites guidance calls for review of confidential information, uploaded files, forms, links, authentication behavior, third-party content rights, and visitor data collection before public or shared use, so a launch recommendation should reflect those review categories explicitly.

Prompt-Composition Framework for Approval-Grade Website Reviews

Build each review prompt from six components: role, scope, evidence, decision criteria, output format, and approval owner. The role tells ChatGPT whether to behave like a QA analyst, privacy reviewer, accessibility auditor, incident facilitator, or release chair; the scope prevents the model from reviewing unrelated pages; the evidence section prevents speculation; the decision criteria align findings to severity; the output format makes results comparable; and the approval owner preserves human accountability.

Recommended decision rule: If the prompt cannot name the Site, audience, evidence source, severity scale, and accountable human approver, it is not ready for a launch decision.

For ChatGPT Sites reviews, include the intended sharing mode in every launch-stage prompt: owner/admin only, internal, named external viewers, or public. This matters because external viewers can use a Site without receiving edit or publish rights, while public publishing and external invitations are controlled separately by workspace permissions and role-based access controls.

Evidence Standards for Findings and Approvals

Severity Rubric for Launch Decisions

Human-Approval Workflow for Shared or Public Sites

1. Site owner prepares evidence: Collect QA results, access tests, privacy notes, accessibility findings, stakeholder comments, and rollback steps before asking for approval.
2. Functional owner verifies behavior: Product or QA confirms that core journeys, forms, links, and responsive behavior match the release scope.
3. Privacy and security review exposure: Review forms, uploaded files, links, confidential text, third-party content, authentication behavior, and visitor data collection before sharing externally or publicly.
4. Accessibility reviewer checks barriers: Validate keyboard use, focus order, contrast, headings, labels, and error messages; treat ChatGPT output as triage support, not certification.
5. Workspace admin verifies policy where required: For Enterprise or Edu workspaces, confirm that Sites availability, public publishing, and external-invitation permissions match the intended role policy.
6. Risk owner accepts or rejects exceptions: Any unresolved medium, high, or blocker-class issue must have an owner, expiration date, mitigation, and explicit decision.
7. Release chair records publish/no-publish: Publish only when required approvals, evidence, access recertification, and rollback readiness are complete.

Conclusion

Prompts 19–25 move the review process from “the Site appears to work” to “the right people have accepted the right evidence for the right audience.” That distinction is critical for ChatGPT Sites because sharing choices can range from private owner access to named external viewers to public publication, and each choice changes the privacy, security, accessibility, support, and rollback obligations.

The safest operating pattern is to make ChatGPT-5.5 or ChatGPT Work structure the review, summarize evidence, identify assumptions, and expose missing approvals, while humans retain responsibility for legal, security, privacy, accessibility, administrative, and launch decisions. If a prompt cannot produce reproducible evidence, severity, assumptions, and a named accountable approver, it should inform the team but not decide the launch.

Useful Links

• OpenAI Developers: Codex Sites
• OpenAI Help: Creating and managing ChatGPT Sites
• OpenAI Help: Managing ChatGPT Sites for your workspace