Indexed, linked, and fast enough to matter

A technical audit tells you how bad a finding is. It does not tell you what it costs you. So somebody sorts the backlog by severity, an engineer works down from the top, and the worst score turns out to sit on a page that never earned a click.

That is how technical work loses its audience. The rule that keeps this category useful is to sort every finding by the clicks at stake instead. A blocked page earning nothing is trivia. A blocked page that anchored a revenue line is an incident. A severity ranking shows you the same red dot for both.

Three checks make that sorting possible: which crawled pages cannot be indexed and why, which pages have nothing linking to them, and how fast the pages that earn your traffic actually load. One triage sheet, ranked by traffic, is the deliverable.

Indexation gaps are silent by design

A page blocked from the index does not error, alert, or complain. It stops appearing. The traffic it used to earn drains away at whatever pace the index forgets it. One check reads your crawl and lists every crawled URL flagged not indexable, with the reason attached: a noindex directive, a canonical pointing elsewhere, a robots rule, or a status code.

That reason column is what makes triage fast. A deliberate noindex on a utility page is policy. The same directive on a money page is a fire. One sort by traffic is all that separates them.

Reasons cluster, too. The clusters are worth reading. A wave of canonical flags after a replatform points at template logic. Robots flags concentrated in one directory usually point at a rule somebody wrote for staging that rode a release into production. That turns a list of URLs into a short list of causes, which is what your fixing team needs.

The quarter-long drop that wasn't Google

Here is the case that argues for proactive crawling better than any policy could. A key page type lost clicks for a quarter, and the investigation began from the obvious assumption. Rankings had slipped. They had not.

A stray URL parameter had spawned variant addresses, and a code patch was intermittently applying noindex to the affected pages. Some crawls saw the directive. Some did not. The index bled the pages out slowly enough that no single week looked like an event.

Diagnosis was harder than it needed to be. Somebody had fixed a reporting bug without restating the historical series, so the team read a real decline through a distorted picture. Every ingredient was self-inflicted, and none of it showed up in a rankings report. Rankings were the symptom.

The fix that team adopted is the lesson. Crawl your own money pages on a schedule, so a directive appearing where it should not surfaces in days. Waiting for the traffic chart means paying a quarter of decline for one line of diagnosis.

Who can reach an orphan page?

Nobody, which is the whole problem. One check lists every crawled URL with zero incoming internal links. A second shows where your links pool, which pages hoard and which starve. An orphan is invisible twice over: once to crawlers that follow links to find pages, and once to visitors who navigate the same way.

Your triage rule applies unchanged. Orphans with real traffic history or commercial value get linked back into the site this sprint, and the internal linking article covers where those links come from. Orphans that never earned anything join a slower conversation about why they exist.

Orphans also accumulate at predictable moments, and checking after each of them costs minutes rather than a project.

• A migration that drops old sections out of the navigation
• A campaign whose landing pages outlive the links pointing at them
• An archive that quietly detaches from the rest of the site

See also: the linking work that pulls an orphan back in →

Which slow pages actually cost you?

The ones carrying your traffic, which is rarely the list with the worst scores. Core Web Vitals invite the same score trap: a site-wide average, a color grade, a backlog sorted by severity. One check resists it by joining the vitals to your Search Console clicks per page. What comes back is your top traffic earners with their load performance attached.

A slow page nobody visits is a fact. A slow page carrying your highest-traffic template is a priority with a number on it. That join routinely reorders a vitals backlog, because your worst scores and your most valuable pages are rarely the same rows.

The vital itself is selectable. Load speed by default, with responsiveness and layout stability on the same join, so the check matches whichever metric your team is accountable for.

The workflow that does this: Sub-page portfolio audit →

One sheet, ranked by clicks at stake

Your deliverable merges the three checks into one ranked sheet: every finding, its reason, and the traffic it endangers, sorted descending. The top of that sheet is this month's technical work. It is defensible in any meeting, because every row carries its own justification, and all three run off the same crawl and traffic data, so the sheet refreshes without a project attached.

It changes the meeting you carry it into. Technical work stops arriving as scores and starts arriving as protected traffic, which is a language every stakeholder in the room already speaks. Findings compete for the sprint on equal terms with features, and the traffic column is what lets them win.

This is the ground the rest of your program stands on. The first question of the Quattr Method asks whether crawlers and AI bots can fetch, render, and index your pages at all. Indexation, linking and speed are its three most common failure modes. Keep the sheet current and that question stays answered without heroics at quarter end.

See also: the first question: can crawlers and AI bots fetch, render, and index your pages →