Search and AI discovery fundamentals

A ranking is a position on a page. It is not money, and it is not a reader. Everything that decides whether the work was worth doing sits in between: whether the query attracts people who can buy, whether the page answers them once they arrive, whether the next step is obvious. Skip that and you can spend six months moving a keyword from 14 to 4 for a question nobody profitable ever asks.

Name one outcome you can observe, and one number that would prove the win was hollow.

What counts as an outcome

An outcome is an action a person takes that the business would pay to cause. A form submission, a call, a subscription, a booking, an application, an order. It has to be visible in a system somebody can open. If nobody can point at the row where it happened, it is a hope rather than an outcome.

Engagement is not an outcome. Time on page, scroll depth, and bounce rate describe behavior on the way to something else. They earn their keep when you are diagnosing a page that fails. They prove nothing about a page that worked. Keep them in the middle layer of the tree, where they belong.

An assigned value is a business assumption. Putting $350 against a consultation request is a decision somebody made, and it should be recorded as one. When the report later says $177,300 of assigned value, every person reading it needs to know that figure came out of a multiplication rather than a bank statement.

When the outcome exists but you cannot see it yet, write that down instead of substituting something easier to reach. "Signed cases: unknown, no CRM source connected" is a stronger line in a report than a lead count quietly standing in for revenue. It tells the reader exactly how far the evidence reaches, which is the only thing that makes the rest of it trustworthy.

Why this cannot wait until later

Every decision after this one inherits it. Keyword qualification needs a rule for what disqualifies a term, and that rule comes from the outcome. Choosing a page type needs a definition of the task being served. Prioritizing two fixes means comparing them against something, and if there is no target, the comparison is a preference dressed up as analysis.

Teams who skip it end up with a queue sorted by whichever tool shouted loudest. The audit returns 340 issues. The keyword tool returns 10,000 rows. Both look like work, and neither can tell you which one matters, because neither of them knows what you were trying to change.

Write the outcome statement

Four lines, written once, referenced by everything downstream. It should read like something a person who does not work in search could repeat back to you.

1. Name the site and the audience.Write who the visitor is and what decision they are trying to make. A page for someone comparing three firms is a different page from one built for someone who already chose you.
2. Choose one primary outcome.One. Listing five is a way of avoiding the choice, and it leaves every later trade-off unresolvable, because two of the five will always point in opposite directions.
3. Choose one guardrail.Ask which number would have to move the wrong way for the win to be fake. Lead quality, revenue per visit, return rate, engaged time. That number is the guardrail.
4. Write down what you cannot measure.State the gap and what would close it. This is the sentence that keeps the report honest in six months, when someone asks whether any of it turned into revenue.

Four systems have to succeed in order before a page earns anything, and each one fails in its own way. A crawler has to request the URL and get a usable response. An index has to store it and pick it as the canonical. A ranking system has to consider it for a query. Where an answer engine is involved, it has to retrieve the page and actually use it.

The diagnosis is cheap, which is what makes skipping it so expensive. Each stage has one specific piece of evidence that either exists or does not. Checking all five takes about ten minutes and it decides which of five completely different pieces of work you are about to do.

Name the stage before you name the fix.

The evidence that belongs to each stage

Crawl. A crawl run or a server log shows the request, the status, and the time it happened. The absence of a request is itself the finding. If the URL was never fetched, go looking for the internal link that should have pointed at it, not for something wrong with the writing.

Index. URL Inspection reports the indexing state and, more usefully, the canonical the engine selected. A page reported as crawled but not indexed has a different problem from one whose canonical quietly resolves to another URL on your own site.

Rank. Search Console query rows are the first-party evidence that the page is being considered at all. Impressions near zero for the terms the page was built for means the ranking system is not putting it in front of that query. That is a relevance problem. No amount of formatting fixes it.

Answer. A dated run recording the engine, the product mode, the prompt, the response, and the sources it cited. One run is an anecdote. The same prompt run on a schedule, under written conditions, is evidence you can compare against itself.

Outcome. A mapped key event in Analytics, attached to the page group. This is the stage where a page that ranks well, gets clicked, and changes nothing finally becomes visible.

Two shortcuts that will lie to you

A site: search does not prove indexation. It is a filtered view with its own rules and its own omissions. A URL missing from it may well be indexed. A URL showing up in it may not be eligible to rank for anything. URL Inspection reports the state that actually applies to the page.

One prompt does not prove AI access. Answer engines vary by account, location, product mode, model version, and the day of the week. A single response showing a competitor where you expected yourself is one observation taken under uncontrolled conditions. Repeat it under a written protocol before you let it move a budget.

