Technical SEO: What to Fix First and What You Can Ignore

"The role of the technical SEO is in the rapid Online marketing-environment of today is undeniably crucial."

That was the first sentence of this post until I rewrote it in November 2026. Read it twice if you like. It doesn't improve. A machine translated it, I didn't catch it, and it sat on my own website telling people how to do SEO properly.

Before touching it I pulled the numbers. Over 90 days the German version collected 469 impressions at an average position of 71, with zero clicks. The English version didn't show up in the report at all. Search Console filed those impressions under wunderlandmedia.de/technical-seo, an English slug on my German domain that only exists as a redirect. Eleven of my own German posts were linking to it instead of the real URL.

None of that explains position 71. The page loaded. The canonical and hreflang tags were right. Google had it indexed. It ranked badly because the words were garbage, and that is the most useful thing I can tell you about technical SEO: it decides whether a page gets to compete. It doesn't win anything for you.

What Is Technical SEO?

Technical SEO is the work that lets search engines find your pages, read them, store them and show them, before anyone judges what the pages say.

On-page SEO is the stuff on the page: titles, headings, text, internal links. Off-page is what other sites say about you. Technical is the plumbing underneath both. When it works, nobody thanks you. When it breaks, the best article you ever wrote doesn't exist as far as Google is concerned.

Nearly all of it comes down to four checks:

• Crawling: Google can reach the page.
• Indexing: Google keeps the page, under the URL you want.
• Experience: the page is fast and works on a phone.
• Meaning: a machine can tell what the page is about.

This post takes them in that order, because a failure higher up makes everything below it irrelevant.

Why This Comes First in a Digital Strategy

Google's documentation for AI Overviews and AI Mode has one hard condition for appearing as a supporting link: "a page must be indexed and eligible to be shown in Google Search with a snippet." Classic results work the same way. Your content calendar and your shot at an AI answer both run through that gate.

The other half is less popular with people selling audits. Google's page experience documentation says Search "always seeks to show the most relevant content, even if the page experience is sub-par." A green score doesn't lift a bad page past a good one. My post at position 71 had clean tags and nothing worth reading.

So treat this layer as a precondition. Fix whatever stops a page from being indexed or makes it painful to use, then stop, and put the rest of your budget into finding out what people search for and writing pages that answer it.

Crawling: Getting Google to Your Pages

Google's crawl budget guide is written for sites with a million-plus pages, for sites with 10,000-plus pages that change daily, and for sites with a big pile of URLs stuck on "Discovered - currently not indexed". If you run a 40-page company site, crawl budget isn't your problem. Google says an up-to-date sitemap and a regular look at the Page Indexing report are enough.

Small sites fail in dumber ways. A robots.txt from staging that still blocks everything. A noindex from the dev build that shipped to production. A page nothing links to. A sitemap full of redirects and 404s.

robots.txt controls crawling and nothing else. Google calls it "not a mechanism for keeping a web page out of Google," and a blocked URL can still appear in results if other sites link to it. To keep a page out, use noindex and leave the page crawlable. Block it in robots.txt and Google never gets to read the tag.

robots.txt is also where you decide which AI crawlers get in. If bots are hammering your server, that needs a fix at the server level.

Indexing: Getting Google to Keep Them

While rewriting this post I inspected my own keyword research guide. Status: "Crawled - currently not indexed", on both domains. Google fetched it and passed.

Google's help page says "Don't expect every URL on your site to be indexed" and that this status "doesn't necessarily indicate an issue that needs attention." For a tag archive, leave it. For a page you need, I read it as a verdict on the content, and no tag fixes that. That guide had a table of contents pointing at dead anchors and an empty FAQ heading at the bottom.

The technical indexing problem on small sites is usually duplicates: the same page at /foo and /foo/, with and without www, on http and https, with tracking parameters attached. You tell Google which version counts with a redirect and a canonical tag. Google lists both as strong signals. They are signals, so Google can still pick a different URL, and URL Inspection in Search Console shows you which one it chose.

On this site /foo/ redirects to /foo and the canonical tag agrees. If you run two languages, hreflang tags tell Google which URL is the translation of which. Every post here names both versions plus an x-default.

Redirects and Broken Links: Where Relaunches Lose Traffic

When I moved my Directus backend to a new subdomain, every absolute file link inside my article bodies broke. The articles hadn't changed. The hostname had, and I'd baked it into the text. Files now go through a relative path, so the next move won't touch them.

That's the small version of what goes wrong in a relaunch. URLs change, nobody maps the old ones, and whatever those URLs had earned goes with them. Every old URL needs a permanent redirect to its closest new equivalent, in one hop. It's the dullest job in this post and the one with the largest downside, which is why my migration checklist spends so long on the redirect map.

Titles and meta descriptions go missing the same way during a platform change, so export them before you start. The relaunch checklist has the full order.

Your own links should skip redirects entirely. A redirect is the right answer for outside links and old bookmarks. Those eleven German posts of mine worked fine, they just sent every visitor and crawler on a detour I could have avoided.

