Technical SEO is the work that lets search engines and answer engines reach your pages, read them, and trust them enough to rank them. It covers crawling, indexing, page speed, mobile rendering, internal linking, canonical tags and structured data. It is not what your pages say. It is whether a machine can get to what they say, and whether it can tell what it is looking at.
Here is the part nobody wants to hear. On most B2B sites, a short list of technical problems costs more rankings than any volume of new content will win back. Publishing feels like progress. Fixing your indexation does not. So the content gets commissioned, the technical debt stays, and twelve months later the site has forty more posts and the same traffic.
This is the order to work in, and how to tell which problem you actually have.
What is technical SEO?
Technical SEO is the practice of making a website easy for search engines and answer engines to crawl, index and interpret. It deals with the delivery of a page rather than its content: how fast it loads, whether it renders on a phone, whether a crawler can find it at all, and whether the markup around it explains what it is.
It does three jobs, in this order:
- Access. Can a crawler find the page and fetch it?
- Comprehension. Once fetched, can it tell what the page is about, and which version of the page is the real one?
- Trust. Does the page load fast enough, and work well enough, that serving it to a searcher is a safe bet?
Every technical SEO task maps to one of those three. If you cannot say which one a task serves, it is probably not worth doing yet.
What is the difference between on-page SEO and technical SEO?
On-page SEO is what your page says. Technical SEO is whether a machine can reach it and understand it.
| On-page SEO | Technical SEO | |
|---|---|---|
| Deals with | Content and its structure | Delivery and infrastructure |
| Examples | Titles, headings, copy, keyword targeting, internal link anchors | Indexing, crawl paths, speed, mobile rendering, canonicals, schema |
| Fixed by | Writers and editors | Developers and platform decisions |
| Fails like this | You rank, for the wrong thing | You do not rank, for anything |
| Question it answers | Is this page the best answer? | Can this page be found and read? |
The two are not in competition and they are not sequential in the way people usually assume. You need both. But they fail differently, and that is the useful part: the way a site fails tells you which one is broken.
A page with excellent on-page SEO that no crawler can reach earns nothing. A perfectly fast, flawlessly marked-up page that answers a question nobody asks also earns nothing. Diagnose before you spend.
How do you know if technical SEO is your problem?
Look at impressions before you look at anything else. Not clicks, impressions. Clicks tell you whether people chose you. Impressions tell you whether you were in the room.
Three patterns, three different problems:
- Impressions but almost no clicks. Usually not technical. Search engines can find you fine. You are ranking for terms that are too broad, or ranking too low to get chosen, or your titles are not earning the click. This is a content and targeting problem, and buying more technical work will not touch it.
- No impressions at all for terms you should own. Usually technical. Something is stopping you from being seen in the first place. Start with indexation.
- Impressions falling off a cliff after a change. Almost always technical. A redesign, a migration, a plugin, a robots file. Look at what shipped that week.
Most teams skip this step. They guess, or they take the recommendation of whoever is selling them something. Fifteen minutes in Search Console tells you which of the three you have, and that fifteen minutes is the highest-value technical SEO work available to most B2B sites. Making regular website audits a habit is how you stop finding out about this kind of thing a quarter late.
What should you fix first?
In this order. The order is the actual advice, because the first two items carry most of the weight and the last two are where people like to start.
1. Indexation and crawlability. Are your pages in the index? Everything else is theoretical until they are. Check for pages blocked in robots.txt, noindex tags left over from staging, orphan pages with no internal links pointing at them, and broken sitemap entries. A page that is not indexed cannot rank, no matter how good it is.
Search Console tells you why a page is excluded, and two of the reasons get misread constantly:
- “Crawled, currently not indexed.” Google fetched the page and decided against it. This is usually not a technical block. It is a judgment about quality or duplication, and the fix is the page, not the plumbing.
- “Discovered, currently not indexed.” Google knows the URL exists and has not bothered to fetch it. That points at internal linking or crawl priority. The page is probably an orphan, or buried too deep.
The rest are more literal. “Excluded by noindex tag” and “Blocked by robots.txt” mean what they say and are usually leftovers from a build. “Duplicate without user-selected canonical” means you have two versions of something and did not say which one counts. “Alternate page with proper canonical tag” is normal and needs nothing from you.
2. Page speed and Core Web Vitals. Google measures three: Largest Contentful Paint for load speed, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. The thresholds are 2.5 seconds, 200 milliseconds and 0.1. On B2B WordPress sites the usual culprits are oversized images, a page builder loading assets it does not need, and too many plugins each adding their own stylesheet.
3. Mobile rendering. Not “is it responsive.” Does it actually work. Tap targets far enough apart, no horizontal scroll, forms usable with a thumb. Your buyers research on phones and convert on desktop, so a mobile failure costs you at the top of the funnel where you cannot see it.
4. Internal linking. The most underrated item on this list and the cheapest to fix. Internal links tell search engines which of your pages matter and how they relate. A cluster of posts with no links between them is a list, not a cluster.
The working rule: every post links up to its cornerstone page and across to two or three siblings, with anchor text that describes the destination. “Learn more” teaches a crawler nothing. The anchor is a label, so use the words someone would search for. This costs an hour across a whole cluster and it is the closest thing to free ranking movement available to a B2B site, which is exactly why it keeps getting skipped in favor of buying something.
5. Canonical tags and duplicate content. Where one page of yours competes with another page of yours. Publish long enough without a map and you end up with several posts chasing one query, and search engines have to guess which one you meant.
We did it on this site. Three separate posts covered this exact subject, so we merged them into the one you are reading and redirected the other two. Worth being precise about what that fixed, though: when we checked Search Console, all three were earning almost nothing, so the merge was not rescuing traffic that overlap had stolen. It was tidying three thin pages into one useful one. Those are different problems, and the second one is far more common than the consultants selling the first one will tell you.
6. Structured data. Schema markup that tells a machine what kind of thing a page is. Useful, genuinely, and the last thing on the list. Schema on an unindexed page is a rounding error.
How do you run a technical SEO audit without a specialist?
Most of what a B2B site needs is in Google Search Console, free, and takes an afternoon.
- The Pages report shows what is indexed and what is not, with the reason. Start here. Read the excluded reasons rather than skimming the totals.
- The Core Web Vitals report shows real user measurements rather than a lab score, grouped by URL pattern, so you can see whether the problem is the whole site or one template.
- The sitemaps section tells you whether your sitemap is being read and what got rejected.
- The performance report, filtered by page, is where you run the impressions diagnostic from earlier.
Free tools stop being enough in four places: JavaScript rendering, where you need to see the page as a crawler executes it; server log analysis, which is the only way to see what crawlers actually requested; crawl budget on large sites; and server configuration, where the fix is in nginx or Apache rather than in the CMS. If your site is a few hundred pages of mostly server rendered content, you may never need any of that.
A workable sequence for the afternoon: export the Pages report and sort the excluded URLs by reason, not by count. Pick the reasons that indicate a block rather than a judgment. Cross-check the blocked ones against your sitemap to see whether you are asking Google to index something you are also telling it to ignore, which is more common than it sounds. Then open the Core Web Vitals report and check whether failures cluster by template. If they do, you have one fix, not forty.
One warning. A crawl tool will hand you several hundred issues sorted by its own severity scale, not by your business impact. Broken links on a page nobody visits are not urgent. Work the list above in order instead, and treat the tool as a way to find things rather than a way to prioritize them.
What does technical SEO have to do with answer engines?
Everything, and this is the part that changed recently. If a model cannot crawl and parse your page, it cannot quote you. There is no alternate route in. Answer engine optimization is not a separate discipline sitting beside technical SEO. Technical SEO is the floor it stands on.
What answer engines add on top is a preference for structure. They pull passages rather than ranking pages, which means:
- Clean, semantic headings that describe what follows
- Definitions written so they survive being lifted out of context
- One clear point per page, so there is no ambiguity about what the page answers
- Content in the HTML rather than assembled by JavaScript after load
That last one matters more than it used to. A page that renders its main content client side may be crawled, indexed and still never quoted, because the passage was not there when the parser looked.
There is also a newer convention worth knowing about. Some sites now publish an /llms.txt file, a plain-text map of the site written for models rather than for crawlers. We generate ours from the meta description of every published page, which has the useful side effect of making a missing meta description a visible defect rather than a quiet one. Be clear-eyed about it: no major engine has committed to reading these files, so treat it as cheap insurance and not as a ranking factor.
The overlap with good technical SEO is almost total. A fast, crawlable, well-structured page was always the goal. Answer engines just removed the margin for error.
How often should you audit your technical SEO?
Quarterly, as a baseline, and immediately after anything structural.
The quarterly pass is maintenance: indexation, Core Web Vitals, anything new in the Pages report. An hour, if nothing is wrong.
The triggered audit is the one that matters, because this is when technical SEO problems are created. Audit right away after a redesign, a domain or URL change, a CMS or theme change, a new page template, or a plugin that touches rendering or caching. If you are changing your site address, audit before and after, and keep the redirect map.
The mistake is treating the audit as the deliverable. The audit is a list of things to fix. It is worth what you fix.
Where this fits
Technical SEO gets you found and read. It does not get you chosen. Once the pages are indexed, fast and structured, the remaining problem is whether the page earns the click and the click earns a conversation, which is what actually makes a website convert rather than merely rank. If you are heading into a rebuild, the same logic says to let analytics drive the redesign rather than taste.
More on this in B2B websites that convert.