Zum Inhalt springen
← All posts

Technical SEO: The Basics Before the Content

The best content is worthless if Google cannot crawl and index it. The technical SEO foundations from robots.txt to Core Web Vitals and hreflang – including the WordPress mistakes I keep finding in audits, plus a checklist.

Technical SEO basics are the least glamorous part of search visibility – and the most common reason it never arrives. Every few months someone contacts me who has been publishing blog posts diligently for a year and cannot understand why nothing ranks. The answer is often a single line of code: a forgotten noindex tag, a robots.txt blocking the wrong path, a sitemap full of dead URLs. The best content in the world is worthless if Google cannot crawl it, index it or render it properly.

In this article I walk through the technical foundations in the order search engines need them: crawling, indexing, speed, structure. Including the WordPress traps I keep finding in audits, and a checklist at the end that you can work through on your own site.

Why the technical layer comes before content

A search engine’s pipeline is straightforward: first the bot crawls a page, then Google decides whether to index it, and only after that does ranking even become a question. Each stage depends on the one before it. Content optimization targets stage three – if stage one or two is broken, you are optimizing into a void. That is why every SEO project I take on starts with a technical audit. It typically takes two days and delivers more than three months of content production built on a broken foundation.

Crawling and indexing: can Google even reach your pages?

robots.txt: small file, big consequences

The robots.txt file controls which areas search engines may crawl. Two mistakes show up constantly. First, blocking CSS and JavaScript files – Google renders pages like a browser and needs these resources to evaluate layout and mobile usability. Second, trying to keep pages out of the index via robots.txt. That does not work: a blocked page can still end up indexed, just without content, showing the infamous no-information snippet. Excluding a page from the index is the job of a meta robots noindex tag – and for Google to see that tag, the page must be crawlable.

XML sitemap: the table of contents for bots

Your sitemap should list every URL you want indexed – and nothing else. WordPress ships its own sitemap since version 5.5; SEO plugins like Rank Math or Yoast generate better ones. The rules: serve exactly one sitemap (two parallel SEO plugins happily produce two), no redirects or 404s inside it, and submit it in Google Search Console. The Search Console indexing report then shows you which URLs Google knows but chose not to index – the single most valuable free diagnostic tool you have.

On larger sites, crawl budget enters the picture: Google only crawls a limited number of URLs per site. Every error page, redirect chain and indexable filter variant burns budget that your important pages then lack. Below 500 pages this is rarely an issue – on shops with faceted filter URLs, it is a chronic one.

The classic: the forgotten noindex

WordPress has a checkbox under Settings > Reading: discourage search engines from indexing this site. It gets ticked on the staging environment during a relaunch and forgotten at go-live – and the site becomes invisible to Google. I have seen this go unnoticed for months. After every launch, this checkbox belongs at the very top of your verification list.

Canonical tags and duplicate content

Every page should be reachable under exactly one URL. In reality, variants multiply fast: with and without www, with and without a trailing slash, with campaign parameters, as a print version. The canonical tag tells Google which variant is authoritative. WordPress SEO plugins set it automatically – which is exactly why you should verify it: on paginated archives, filtered shop pages and multilingual setups I regularly find canonicals pointing at the wrong page, quietly knocking whole sections out of the index. On top of that, server-level redirects must be clean: http to https, www to non-www (or the other way round), in a single hop, with a 301 status.

Speed and Core Web Vitals

Page speed has been a ranking factor for years, measured through the Core Web Vitals. Google evaluates real user data from the Chrome User Experience Report – not your lab test on a fast office connection. The three metrics and their thresholds:

Metric Measures Good Poor
LCP (Largest Contentful Paint) Load time of the largest visible element under 2.5 s over 4.0 s
INP (Interaction to Next Paint) Responsiveness to user interactions under 200 ms over 500 ms
CLS (Cumulative Layout Shift) Visual stability while loading under 0.1 over 0.25

The usual suspects in WordPress: unoptimized images, plugin bloat, cheap shared hosting and page builders shipping tons of CSS and JavaScript. I cover how to find the real causes instead of fighting symptoms in my article on why your website is slow and what actually helps. Measure with PageSpeed Insights and focus on the field data section at the top – that is what Google actually uses.

Mobile first: Google only sees your mobile version

