Technical SEO: the basics that actually matter
8 min read
by Marcel, Senior software engineer
A lot of website owners know the feeling: you have a good-looking site, but it just doesn't show up on Google. Often that's not down to the content — it's down to the technical side. Here are the most important technical SEO basics, explained in plain language.
The short version
- Core answer: If your site isn't ranking, the cause is often technical — not your content.
- Can Google find it? A sitemap, robots.txt, clean URLs and canonicals decide whether pages get indexed.
- Speed & mobile: Core Web Vitals and the mobile version are ranking signals — real, but weaker than good content.
- Where to start: Always a technical SEO check — measure before you optimize.
The three pillars of SEO
SEO stands on three legs: technology, content and links. Content and backlinks get most of the attention — yet the technical side is the foundation. If that isn't right, the other two fizzle out. A search engine has to be able to read and understand your page before good content even gets a chance.
If your time is limited, work through the following five points in exactly that order. An indexing problem makes any speed work worthless, and duplicate URLs devalue every piece of content you write afterwards.
1. Can Google find your site at all?
Before a page can rank, it has to get indexed. For that, Google needs clear signposts:
- A sitemap listing all your important pages.
- A robots.txt that controls crawling.
- Clean, readable URLs without the clutter.
- Canonical tags that clearly assign duplicate content.
If those building blocks are missing, Google may well overlook exactly the pages you want to rank.
You can look this up in Search Console under Indexing → Pages. Every page that is not indexed comes with a reason, and these four account for most of them:
| Message | What is actually behind it |
|---|---|
| Blocked by robots.txt | Usually a Disallow: / line that travelled from the staging environment to the live site. |
| Excluded by 'noindex' tag | A <meta name="robots" content="noindex"> in the template — or, in WordPress, the "Discourage search engines from indexing this site" checkbox. |
| Discovered – currently not indexed | Google knows the URL but has not fetched it. Typical for pages that barely get linked internally. |
| Crawled – currently not indexed | Not a technical fault but a quality judgement. No tag fixes this; better content does. |
The last message is the one most often treated wrongly: reacting to it with sitemap tuning repairs something that is not broken. For a single URL, the URL inspection tool at the top of Search Console gives the definitive answer — whether indexing is allowed, which URL Google picked as canonical, and when it was last crawled.
2. How fast does your site load?
Speed is a confirmed ranking signal, but a weak one: with comparable content it can tip the balance, it does not replace better content. Its bigger lever is conversion. Google measures it through the Core Web Vitals: how quickly does content become visible, how quickly does the page respond, how stable is the layout while loading? Every second of load time costs you visitors. A technically lean site wins twice here.
Concretely there are three numbers, each measured against the slowest 25 % of your real visits:
- LCP (Largest Contentful Paint) — when the largest element becomes visible: good up to 2.5 s.
- INP (Interaction to Next Paint) — how quickly the page responds to input: good up to 200 ms. INP replaced the old FID metric in March 2024; any guide still talking about FID is older than that.
- CLS (Cumulative Layout Shift) — how much the layout jumps while loading: good up to 0.1.
The distinction that matters is lab versus field: PageSpeed Insights shows the real numbers from your visitors over the last 28 days at the top — if there is enough data — and a lab test from a simulated environment below. The field data is what counts. A green lab score next to red field data simply means your visitors have slower devices and connections than the test run.
3. Does your site speak the search engine's language?
With structured data (Schema.org) you tell Google directly what a page is about: is this an article, an FAQ, a local business, an offer? That increases your chances of rich results — the more eye-catching listings with stars, prices or extra info.
Worth knowing, because a lot of guides are out of date here: expandable FAQs in search results are gone for ordinary websites. Since August 2023 Google only shows them for well-known, authoritative government and health sites, and HowTo rich results were dropped entirely. FAQ markup does no harm and still helps machines understand the page — but building it for the expandable listings means planning around a feature you no longer get. What still works: Article, Product, LocalBusiness, BreadcrumbList and Organization. We go through what that looks like in practice for an online store in our Shopware SEO guide.
The typical mistake here is not missing markup but contradictory markup: two Article blocks on one page, a price in the markup that differs from the price on the page, or review stars for a product that shows no reviews anywhere. Google explicitly requires structured data to reflect what visitors actually see. When it does not, the consequence is not just "no rich result" but, at worst, a manual action.
The Rich Results Test distinguishes two levels: warnings mean recommended fields are missing and the rich result is still possible. Errors mean required fields are missing, and then the whole type drops out. The same findings show up collected under Enhancements in Search Console — though only after Google has re-crawled the page.
4. Does everything work on a phone?
Google primarily evaluates the mobile version of your site. If it isn't properly optimized for phones, you lose rankings — no matter how good the desktop version looks.
Three failure patterns come up most often:
- Horizontal scrolling. A single fixed-width element — usually a table, a code block or an oversized image — breaks out of the viewport, and the whole page slides sideways. You spot it when text looks cut off at the right edge.
- Tap targets that are too small. Links and buttons sitting closer than roughly 48 px apart are hard to hit reliably with a thumb. It almost always affects navigations carried over one-to-one from desktop.
- Zoom disabled.
user-scalable=noormaximum-scale=1in the viewport meta tag stops anyone from magnifying the page. That is not just unfriendly, it is an accessibility violation — and under the European Accessibility Act a legal problem for many services.
Guides are out of date here too: Google's Mobile-Friendly Test and the "Mobile Usability" report in Search Console were both retired in December 2023. Today you check in Chrome DevTools' device mode or through the mobile tab of PageSpeed Insights.
Top tip
The first step is always a technical check. Only once you know where things are stuck does it make sense to optimize deliberately — instead of blindly turning knobs.
5. Is every piece of content reachable at exactly one URL?
The most common technical mistake we see is the same content reachable under several URLs: with and without www, http and https, with and without a trailing slash, plus print or filter variants. Search engines then split the signals across those copies instead of counting them once.
Fix it in this order: pick one canonical variant, redirect all others with a 301, set a self-referencing canonical tag on every page, and make sure your sitemap only lists the canonical URLs. If your site was recently moved and one variant answers while the other does not, the cause is usually DNS rather than SEO — that path is covered in fixing DNS problems. Once speed is the bottleneck instead, improving Core Web Vitals is the next step.
How to check this yourself
Everything above can be measured without a budget. These four tools cover 90% of cases:
| Tool | What for | Cost |
|---|---|---|
| Google Search Console | Indexing, error pages, real Core Web Vitals from your actual visitors | free |
| PageSpeed Insights | Load time per page, concrete suggestions | free |
| Rich Results Test | Checks whether Google can read your structured data | free |
| Screaming Frog | Crawls the whole site: dead links, missing titles, canonical errors | free up to 500 URLs |
The order matters: start with Search Console. It shows what Google actually does with your site — everything else is lab data.
The good thing about technical SEO
Unlike content or backlinks, technical SEO is measurable and plannable. You can see exactly what's broken, fix it, and verify the result. That's precisely where we start: we remove the technical brakes that are costing you visibility, and create the best possible starting position for good rankings.
Wondering why your website isn't getting found? We'll run a technical SEO check and tell you concretely what's holding it back.
Frequently asked questions
What is technical SEO?
Technical SEO is everything that lets a search engine read, understand and quickly serve your site: sitemap, robots.txt, clean URLs, canonical tags, load time, structured data and the mobile version. It’s the foundation the other two pillars, content and links, stand on. If that isn’t right, good content never gets its chance.
Why isn’t my website getting found on Google?
Often it’s not the content but the technical side: pages that never get indexed, missing signposts like a sitemap or canonicals, slow load times, or a mobile version that doesn’t hold up. Google primarily evaluates the mobile version, so a site that only shines on desktop loses rankings.
Do I need structured data on my website?
With structured data you tell Google directly what a page is: an article, an FAQ, a local business, an offer. That raises your chances of rich results — the more eye-catching listings with stars, expandable FAQs or extra info. It won’t fix a slow or unindexable site, though.
Where should I start with technical SEO?
Always with a technical check. Unlike content or backlinks, technical SEO is measurable and plannable: you can see exactly what’s broken, fix it and verify the result. Only once you know where things are stuck does it make sense to optimize deliberately instead of blindly turning knobs.