Send an AI visitor through your website regularly.

What the AI will do

• Builds a recurring team of website visitors: agents that look for bugs, unclear writing, weak design and obstacles to AI access across busy pages and forgotten corners.
• Sets up reports on your chosen schedule, then develops bigger ideas for how AI could make the site more useful—including answers and experiences tailored to individual visitors.

What you can provide

• A website or customer service app, and whatever you know about its visitors and purpose.
• Available access to analytics, customer feedback, site tools and test accounts; the AI checks the connections before asking you to assemble anything.

Where you'll take part

• Choose the scope, report topics and cadence, and which content you want AI services to reach or use for training.
• Review the first findings and choose a larger redesign or personalized experience to explore.

What you'll get

A tested recurring website review system, an initial set of reports and a prototype or concrete design for a more useful AI-powered experience. If scheduling or site access is unavailable, you receive a repeatable first-run review with the exact setup needed to make it ongoing.

Activity context

Your busiest landing page deserves attention. So does the obscure page nobody on your team has opened in two years. A team of AI visitors can make website quality control a standing activity, from finding broken forms to asking a much larger question: what could this whole experience become now that AI can participate in it?

For the user

Give the AI your site or customer service app and a little context about what it should do for people. It will investigate the site and visitor evidence, run the first checks and build the recurring work where tools allow. You choose what the agents cover, when you hear from them, your AI-access preferences and which bigger ideas to pursue.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

Learn what the site is for and what visitors experience

Help me make website quality control an ongoing activity, using a team of agents that repeatedly explores the whole site, reports useful findings and periodically rethinks the experience around current AI capabilities. Apply the same method to a customer service app if that is my starting point.

Inspect the supplied site and available connections. Search relevant customer emails, support chats, other messages, customer-interview and team-meeting transcripts, analytics, internal site discussions, design documents, content guidance and previous issue reports. Use them to identify visitor groups, their questions and goals, journeys that matter, recurring frustrations and existing decisions. Keep documented visitor needs distinct from simulated reactions.

Build a site inventory from the sitemap, navigation, crawlable links, content system and route definitions where accessible. Use analytics to distinguish heavily visited pages from little-used ones; do not infer traffic from prominence in navigation. Include obscure pages, downloads, old campaign routes and states reached through search, forms or authentication. If analytics is absent, label traffic unknown and use a deliberate mix of prominent and deep routes until it is available.

Check browser, code, analytics, issue-tracking and scheduling capabilities by trying relevant access. If a connection is missing, investigate setup or permitted exports before asking me for a specific action. Read-only access can support the first review; explain what additional access enables. If needed, offer to draft an IT request. A one-time chat cannot be described as a permanent service without a real scheduler and operating environment.

Agree on coverage and reporting

Show a proposed coverage map, including visitor tasks, pages, devices, account roles and page states. Ask me to confirm the initial scope and useful report schedule: for example, daily bugs, weekly content improvements and quarterly design or strategy reviews. Let me choose other topics and cadences. Establish which test actions may run on the live site and which require a test environment or test accounts; keep real purchases and messages outside unattended exploratory checks.

Create a work queue that gives important journeys frequent checks while rotating through obscure pages until the inventory is covered. Record the last visit and next due check for each assignment. Set a practical run size, concurrency and request budget so “always on” means dependable recurring coverage rather than an uncontrolled stream of requests.

Build the visitor team and run a baseline

Use separate agents where available, with explicit page sets, visitor evidence, permitted actions, source references and required outputs. Run successive waves when capacity is limited. Without subagents, use separate bounded passes and preserve their findings before synthesis. Include these jobs:

• Bug visitors: attempt real user journeys and inspect links, forms, search, navigation, errors, downloads and relevant mobile or authenticated states. Save reproduction steps, expected and actual behavior, affected route and screenshot or other evidence. Cover both the busiest and most obscure routes.
• Writing reviewer: read all in-scope copy over successive runs, using the coverage record to prevent omissions. Identify confusing terms, buried answers, contradictions and unclear calls to action. Draft specific before-and-after improvements, preserving intended claims and meaning.
• Design reviewer: inspect rendered pages for impact and clarity: what catches attention, whether the purpose is apparent, whether the next action is understandable, and whether layout helps a visitor complete the task. Use screenshots and actual interactions; distinguish a reproduced usability problem from an aesthetic judgment or simulated reaction.
• AI-access reviewer: examine which content external AI systems can reach and which content we want them to reach, using the dedicated method below.
• AI-experience explorer: investigate where an embedded assistant, guided interaction or individual adaptation could help people get answers faster or complete a service more easily. Ground ideas in visitor tasks and evidence rather than adding a chat box by default.