Google has indexed exclusively mobile for years. Whatever is invisible or unusable on a smartphone does not exist for search. Concretely: identical content on mobile and desktop (collapsible sections are fine), font sizes of 16 pixels and up, touch targets with enough spacing, no horizontal scrolling. And test on a real device, not just a resized browser window – menus and forms often behave differently on actual touchscreens.

URL structure: short, readable, permanent

Good URLs are short, describe the content and never change. For WordPress that means: permalink structure set to post name, no cryptic parameters, lowercase, hyphens instead of underscores. Keep the hierarchy flat – two levels of depth are enough for most websites. And when a URL does have to change, set a 301 redirect from the old address to the new one, without exception. Every forgotten redirect throws away rankings you already earned.

Hreflang: mandatory for multilingual sites

If you serve customers in the DACH region and internationally – as I do with this German and English site – hreflang tags tell Google which language version is meant for which users. Without them, your language versions compete against each other, or Google shows the German page to visitors searching in English. The rules: every page references all of its language variants including itself, the references must be reciprocal, and an x-default entry covers everyone else. Polylang or WPML generate the tags automatically – but verify that every translation is actually linked. A single orphaned page without a return link invalidates the whole cluster for that URL.

Structured data: context for machines

Schema.org markup in JSON-LD format tells Google what your content is: an organization, an article, a product, an FAQ. It is not a direct ranking factor, but it is the entry ticket to rich results – star ratings, FAQ dropdowns and breadcrumbs in the search results, which measurably improve click-through rates. For a business website, the sensible baseline is Organization or LocalBusiness, Article for blog posts and BreadcrumbList. SEO plugins generate the skeleton; validate the output with Google’s Rich Results Test.

Typical WordPress mistakes from my audits

  • The staging-phase noindex checkbox still active after go-live
  • Attachment pages for every uploaded image left indexable – thin content in its purest form
  • Two SEO plugins generating competing sitemaps and duplicate meta tags
  • Tag archives with one post each, bloating the index
  • A publicly reachable, indexed staging environment – duplicating the entire site
  • Internal links pointing at http or www variants, creating redirect chains

Your technical SEO checklist

  1. Verify the WordPress noindex setting
  2. Check robots.txt: nothing important blocked, CSS and JS crawlable
  3. One clean XML sitemap, submitted in Search Console
  4. Review the Search Console page indexing report
  5. https and www redirects resolve in one 301 hop
  6. Spot-check canonical tags, especially on archives and filters
  7. Core Web Vitals field data in the green in PageSpeed Insights
  8. Test mobile rendering on a real device
  9. Hreflang reciprocal and with x-default on multilingual sites
  10. Validate structured data with the Rich Results Test

Conclusion

Technical SEO is unspectacular – no item on this list will make you visible overnight. But any one of them can make you invisible if it breaks. The good news: unlike content, the technical layer is a bounded project. Set it up cleanly once, keep an eye on it through ongoing website care, and the foundation carries you for years. Only then does every hour you invest in content actually pay off – and only then does a professionally built website translate into visibility.

Want to know where your site stands technically? As part of my technical consulting I audit exactly these points and hand you a prioritized action list instead of an 80-page PDF. Drop me a line – the first look costs nothing.

Häufige Fragen

What does technical SEO include?

Everything that lets search engines access and evaluate your site: crawl control via robots.txt, indexing via sitemaps and meta robots tags, canonical tags, page speed and Core Web Vitals, mobile usability, URL structure, hreflang for multilingual sites and structured data.

How do I check whether my website is indexed?

The quick test is a site: query in Google (site:yourdomain.com). The reliable answer comes from Google Search Console: the page indexing report shows which URLs are indexed and exactly why others were excluded – free and straight from Google.

Is technical SEO more important than content?

It is the precondition for content to work at all. Without clean indexing and acceptable load times, even excellent content will not rank. The reverse is also true: a technically flawless site with no relevant content ranks for nothing. Fix the technical layer first, then invest in content.

Do I need hreflang with only two languages?

Yes. As soon as multiple language versions exist, every page should carry reciprocal hreflang references to all variants plus an x-default. Otherwise the versions compete against each other in the index, or users land on the wrong language.

Free checklist: 10 points before your website goes live

Practical tips from real projects — straight to your inbox, no spam. Unsubscribe any time.

    Alex
    Alex · Buntweb

    Web developer and IT service provider from Vienna. For over ten years I have been building and maintaining websites and online shops — focused on clean technology, honest advice and solutions that work in everyday business.

    Ask a question