ChatGPT search history is not chat history

Two very different kinds of history

Chat history preserves a conversation. Search history, in the narrow Open Queries sense, preserves only eligible web-search strings that the provider exposes during retrieval.

The distinction is structural rather than cosmetic: the event schema has no fields for message text, conversation titles, account identity or conversation URLs.

The word history is overloaded. ChatGPT conversation history is the user's archive of conversations and account activity. Browser history is the browser's record of visited pages. A web-search query history is narrower: it records explicit search strings surfaced while a supported AI interface uses web search. Treating those three stores as interchangeable creates both privacy risk and analytical confusion.

A query-history tool should make its narrow object visible in the product name, settings and exports. Someone reviewing a record should be able to tell that it came from a provider search event, not from the person's prompt or from every URL they visited. The distinction should survive even when a CSV leaves the extension.

This also limits the SEO claim. Query history can reveal retrieval vocabulary and recurring constraints in the captured sample. It cannot describe everything users asked, every source the provider considered or every search the provider executed.

Is ChatGPT search history public?

No. ChatGPT conversation history is tied to the account or workspace and is not publicly browsable by default. A conversation becomes visible to someone else only when the user deliberately creates or sends a shared link, or shares it through an eligible managed workspace. OpenAI says a personal-account link can be opened by anyone who has that link, while managed-workspace links remain subject to workspace access rules.

Open Queries creates a different record: a 30-day browser-local trace of eligible web-search strings surfaced during retrieval. That trace is not a public profile or a copy of the user's chats. Optional query contribution is off by default and sends only the minimized query-event fields described in the privacy policy, never surrounding conversation content.

What appears in the local trace

Each eligible entry contains the minimum information needed to understand and audit the query observation.

Minimize fields before optimizing analytics. The default record needs the provider, query text, timestamp, evidence class and enough adapter context to explain how the event was identified. A stable event identifier may support deduplication, but a full prompt is not required to analyze the search string.

Retention should match the job. A short local window helps a practitioner review recent sessions without creating a permanent behavioral archive. A longer accepted telemetry window may support aggregate product health only when the fields, purpose and deletion path are explicit. Local and accepted remote storage should never be described as the same thing.

Exports need the same provenance labels as the interface. Removing the evidence class or provider during export makes downstream misuse predictable: estimated queries get counted as observed and records from different interfaces are compared without qualification.

• The surfaced search query.
• Provider and evidence class.
• Capture time and adapter version.
• A 30-day local retention boundary with a 2,000-entry limit.

What stays outside

The extension does not build a conversation archive. It does not require the user's prompt to understand whether a provider emitted an explicit search-tool query.

The strongest privacy statement is a verifiable negative contract. Conversation prompts, response bodies, page content and unrelated browsing activity are unnecessary for the query-history job and should remain outside collection. Passwords, form values and cookies are also outside scope and should not become accidental debugging payloads.

Avoid deriving sensitive categories from query strings. A surfaced query can contain personal or confidential terms because it reflects the task at hand. Search, filtering and deletion can operate on the literal record without adding inferred health, political, employment or identity labels.

Debugging should preserve the contract. When an adapter breaks, collect version and failure state rather than nearby DOM text. A temporary diagnostic that captures more content can become a permanent undeclared data path unless the boundary is enforced in code and tests.

How to use the trace responsibly

A local trace is useful when the goal is to compare retrieval language across supported searches without turning the browser into a surveillance tool.

Begin with a bounded review window and one question, such as “Which comparison criteria appeared while researching our enterprise plan page?” Filter to the relevant provider and canonical, deduplicate exact repeats and classify the remaining queries by function. Do not browse an employee's entire trace looking for an interesting story.

Create a short evidence memo with counts, representative rows, missing coverage and rejected rows. Rejections matter: branded navigational searches, unrelated tasks and ambiguous strings should not enter the page brief merely because they occurred.

Translate accepted evidence into research tasks rather than phrases to insert. A query about data residency becomes a request to verify hosting regions, subprocessors, contractual coverage and limitations from primary documentation. The final article cites those sources, not the private query trace.

1. 01
   Review privacy

   Accept the explicit privacy boundary before query views and estimates unlock.

2. 02
   Inspect locally

   Use Current and History views to compare eligible surfaced searches.

3. 03
   Export the insight, not the chat

   Carry concepts and qualifiers into an editorial brief without copying conversations.

4. 04
   Clear when needed

   Delete the local trace or rotate the anonymous server identifier from Settings.

Limits and terminology guardrails

A missing query does not prove that ChatGPT did not search; the interface may not expose every action, and an adapter may fail closed after a provider change. A retained query also does not identify a person or reveal the surrounding conversation.

An interface event can be absent because the provider did not search, because the mode was unsupported or because the adapter could not safely identify the event. These cases are observationally different but may look identical in the history. The product must report the boundary instead of claiming completeness.

A history record can contain confidential language even when conversation text is excluded. Teams should apply access control, retention, deletion and export handling appropriate to the query data itself. Data minimization reduces risk; it does not make every captured query harmless.

Use a field contract that a privacy reviewer can audit

The contract should be understandable without reading implementation code. It names the field, its purpose, storage boundary and deletion behavior, then links to the public architecture for verification.

Worked example: audit a comparison session without reading the chat

A practitioner researches AI visibility tools. The narrow history shows surfaced searches for citation monitoring, referral attribution, prompt tracking and query inspection. It does not store the user's prompt, the assistant's recommendation or unrelated tabs.

The practitioner maps the four query classes to the comparison page. Query inspection is supported and documented; continuous citation monitoring and rank tracking are not. The editorial result is not to imply broader coverage. The page instead adds a boundary table that explains which evidence Open Queries provides and which instruments a team needs for the remaining jobs.

That outcome is strategically useful because it improves qualification. Readers looking for a full monitoring suite can self-select out, while teams needing provider-query evidence can understand the exact fit and install with accurate expectations.