Both shortcuts are popular because they are fast and they feel like evidence. They produce a specific kind of failure: work that is confidently aimed at the wrong stage, defended with a screenshot, and impossible to argue with until somebody opens the real report.

When two stages are broken at once

This happens more often than the clean version. A section of the site was disallowed in robots.txt for a month, and the pages that were reachable also carry titles nobody has touched since 2023. Both are real. Fixing them in either order feels defensible.

Fix the earliest broken stage first, then stop and re-measure before you diagnose anything below it. The reason is not tidiness. A fix at an early stage frequently dissolves the symptom you were about to spend a sprint on, because the later stage was never failing on its own merits. Pages that could not be crawled had no impressions, so the titles were never the thing suppressing clicks.

The cost of getting this backwards is that you never find out which fix worked. Ship both, watch the number move, and you own a result you cannot attribute and cannot repeat on the next site.

How far to follow the chain

Staged diagnosis has an obvious failure at each end. Stop too early and you fix the visible symptom while the cause keeps producing it. Keep going indefinitely and you produce a document nobody can act on, arriving a month after it was useful.

The stopping rule is about actions, not questions. Stop when the next answer would not change anything already in the plan. Not when you run out of questions, because you will not, and not when you run out of time, because that cuts the chain wherever the clock happened to land.

In practice this means asking, before each next step, what you would do differently depending on the answer. If both answers lead to the same action, the step is curiosity rather than diagnosis. If they lead to different actions, keep going, even when the chain has already run further than the brief implied.

Work the stages in order

Stop at the first stage that fails. Everything below a broken stage is unmeasurable, so any conclusion you draw down there is guesswork wearing a number.

1. Discovery.Confirm an internal link or a sitemap entry exposes the URL. If neither does, the page has not been rejected. It has not been considered.
2. Access and rendering.Check the status, the robots controls, and whether the content survives rendering. A page that needs a click to reveal its main text can be indexed as an empty page.
3. Indexing.Read the indexing state and the selected canonical together. The second one explains most of the confusing cases.
4. Ranking and presentation.Segment by query, page, country, and device before concluding anything. A site-wide average hides the one segment where the change actually happened.
5. Answer visibility.Record the prompt, engine, mode, date, response, and sources, then say whether the claim made about you was accurate. Mention and accuracy are separate findings and they need separate fixes.

Two numbers moving in the same direction during the same month is the weakest form of evidence there is, and it is the form most SEO reports are built on. Titles were rewritten in week one. Clicks rose 14% by week four. The report draws an arrow between them, the client accepts it, and nobody finds out for another two quarters that a competitor had gone offline for three weeks.

The fix is not more caution in the writing. It is a structure that keeps the three kinds of number apart so the relationship between them has to be stated rather than implied. Work completed at the bottom. Visibility observed in the middle. Audience or business outcome at the top. Each layer gets its own evidence, and each join between layers gets a label describing how strong the link really is.

Work is not visibility, and visibility is not an outcome. The label on each join is what makes the report true.

What each layer is allowed to say

Work completed. Countable and dated. Eight titles rewritten, one critical issue closed, a recrawl requested on August 28. This layer is the easiest to fill and the easiest to mistake for a result. Nobody outside the team wants a list of tasks, and no amount of shipped work proves anything on its own.

Visibility observed. Always segmented, always dated, always with the comparison period visible. 11,198 clicks against 366,713 impressions for July 29 to August 25. An average position of 11.9 is a property of a set of queries, not a rank, and it moves when the query mix moves even if no page changed.

Audience or business outcome. The layer the business actually cares about, and the one most likely to be partly unavailable. 504 mapped leads is a GA4 fact. $177,300 of assigned value is that fact multiplied by an assumption. A qualified, won, or paid case is a different fact: it belongs in Analytics > Business outcomes only when a named source import confirms the stage, value, and date.

Writing the join

A client told that clicks and rewritten titles moved together in the same window, with the alternative explanations listed beside them, trusts the next report more than one told a causal story that falls apart in November. The weaker claim is the one that survives contact with the data.

The gap is a finding, not an embarrassment. A tree that ends at mapped leads with the qualified and paid layers marked unknown tells the reader precisely how far the measurement reaches. Analytics > Business outcomes can extend it from a dated CRM or CSV export, while retaining the source system, stage history, and attribution limit beside the result.

Build the tree

Fill it from the top down, because the outcome decides which visibility signals are worth carrying and which work is worth reporting at all.

