Technical SEO, in plain words.

The part of SEO nobody sees: whether a search engine can reach your pages, render them, and understand how they fit together. If it cannot, nothing else you do for search will count.

What the work includes

Crawl and index audit: Which pages a search engine can reach, which ones it has been told to ignore, and which ones are wasting its time.
Rendering check: Whether your content is in the HTML the server sends, or only appears after scripts have run.
Site structure: How pages link to one another, how many steps the important ones are from the front door, and whether each page has exactly one address.
Speed: Core Web Vitals measured on your real pages, the causes found, and the fixes made in the code rather than with one more plugin.
Structured data: Markup that states what a page is — a business, a service, an article — using only facts that are true.
Redirects and migrations: Moving a site, or changing its addresses, without throwing away what it has already earned.
A written report: What we found, what we changed and what is left, in words a business owner can read without a glossary.

Why it comes first

A search engine meets your site the way a stranger meets a building in the dark. It follows the links it can find, asks the server for each page, and reads what comes back. If a page cannot be reached, it does not exist. If its words arrive only after a script has run, they may be read late or not at all. If the same page answers at three addresses, its reputation is split three ways.

None of this shows in a design review. A site can be beautiful, approved and launched with every one of these problems in place. That is why technical SEO is the first stage of the work and not a finishing touch: the writing, the keywords and the links all rest on it.

What we look at

Reach. robots.txt, the sitemap, internal links, redirects, status codes. Can every page that matters be found by following links from the home page? Are there pages nobody links to?

Rendering. What the server sends before any script runs. We read the raw HTML the way a crawler does, and compare it with what a visitor finally sees.

Structure. One h1, headings in order, landmarks, one canonical address per page, a title and a description written for that page and no other.

Speed. Google’s three measurements: how quickly the main content appears (LCP, good at 2.5 seconds or less), how quickly the page answers a tap or a click (INP, under 200 milliseconds), and how much it jumps about while loading (CLS, under 0.1). Google states that these are used by its ranking systems — and also that a good result does not guarantee a place at the top.

Meaning. Structured data that matches what is on the page. We add the types a page really is, and nothing a visitor could not verify by reading it.

How the work goes

Read. We crawl the site as a search engine would and, if you have Search Console, read what Google already reports about it.
Rank the problems. Not every finding matters. Each one is listed with what it costs you and what it takes to fix.
Fix. In the templates and the server configuration, where the cause is — not with a layer on top that hides it.
Measure again. The same checks, after the change, with dates. What could not be measured is written down as not measured.

See it on this site

This site is its own example. Switch any page to Structure and it shows its landmarks, its heading order, where each link goes, and what your own browser measured while loading it. Or go to the home page and press X-ray this website.

What we will not promise

A position in the results. No one can promise that, and Google says so itself.
Bigger listings from FAQ or how-to markup. Google no longer shows them, so we do not sell them.
A perfect Lighthouse score as the goal. It is a lab test. The goal is what your visitors experience.