Skip to main content

Intelligence module

The layer nobody notices until it stops working

Technical problems rarely announce themselves. Traffic drifts, a section quietly stops appearing, and the cause turns out to be a directive added eighteen months ago for a reason nobody recorded.

Technical health governs whether everything else has a chance to work. Content quality is irrelevant on a page that returns an error. Entity clarity is irrelevant on a page nothing can reach. The technical layer is not more important than the others, but it is prior to them.

It is also the area where problems persist longest, because the symptoms are indirect and the people who would notice are not usually the people looking. A marketing team sees traffic decline. A development team sees no errors in the logs. Both are looking at accurate information and neither is looking at the cause.

Layers

Five layers, checked in order

The order matters. A failure in an earlier layer makes findings in a later one academic, and fixing them in the wrong sequence wastes effort.

  1. Reachability

    Whether a request for the page succeeds. Response status across the pages examined, redirect behaviour including chains and loops, and whether the server responds consistently rather than intermittently.

  2. Permission

    Whether anything instructs a crawler not to proceed. robots.txt directives and their actual effect, indexing directives in markup and headers, and conflicts where two signals give contradictory instructions.

  3. Rendering

    Whether the content is present in the response or arrives after JavaScript execution. What a parser sees without execution is compared against what the page is intended to communicate.

  4. Structure

    Whether the site's architecture communicates a hierarchy. How deep important pages sit, how internal links distribute emphasis, whether canonical relationships are coherent, and whether the sitemap agrees with reality.

  5. Delivery

    How the page performs once reached. Core Web Vitals for mobile and desktop through PageSpeed Insights, image handling, and the response characteristics observed during the fetch itself.

A technical finding is worth acting on when it is preventing something. Many are simply differences from a recommended default, and treating those with equal urgency is how technical debt lists become unreadable.

Interpretation

What the score reflects

Reflects whether the website is straightforward for search engines to crawl and index, and whether it loads and renders to a modern standard.

A high technical score is a statement that nothing observable is obstructing the site. It is not a statement that the site will perform well, because performance also requires content worth finding and a market that wants it.

The maximum for a passive assessment is 96. A passive review examines a small number of pages and cannot establish that the remaining several thousand behave the same way. Where a site scores highly with no findings, that means we looked and found nothing wrong — which is genuinely good news, and a weaker claim than nothing being wrong.

Commonly surfaced

  • A staging directive that followed the site into production
  • Redirect chains resolving in three or four hops
  • Canonical declarations pointing at the wrong page
  • Service content present only after JavaScript executes
  • A sitemap listing addresses that redirect or error
  • Important pages five clicks from the home page
  • Images served at many times their displayed size
  • Mobile performance substantially worse than desktop

Example finding

A representative finding

This is an illustration of the report format rather than a result from a real assessment.

High

Service Descriptions Are Absent Until JavaScript Executes

What we found
The initial HTML response for the service pages contains navigation, footer and a page shell. The service descriptions, headings and internal links within the main content area are inserted by client-side script after load, and are not present in the document a parser receives.
Why it matters
Search engines can process client-rendered content, but on a delayed and less reliable path than content present in the response. Generative retrieval systems frequently do not execute JavaScript at all. Content on this path is at best processed late and at worst not processed by some systems.
General direction
Move the main content of commercially significant pages into the server response, through server-side rendering or static generation. Interactive elements can remain client-side; the material describing what the business offers should not depend on execution.
How IXSEO can help
Technical SEO, with implementation support where the platform allows it.

Categories

How findings are triaged

Every technical finding falls into one of three categories, and the category determines the response more than the severity label does.

Actively limiting

Something is currently preventing pages from being reached, processed or served. Scheduled immediately, with verification afterwards rather than an assumption that the fix worked.

Constraining

Nothing is broken, but the configuration makes the site harder to process than it needs to be. Worth resolving within the quarter, usually alongside other planned work.

Divergent from best practice

A difference from a recommended default with no observable consequence on this site. Recorded for completeness, explicitly deprioritised, and not something to spend a sprint on.

Frequently asked questions

Is this the same as a performance audit?
Performance is one component. The module also covers crawling, indexation, rendering, architecture, redirect behaviour and serving consistency, most of which affect visibility more directly than load time does. A fast site that cannot be indexed is fast and invisible.
How much do Core Web Vitals actually matter?
Less for ranking than most people assume, and more for conversion than most people measure. They function as a tiebreaker between comparable results rather than a primary factor. The stronger argument for improving them is that people leave slow pages, which costs you enquiries regardless of where you rank.
Our site is a JavaScript application. Is that a problem?
Not inherently, but it changes what has to be verified. Client-rendered content is processed on a delayed and less reliable path than content present in the initial response, and generative retrieval frequently does not execute JavaScript at all. Whether that matters depends on which content it affects — a rendered dashboard is fine, rendered service descriptions are not.
Can you fix the issues you find?
Through the Technical SEO service, yes — either by specifying changes precisely enough for your developers to implement, or by implementing directly where that is preferred. Most engagements are a mixture, weighted according to your team's capacity.

Check the layer underneath everything else

Technical Health runs by default on the free snapshot and includes performance measurement where PageSpeed Insights responds.