1. State the outcome and the period.One outcome, one window, one comparison window. Everything else on the page has to reference the same dates or the tree cannot be read.
2. Pull the visibility layer with its filters visible.Record the segment you used. All countries and all devices is a choice, and it hides the mobile-only drop that a segmented view would have shown.
3. List the work with its ship dates.Movement before a ship date is not attributable to it. Half of the causal claims in reporting die on this line alone.
4. Label each join.Observed, plausible, or verified. Write the alternative explanation you considered and rejected next to it.
5. Reconcile the windows, or declare the mismatch.Search Console and Analytics rarely cover identical days. Horizon runs Jul 29-Aug 25 against Jul 30-Aug 26. A one-day offset is usually harmless, but it has to be written down, because the reader will otherwise assume the two rows describe the same period.
6. Name the layer you cannot see.Say what is missing and what would connect it. An unmeasured layer that is declared is far more useful than one filled with a proxy.

A baseline is the thing you argue with later. In four months somebody will ask whether the technical work paid for itself, and the answer depends entirely on whether anyone wrote down what the site looked like before it started. Not a headline number. The coverage, the crawl scope, the query set, the dates, and the parts that were unknown at the time.

The common version is a screenshot of a traffic graph, and it fails for a specific reason: it cannot be reopened. Nobody can reproduce the filters, nobody remembers whether it included brand queries, and nobody recorded that only seven of eight pages were readable during that crawl. A number without its scope cannot be compared to anything, which means the comparison gets made anyway, badly.

A baseline someone else can reproduce, including its gaps. Anything less becomes an argument later.

What actually goes in

Coverage before content. Which data sources are connected, and which are not. Horizon shows 5 of 5 across domain, Search Console, audit, backlinks, and agent context. A project sitting at 3 of 5 produces conclusions with holes in them, and the holes need to be visible at the top rather than discovered halfway through a review.

The crawl scope, not just the score. 70% health means nothing without the eight pages attempted and the seven that were readable. One unreadable page out of eight is a 12% blind spot in every technical conclusion drawn from that run, and it travels with them whether or not anyone writes it down.

Search performance with its filters. Clicks, impressions, CTR, and average position, plus the countries, the devices, and both date windows. Record one or two query rows that matter, such as the settlement calculator cohort, so the totals can later be broken apart rather than only compared as totals.

The tracked set, described as a sample. Twelve keywords on Google, desktop and mobile, checked weekly, with two saved competitors. This is a deliberately chosen cohort. It is not the market, it is not total demand, and reporting it as either is the most common way a rank tracker gets misread.

New sites record zeros, not estimates

A site launched last month has no history, and that is a fine baseline. Write zero where the number is zero and unavailable where the source does not exist yet. The first crawl still produces a scope and a health score. Analytics still produces a setup, even with no conversions behind it. Search Console still produces a start date, which is the single most useful thing you will own three months from now.

The temptation is to fill the emptiness with industry benchmarks or a competitor's numbers. Doing that converts the baseline from a record into a forecast, and every later comparison inherits the error. An empty row that is honestly empty stays useful. An invented one poisons the comparison it was meant to support.

How often to take a new one

A baseline is not a monthly ritual. Taking one every month gives you twelve starting points and no way to measure a year, because each comparison silently resets against the most recent snapshot rather than the moment the work began.

Take a new one when the thing being measured changes shape: a migration, a redesign, a new section or market, a change to how conversions are tracked, or a switch in crawl scope. Those events break comparability, and pretending otherwise produces a chart with a cliff in it that nobody can explain two quarters later.

Never overwrite the old one. Keep every baseline, dated, including the ones taken before a migration. The pre-migration record is the only evidence that will settle the argument about whether the migration cost anything, and it is the one people delete because the numbers underneath it look stale.

Capture it in one pass

One pass through Analytics > Baselines, one dated snapshot. The test is whether a colleague can reopen the saved evidence next quarter without reconstructing your filters from memory.

1. Confirm the project and its coverage.Open Analytics > Baselines and name the scope, owner, period, assumptions, and unknowns first. A missing source is saved as unavailable instead of becoming a zero.
2. Record Search Console with its filters.Set the window and the comparison window, keep all countries and devices visible, then record the four totals and the query rows that matter to the outcome.
3. Record Analytics against the mapped events.Sessions, engaged visits, key events, mapped leads, and assigned value. Note which of these is an assumption and which is a count.
4. Record the audit run and its scope.Date, pages attempted, pages readable, severity counts, and the affected URLs. The scope is the part people forget and the part that invalidates comparisons.
5. Record the tracking cohort.Save the snapshot, then open its metric links to verify the Rank Tracker, Site Health, Search Console, Analytics, link, and Work Queue periods. Use Compare with only when the scope still means the same thing.