Remediation, aimed at a site somebody else built
The work here is remediation. If you want the version where these problems never arise, that is an architecture question and it belongs to the Model Context Protocol.
What a technical audit actually turns up
The same findings recur across almost every site we assess, which says something about how sites get built rather than about the people who built them.
Performance
The Core Web Vitals measure loading, interactivity and visual stability: how quickly the main content paints, how fast the page responds to a first interaction, and whether the layout jumps while it settles. The usual levers apply: modern formats, responsive image sets, lazy loading, explicit dimensions so nothing shifts, caching, minification, deferred scripts, font display rules and critical styles inlined.
Heading structure
Levels that skip or run out of order, decorative text marked up as one, and pages where the visual hierarchy disagrees with the document outline. An outline is the compressed argument of a page, so a broken one leaves that argument unreadable.
Links with no discernible name
Icons and bare images wrapped in anchors with no text. Invisible to a screen reader, and a wasted signal for everything else.
Uncrawlable navigation
Links implemented as script actions rather than as addresses, which a person can click and a crawler cannot follow.
Missing landmarks and low contrast text
Accessibility failures first, though each also affects how cleanly a document can be parsed. Alongside them: invalid language attributes, usually inherited from an embedded widget nobody has looked at since installation.
Accessibility is doing two jobs
Proper heading order, descriptive link text, alternative descriptions on images and present landmarks are accessibility requirements. Those same structures are what a crawler and a retrieval system use to understand a document. That makes accessibility remediation unusually good value. One pass satisfies a legal obligation and improves how machines read the page, so it rarely has to compete for budget against the search work. The two are the same job.
Writing to be read by an answer engine
These systems run a different pipeline from classic search. A question is rewritten into sub-queries. Candidate passages are retrieved, reranked and assessed, then citations get attached to specific claims. The properties that make a passage selectable are specific and testable: a section answers its own heading in its first sentence, headings are phrased as the question a reader would actually ask, paragraphs stand alone without needing the surrounding context, and content suiting a list, a table or a definition is shaped accordingly, because those forms extract cleanly and prose does not.
These are structural rules rather than stylistic preferences, and a page built to them reads better for people too, which is the usual sign that a technique will last.
Meta descriptions, and when to leave them out
Standard advice says write a unique one for every page. We follow it in most cases and deliberately break it in one. On pages that earn traffic across a long-tail spread of varied queries, a fixed description competes with the search engine's ability to compose a snippet matched to the specific question asked. Leaving the description off lets the engine pull the passage that fits the query, which frequently converts better than anything written in advance.
The choice is a judgment made per page rather than a policy. Where a page has one dominant intent, write the description. Where it serves dozens of different questions, let the engine choose. The scalpel for controlling which passages are eligible is a no-snippet attribute on the sections you want excluded, and a social description tag keeps the sharing preview intact either way.
Prioritizing honestly
An audit that returns two hundred findings is not a plan. Most of what a scanning tool reports carries no practical consequence, and a client working through the list in order will spend weeks on items of no effect.
We sort by effect. Anything blocking crawling or indexing comes first, because nothing else matters on a page that cannot be reached. Then the structural faults that affect how a document is understood. Performance comes next, weighted toward what visitors on ordinary connections actually experience. Last comes the long-tail of findings worth correcting whenever the page is next touched anyway.
"Saying plainly which findings do not matter is part of the deliverable."
Where compliance work connects
The architecture that avoids most of these problems by construction is covered under the Model Context Protocol. The machine-readable facts a compliant page can carry are covered in structured data, while measurement of whether any of it moved belongs to performance analytics.