# Turn search demand into a content experiment

Search queries can reveal a question your existing page almost answers. Use
that evidence to prepare one content change with a clear hypothesis and a way
to evaluate it. A useful result is a reviewable brief grounded in observed
search demand, with the limits of the measurement visible.

## Before you start

- Create a project for the website and review its audience and primary outcome
  in the [getting-started guide](/docs/getting-started.html).
- Have read-only Search Console access to a verified property covering the
  project URL. Confirm whether you need a domain property or a URL-prefix property.
- Confirm that your deployment has configured an approved Google OAuth
  application and enabled the required Search Console access.
- Have a person or separately configured publishing path that can review and
  ship the proposed content change.

**Search Console is a guided connector.** Its readiness depends on deployment
configuration and your property access. Inspect the current
[integration setup](/docs/integrations.html) before expecting a working
connection. Self-hosted operators can use the repository's
[OAuth operations runbook](https://github.com/leanderme/tractionscout/blob/main/docs/operations/google-search-console-oauth.md).

## Build the hypothesis from the observed query

1. In **Configure → Data Sources**, connect Google Search Console and select
   the exact property that covers your project website.
2. Synchronize and inspect the lookback window, query and page coverage,
   freshness, sitemap results, and any URL-inspection limitations. Missing
   observations are unknown, rather than zero.
3. Open **Search** within **Performance**, or find it through workspace search
   (⌘K or Ctrl+K). Examine a query/page pair with enough relevant evidence to
   discuss. Read the actual page before deciding what should change.
4. Ask Scout to prepare a hypothesis with the page, query intent, observed
   evidence, proposed change, expected mechanism, baseline, and guardrails.
5. Review the content brief or repository change in the action queue. Reading
   Search Console does not authorize publication; ship through your configured
   review and publishing process.
6. Record what shipped and when. Compare the declared before-and-after windows
   once the observation period has completed.

## Worked example: answer a setup question sooner

This is **synthetic teaching data**, not a traffic forecast. Over a completed
28-day period, a page about activation reporting has 5,000 impressions and
100 clicks for a relevant setup query: a 2% click-through rate. Its recorded
average position is 6.8. These observations alone do not prove a snippet or
content problem; relevance, position, device, country, and competing results
can all affect the outcome.

On inspection, the page describes the reporting concept but buries setup
instructions. A useful brief could look like this:

| Part of the brief | Proposed decision |
| --- | --- |
| Question | Can visitors quickly learn how to configure an activation report? |
| Change | Add a concise setup section and a relevant link to the implementation guide. |
| Mechanism | Give searchers a clearer answer and a direct path to completing setup. |
| Primary observation | Completed setup from visitors entering through this page, where first-party measurement is available. |
| Search observations | Query/page clicks, impressions, CTR, and average position with device and country context. |
| Guardrails | Accurate instructions, accessible content, no loss of the page's existing useful explanation. |

For this example, record the previous 28 completed days and a comparable
28-day period after publication and indexing. Choose the actual window based
on traffic and measurement needs, and record other releases or seasonal
effects. If first-party setup measurement is missing, retain that as a gap;
Search Console clicks cannot substitute for completed customer outcomes.

## What a useful first result contains

Save the source query and page evidence, the hypothesis, a concrete reviewable
change, and the measurement plan. After shipment, retain the outcome even when
the result is inconclusive. A before-and-after comparison is descriptive unless
the measurement design supports a stronger causal claim.

Do not turn a generic CTR benchmark into an invented traffic forecast. The
point of the exercise is to make a reasoned, measurable decision from the
evidence available to this project.

## Continue with the right next step

[View the read-only analytics demo](/tractionscout/demo) to explore real,
privacy-preserving aggregate traffic from TractionScout.com. For a tour of the
broader growth workspace, see the [synthetic product walkthroughs](/#product).
The setup action below carries this content-experiment question into onboarding
for review. If your next question concerns the quality of signups after they
arrive, continue with the
[activation and revenue workflow](/workflows/posthog-stripe-readout.html).


## Setup guides

- [Set up your project](https://tractionscout.com/docs/getting-started.html)
- [Check Search Console availability](https://tractionscout.com/docs/integrations.html)

## Start with this question

Which content change is worth testing next?

[Prepare my content experiment](https://tractionscout.com/signup/tractionscout?workflow=search-console-content-experiment)

Your workflow is carried into setup. Review the project, sources, and request before starting a run.

## Related workflows

- [Understand activation and revenue together](https://tractionscout.com/workflows/posthog-stripe-readout.md): Compare PostHog activation with Stripe payment and subscription evidence to choose a useful next growth move.
- [Prepare growth work from an external agent](https://tractionscout.com/workflows/agent-cli-automation.md): Use the Agent CLI or MCP to inspect project capabilities and stage evidence-backed work inside the project's approval policy.