Site Speed: Core Web Vitals Over Load Time

Google measures three things on real visits: Largest Contentful Paint (good is 2.5 seconds or less), Interaction to Next Paint (200 milliseconds or less) and Cumulative Layout Shift (0.1 or less). A page passes at the 75th percentile, so three quarters of visits have to hit the target.

Google says these metrics "are used by our ranking systems" and, in the same document, that good scores don't guarantee top positions. Take both halves.

I've written up how I test load time and which numbers I ignore. Short version: start with the Core Web Vitals report in Search Console, because that's real users on real phones. A lab score from one test run helps you diagnose a problem. It can't tell you whether you have one.

Resize and compress images first. Then cut the scripts and plugins you don't need. Browser caching and hosting come after that. The old version of this post told everyone to upgrade servers as step one, and I take that back: a dedicated server doesn't fix a 4 MB hero image. Better hosting helps when the server itself is slow, which shows up as a high Time to First Byte. Your choice of platform shows up here too.

Usability: Structure and Navigation

Google classified back button hijacking as a spam signal, with a June 15, 2026 deadline. A site that traps people used to be a UX complaint. Now it's a search problem.

Most of this is less dramatic. Every page you care about should be reachable through normal links, a few clicks from the homepage, with anchor text that says where the link goes. Use real <nav> and heading elements, because semantic HTML is how machines and screen readers work out what's what. Keep headings in order and paragraphs short, and use a list where a list helps. The reader benefits first, the crawler second.

Mobile: The Version Google Actually Sees

Since July 5, 2024, Google crawls and indexes with only Googlebot Smartphone, and content that can't be reached on a mobile device is no longer indexable. You look at the desktop layout. Google looks at the phone.

So test on a real phone, on mobile data. Your responsive layout should hold at every width, buttons should be big enough for a thumb, the menu should work and no popup should cover the content. Anything that exists only on desktop may as well not exist.

The old version of this post recommended AMP. Drop it. Google said in 2021 that AMP is "no longer required" for Top Stories, and it removed the badge. A fast responsive page does the job without a second version of your site to maintain.

Structured Data and Metadata: Telling Machines What a Page Is

Google's structured data gallery listed 25 features when I checked in November 2026. FAQ and HowTo, the two every SEO guide told you to add for years, weren't among them.

Add the types that describe what you actually have: Article, Organization, Breadcrumb, LocalBusiness, Product. Use JSON-LD and keep it in line with the visible page, then run it through the Rich Results Test. Rich results are what you're after here. For Google's AI features, the docs say there's "no special schema.org structured data that you need to add."

Metadata is simpler. Every page gets its own title and meta description, and every meaningful image gets alt text. The title is usually what people see in the results, so write it for them.

AI Search Runs on the Same Basics

A Vercel analysis from December 2024 found that none of the major AI crawlers it looked at, including GPTBot and ClaudeBot, executed JavaScript. They fetched the files and didn't run them. Gemini was the exception, because it uses Googlebot's infrastructure.

That study is nearly two years old, so treat it as a warning and test your own site. Open a page, view the source and check that your main text is in the HTML. If it only appears after JavaScript runs, some crawlers may be looking at an empty shell.

Past that, there's little new to do. Google says you don't need new machine-readable files or special markup for its AI features, and the basics haven't changed. ChatGPT is its own game, with its own findings, and llms.txt has a post of its own.

My Technical SEO Check, in Order

Everything here is free unless your site has more than 500 URLs. This is the order I'd run it in:

1. Page Indexing report in Search Console. See which pages are out and why, then sort out the ones you need.
2. URL Inspection on your five most important pages. Confirm they're indexed and that Google picked the canonical you wanted.
3. Core Web Vitals report. It's Google's own data from real users, and it's easy to miss.
4. A crawl with Screaming Frog. The free version handles 500 URLs. Look for 404s, redirect chains, missing titles and stray noindex tags.
5. Read your robots.txt. Every line. Make sure nothing you need is blocked.
6. Open the site on a real phone. Walk your main path from landing page to contact form.
7. View source on a key page. Your main text should be in the HTML.
8. Rich Results Test on one page per template. Fix errors. Warnings can wait.

On client sites I feed the crawl into AI to cluster the findings by pattern and review the result myself. Once the big items are fixed, the monthly maintenance checklist keeps them fixed.

When to Get Help

I sell SEO consulting, so I'll tell you where you don't need it: most of that list is an afternoon with Search Console.

Bring someone in when a relaunch or platform change is coming, when important pages drop out of the index and you can't see why, when the site depends on JavaScript to render its content, or when you run several languages or domains. In those cases a mistake costs more than the help. What the help costs depends on the size of the site.

I can't promise that fixing the technical layer moves you up. This post sat at position 71 with every tag in place. What I can tell you is whether the plumbing is what's holding your site back, or whether your money belongs somewhere else. Let's talk if that sounds useful.