Every few weeks someone calls me because their rankings went sideways and nobody can tell them why. They have paid for content. They have a Google Business Profile. Their site looks fine. Then I crawl it, and inside twenty minutes there it is: half the pages are not in Google's index, or the mobile experience takes six seconds to paint, or four URLs are quietly competing for the same keyword.

That layer — the one nobody looks at because it does not show up in a screenshot — is technical SEO. It is where I start with every client, and it is the part of this work I have been doing the longest.

Technical SEO is everything that happens between your website and a search engine's infrastructure that a human visitor never sees. Whether Googlebot can reach a page. How fast that page paints on a phone on a Tucson cell network. Whether the structured data tells Google this is a local business rather than a blog post. Whether canonical tags stop four versions of a page from splitting the authority between them. Redirects, XML sitemaps, robots.txt, HTTPS, mobile rendering, and the Core Web Vitals that Google measures from real Chrome users.

Google's own documentation on how Search works lays out the sequence: crawling, then indexing, then serving. Every stage has technical requirements, and every stage is a place a site can silently fall out of the running. A beautiful website built by a designer who has never read that documentation is a house with excellent paint and no plumbing.

I have been working on this layer since before it had a name. I ran two internet marketing companies through the late nineties and early 2000s — Lotus411.com and MSD2D.com, both community sites for enterprise server administrators, both sold. Those sites had thousands of pages that had to stay crawlable and load on the hardware and connections of the day. The tools have changed completely since then. The question has not: can the machine find this, read it, and understand what it is?

Let me deal with the misinformation first, because it is everywhere right now and this page used to repeat a version of it.

The Core Web Vitals thresholds did not change in 2026. There was a real core update — it was announced on March 27, 2026 and finished rolling out on April 8 — but it was a broad quality recalibration. It rewarded original, first-hand, clearly attributed content and it went hard after thin aggregator pages. It did not move LCP to 2.0 seconds. It did not promote INP to a primary signal, because INP has already been one of the three Core Web Vitals since March 2024, when it replaced First Input Delay.

Here is what is actually true, and you can check every number of it against Google's Web Vitals documentation:

The detail most agencies skip: Google scores these from field data, not lab data. The number that counts comes from the Chrome User Experience Report, at the 75th percentile of real visits, across a rolling 28-day window. A green score in PageSpeed Insights on your laptop means very little. What matters is the fourth-slowest visitor out of five, on a mid-range Android, on a normal connection.

That is also why fixes feel slow. Deploy a real LCP fix today and the field data will not fully reflect it for about four weeks. I tell clients this up front so nobody panics in week two.

In the Tucson sites I have put through CrUX this year, the metric that fails most often is INP, and the cause is almost always the same: a WordPress install carrying more JavaScript than the business needs.

This is the failure that hides best, because the page looks perfect when you visit it. It exists on your server. It just is not in the index. Nobody notices for a year.

I check indexation on every site I work on, using Google Search Console's Pages report, a full crawl, and hand checks on the URLs that matter most. When a page is not indexed, the job is to find the specific obstruction and remove it — not to note it on a list.

Architecture is how your pages are organized and how they link to each other. Done deliberately, it tells Google which pages are the important ones, how your topics relate, and where authority should flow. Left to chance — which is the default — you hand Google a pile of pages and hope it works out.

For a local service business the shape is not complicated. The homepage points at the core service pages. Each service page points down to its sub-services and out to the related services a buyer would reasonably want next. Location pages sit under the services they serve. Supporting articles link up to the service page they support, not sideways into nothing. URLs read like a path a human could follow.

This page is a live example. It sits under Services, it links up to the monthly SEO service that contains it, sideways to the SEO audit that diagnoses it and the website design service that builds on it, and out to case studies that show the result. Nothing here is orphaned, and nothing links out to a page that does not exist.

When I build a site through the design service, the architecture is mapped before a page is designed. When I take over an existing site, restructuring happens in month one, ordered by which changes move rankings soonest.

Schema markup is structured data in your page's HTML that states what the content is, in a format machines read without guessing. Instead of hoping Google works out that a page describes a business in Tucson, the markup says so: this organization, this person, this service, this area served, these questions and answers. Google's structured data documentation and the vocabulary at Schema.org define the format.

Two things make this worth more in 2026 than it was in 2021. First, rich results: FAQ blocks, breadcrumbs and business details take up more room in the SERP and pull more clicks. Second, and increasingly the bigger one, AI assistants and AI Overviews lean on structured data when they decide what a business is and whether to name it in an answer. If your site never states its own identity in machine-readable form, you are relying on a language model to infer it from your copy.

The part almost everyone gets wrong is not whether schema exists but whether it agrees with itself. I inherit sites running four plugins that each emit their own Organization block, with three different phone numbers between them. That is worse than having none, because now Google has to decide which version of you is real.

Every site I work on gets one connected graph: a single Organization, a single Person, a single WebSite, and page-level WebPage, Service, BreadcrumbList and FAQPage nodes that reference those by ID instead of redefining them. The structured data on this page is written and validated by me, not generated by a plugin. View source and read it — that is the standard I hold client sites to, and it is checkable rather than claimed.

Speed is not the most important ranking factor and I am not going to pretend it is. Relevance, content quality and authority outweigh it. Speed is a floor and a tiebreaker.

But local search is mostly tiebreakers. You are not competing with Wikipedia. You are competing with three other contractors in Oro Valley who offer the same service to the same people, and when the other signals are close, the faster site takes the position. Then the visitor arrives, and speed stops being an SEO question and starts being a revenue question.

The fixes that actually move the numbers on a small business site are unglamorous:

After enough audits the same list keeps coming back, roughly in this order:

Almost every one of these is fixable in a single working session. The expense is never the repair. It is the eighteen months of suppressed rankings that ran while nobody looked.

You need both, which is why both are in the same monthly service. A technically flawless site with nothing worth reading ranks for nothing. Excellent writing on a site Google cannot crawl never gets the chance.