Have each return findings in a common record: page or journey, job performed, evidence, visitor impact, proposed improvement and uncertainty. Track unvisited routes and untested states. Deduplicate findings while retaining distinct causes. Have an independent reviewer reproduce a sample of bugs and inspect the evidence for major recommendations; simulated visitors do not establish how actual customers will react. Repair test errors and mark claims that remain unverified.

Make deliberate choices about AI reachability

Search current publishing, content-licensing, privacy and access policies, plus related site-owner decisions. Inventory public content we want discoverable, public content we do or do not want considered for future model training, and restricted content. Ask me or the relevant owner to resolve unclear preferences before changing settings.

Keep search discovery, user-requested fetching, model-training preferences and actual authentication separate. Provider rules differ; refresh their official documentation when implementing the choices. As checked September 13, 2026:

• OpenAI documents independent controls for OAI-SearchBot, used for search, and GPTBot, whose crawls may be used for training. ChatGPT-User handles certain user-initiated visits, for which robots.txt may not apply. See OpenAI crawler documentation.
• Google's Google-Extended token controls specified training and grounding uses, does not change inclusion in Google Search, and is not a separate HTTP user agent. See Google's crawler documentation.
• robots.txt expresses crawler instructions; it does not enforce confidentiality. Google also explains that a disallowed URL can still appear in search. Restrict private material through actual authenticated access. See Google's robots.txt guidance.

Inspect actual robots.txt rules, indexing directives, authentication, response status, firewall or CDN rules, readable page content and relevant request logs. Test representative permitted and restricted routes, including logged-out access. Record what the response and logs demonstrate; merely changing a user-agent string does not prove a provider can reach the page. An allowed crawl is not proof of future training inclusion, indexing or citation.

Produce a page-class-by-provider map of intended and observed behavior. Prepare specific corrections, implement the authorized ones and recheck affected routes. Preserve the user's choice to make suitable public material available for future training as well as their choice to exclude material.

Turn the first run into an ongoing service

Build the recurring jobs in an available approved runner, retaining the coverage queue, results and run history between sessions. Connect the chosen reporting destination within my authorized scope. Reports should distinguish new, repeated, fixed and uncertain findings, show coverage and failed runs, and link each actionable finding to evidence. Match each report's topic and cadence to my choices; establish who receives urgent failures and who acts on improvements.

Run a complete cycle and inspect the resulting reports. Verify that the next scheduled execution is configured and that a test invocation reaches its intended destination. Provide a simple way to pause or change the schedule. If scheduling or delivery cannot be connected, supply the repeatable checks, first reports and the precise remaining setup, clearly labeled as not yet ongoing.

Periodically rethink the whole experience

Create a recurring or on-demand session for a more radical question: given what AI can do now, how should this site or customer service app work? At each session, review fresh visitor evidence and verify relevant current capabilities in primary documentation. Brief separate agents to develop genuinely different interactions, then reconcile them against the same visitor goals and evidence.

Include ways to embed AI so visitors reach answers more quickly, and a version of the experience tailored to the individual. Explore adaptation based on what a visitor explicitly tells us, their chosen preferences or permitted account context; an IP address is not an individual identity. Show which parts change—content, explanations, navigation, tools or service steps—and how someone can correct their context or return to the standard experience.

Present concrete sketches of the strongest alternatives and the questions a trial would answer. Ask me which to explore. Build a prototype with test data where tools permit, or a detailed interaction walkthrough when they do not. Compare it with the current journey using representative tasks; propose a small real-user trial to establish whether it helps. Deliver the chosen prototype or walkthrough alongside the recurring review system, its initial findings, coverage record and next review date. Stop at the agreed implementation and prototype scope.

Done when

The first review has produced evidenced findings across the agreed coverage, the recurring system has been tested or its missing setup is clearly identified, and you have a concrete AI-enabled experience to examine alongside the routine improvements.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.