seitenpruefer.de

Ratgeber · best practices

Technisches SEO: Canonical, Viewport, lang und mehr

Die technische Basis entscheidet, ob eine Seite sauber indexiert und mobil nutzbar ist. Eine Checkliste zu Canonical-URL, Viewport, Sprach-Attribut, Zeichenkodierung, Robots-Meta und strukturierten Daten nach Schema.org.

Jan-Tristan Rudat
Jan-Tristan RudatRedakteur · SEO & Web-Standards
Veröffentlicht am ·Zuletzt geprüft am

Ein guter Text nützt wenig, wenn die Seite technisch stolpert. Eine falsch gesetzte Canonical-URL kann Suchmaschinen verwirren, ein fehlendes Viewport-Meta-Tag macht die Seite auf dem Handy fast unbrauchbar, und ein versehentliches noindex nimmt eine Seite komplett aus dem Index. Diese Fehler stecken alle im HTML, sind mit bloßem Auge im Browser oft nicht sichtbar und lassen sich trotzdem in wenigen Minuten beheben, wenn Du weißt, wonach Du suchst.

In diesem Ratgeber gehe ich mit Dir die technischen On-Page-Basics durch, die auch der Seitenprüfer im Technik-Block abklopft. Jeder Punkt kommt mit einer kurzen Antwort auf drei Fragen: Was ist das, warum ist es wichtig und wie sieht es konkret im Code aus. Am Ende findest Du eine kompakte Checkliste zum Abhaken. Wichtig vorweg: Es geht hier um Angaben, die im Markup liegen. Ladezeit und Crawling sind ein eng verwandtes, aber eigenes Thema, das ich am Schluss abgrenze.

Wenn Du zuerst den größeren Zusammenhang verstehen willst, lies die On-Page-SEO Grundlagen. Dieser Ratgeber setzt eine Ebene tiefer an und schaut auf den technischen Unterbau.

Canonical-URL: eine maßgebliche Adresse festlegen

Was. Das rel="canonical"-Tag im <head> sagt Suchmaschinen, welche URL die maßgebliche, kanonische Version einer Seite ist. Es ist ein Hinweis, keine Anweisung, aber ein starker.

Warum. Derselbe Inhalt ist oft unter mehreren Adressen erreichbar: mit und ohne www, mit und ohne abschließenden Schrägstrich, mit angehängten Tracking-Parametern wie ?utm_source=... oder in einer Druckversion. Für Suchmaschinen sehen das erst einmal alles verschiedene Seiten mit gleichem Inhalt aus. Dieses Duplicate-Content-Problem verteilt die Signale auf mehrere URLs, statt sie auf einer zu bündeln. Mit dem Canonical-Tag legst Du fest, welche Adresse zählt.

Beispiel. Die häufigste und sicherste Variante ist die Self-Canonical: Jede Seite verweist auf sich selbst, mit ihrer bevorzugten, absoluten URL.

<link rel="canonical" href="https://beispiel.de/produkte/schuhe/">

Ein paar Regeln aus der Praxis: Nutze immer eine absolute URL inklusive Protokoll, nicht /produkte/schuhe/. Setze pro Seite genau ein Canonical-Tag. Und lasse eine Seite nicht auf eine völlig andere, inhaltlich abweichende Seite zeigen, denn dann kann es passieren, dass die eigentlich gemeinte Seite gar nicht indexiert wird.

Viewport-Meta-Tag: die Grundlage für Mobilgeräte

Was. Das Viewport-Meta-Tag steuert, wie ein mobiler Browser die Seitenbreite interpretiert und skaliert.

Warum. Ohne dieses Tag nimmt ein Smartphone an, die Seite sei für einen Desktop mit rund 980 Pixeln Breite gebaut, und zoomt sie komplett heraus. Das Ergebnis ist eine winzige, kaum lesbare Darstellung, in der Nutzer erst hineinzoomen müssen. Da Suchmaschinen den mobilen Auftritt einer Seite als Hauptmaßstab nehmen, ist ein fehlendes Viewport-Tag nicht nur ein Komfort-, sondern ein handfestes Rankingproblem.

Beispiel. Der Standardwert deckt praktisch alle Fälle ab:

<meta name="viewport" content="width=device-width, initial-scale=1">

width=device-width sagt: Nutze die tatsächliche Gerätebreite als Basis. initial-scale=1 setzt die anfängliche Zoomstufe auf normal. Von Werten, die das Zoomen sperren (etwa maximum-scale=1 oder user-scalable=no), rate ich ab, denn sie schränken Menschen ein, die zum Lesen vergrößern müssen. Barrierefreiheit und gute Praxis fallen hier zusammen.

Sprach-Attribut lang: die Sprache benennen

Was. Das lang-Attribut am <html>-Element gibt an, in welcher Sprache der Seiteninhalt verfasst ist.

Warum. Screenreader entscheiden anhand dieses Attributs, mit welcher Aussprache sie einen Text vorlesen. Fehlt es oder ist es falsch, klingt eine deutsche Seite unter Umständen wie mit englischen Lautregeln vorgelesen, was das Zuhören erschwert. Auch Browser nutzen die Angabe, etwa für die richtige Silbentrennung und für das Angebot, eine Seite zu übersetzen. Suchmaschinen bekommen zusätzlich einen klaren Hinweis auf die Zielsprache.

Beispiel. Das Attribut steht direkt am öffnenden html-Tag:

<html lang="de">

Für eine schweizbezogene Variante wäre es lang="de-CH", für eine englische Seite lang="en". Wichtig ist, dass die Angabe zur tatsächlichen Sprache des Inhalts passt.

Zeichenkodierung: charset als Erstes im head

Was. Das <meta charset="utf-8">-Tag legt fest, mit welcher Zeichenkodierung der Browser das Dokument liest.

Warum. UTF-8 kann alle gängigen Zeichen darstellen, von deutschen Umlauten über das Euro-Zeichen bis hin zu Emojis. Ohne korrekte Angabe rät der Browser, und das geht bei Umlauten schnell schief: Aus „Größe” wird dann etwa „Größe”. Entscheidend ist auch die Position. Die Angabe muss innerhalb der ersten 1024 Bytes des Dokuments stehen, in der Praxis also als eine der allerersten Zeilen im <head>, noch vor dem Titel.

Beispiel. Die Kurzform hat sich durchgesetzt und gehört ganz nach oben:

<head>
  <meta charset="utf-8">
  <title>Beispielseite</title>
  ...
</head>

Robots-Meta: Indexierung steuern, und die Abgrenzung zur robots.txt

Was. Das <meta name="robots">-Tag steuert auf Seitenebene, ob eine Seite in den Index aufgenommen werden darf (index / noindex) und ob Suchmaschinen den Links auf der Seite folgen sollen (follow / nofollow).

Warum. Der Standard ist ohnehin indexieren und folgen, ein explizites index, follow schadet aber nicht und macht die Absicht klar. Gefährlich wird es andersherum: Ein aus einer Test- oder Entwicklungsumgebung übernommenes noindex sorgt dafür, dass die betroffene Seite dauerhaft aus den Suchergebnissen verschwindet, ganz gleich wie gut ihr Inhalt ist. Das ist einer der Fehler, die am meisten Schaden anrichten und zugleich am leichtesten zu übersehen sind.

Beispiel. So gibst Du eine Seite ausdrücklich zur Indexierung frei:

<meta name="robots" content="index, follow">

Und so nimmst Du eine Seite bewusst aus dem Index, etwa eine interne Danke-Seite:

<meta name="robots" content="noindex, follow">

Abgrenzung zur robots.txt. Beide klingen ähnlich, tun aber Verschiedenes. Die robots.txt liegt im Wurzelverzeichnis der Domain und regelt das Crawling: Sie sagt, welche Bereiche eine Suchmaschine gar nicht erst abrufen soll. Das Robots-Meta-Tag dagegen regelt die Indexierung einer bereits abgerufenen Seite. Ein wichtiger Nebeneffekt: Wenn Du eine Seite in der robots.txt sperrst, kann die Suchmaschine das noindex im Meta-Tag nicht mehr lesen, weil sie die Seite ja gar nicht abruft. Willst Du also sicher verhindern, dass eine Seite indexiert wird, nutze das Meta-Tag und sperre die Seite nicht zusätzlich per robots.txt.

Strukturierte Daten: Schema.org als JSON-LD

Was. Strukturierte Daten sind maschinenlesbare Zusatzangaben, die den Inhalt einer Seite in ein klares Vokabular übersetzen. Der Standard dafür ist Schema.org, das empfohlene Format ist JSON-LD, ein Skriptblock im <head> oder <body>.

Warum. Suchmaschinen erkennen so ohne Ratespiel, ob eine Seite ein Rezept, ein Produkt, ein Artikel oder ein Unternehmen beschreibt. Auf dieser Basis können Rich Results entstehen, also erweiterte Suchtreffer mit Sternebewertung, Preis, Kochzeit oder Autorenangabe. Strukturierte Daten sind kein Pflichtfeld und kein direkter Rankingfaktor, aber ein wertvoller Zusatz, der Deine Treffer auffälliger und aussagekräftiger macht.

Beispiel. Ein einfacher Artikel-Datensatz sieht so aus:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Technisches SEO: die wichtigsten Basics",
  "author": {
    "@type": "Person",
    "name": "Jan-Tristan Rudat"
  },
  "datePublished": "2026-07-06"
}
</script>

Wichtig ist, dass die strukturierten Daten den tatsächlich sichtbaren Inhalt der Seite widerspiegeln. Angaben, die im Markup stehen, aber auf der Seite nicht vorkommen, gelten als irreführend und können ins Gegenteil umschlagen.

Kurz weitere Punkte, die dazugehören

Einige technische Basics liegen teils außerhalb des reinen Seiten-Markups, gehören aber ins Gesamtbild:

  • HTTPS. Eine verschlüsselte Auslieferung ist heute Standard und Grundvoraussetzung. Interne Verweise und die Canonical-URL sollten konsequent auf die https-Variante zeigen.
  • Saubere URLs. Kurze, sprechende Adressen wie /ratgeber/technisches-seo/ sind lesbarer und stabiler als kryptische Parameter-Ketten. Eine konsistente Schreibweise (klein, mit Bindestrichen) vermeidet unnötige Dubletten.
  • hreflang bei mehrsprachigen Seiten. Wenn es eine Seite in mehreren Sprachen oder Länderversionen gibt, verknüpft hreflang die Varianten und sagt, welche für welches Publikum gedacht ist. Für eine einsprachige Seite ist das nicht nötig.
  • XML-Sitemap. Eine Sitemap listet die indexierbaren URLs einer Website auf und hilft Suchmaschinen, den Bestand zu erfassen. Sie liegt als eigene Datei vor und wird in der robots.txt oder der Search Console hinterlegt.

Wichtig: das sind Grundlagen aus dem Markup

Alle bisher genannten Punkte liest man direkt aus dem HTML einer Seite ab. Sie sind statisch, mit bloßem Blick in den Quelltext prüfbar und schnell zu korrigieren. Davon getrennt zu betrachten ist das Thema Performance und Crawling: Wie schnell lädt die Seite, wie schlägt sie sich bei den Core Web Vitals, wie effizient kann eine Suchmaschine die gesamte Website durchlaufen. Das hängt von Servern, Bildgrößen, Skripten und Caching ab und lässt sich nicht allein aus einem HTML-Schnipsel beurteilen.

Diese Trennung ist bewusst. Der Seitenprüfer konzentriert sich auf die Markup-Ebene, weil genau dort die häufigen, vermeidbaren und selbst behebbaren Fehler sitzen. Ladezeit-Analysen erfordern andere Werkzeuge, die eine Seite live abrufen und messen. Beides ist wichtig, aber es sind zwei unterschiedliche Baustellen.

Die Checkliste zum Abhaken

Gehe diese Punkte bei jeder Seite durch:

  • <meta charset="utf-8"> steht als eine der ersten Zeilen im <head>.
  • <html lang="de"> (oder die passende Sprache) ist gesetzt.
  • <meta name="viewport" content="width=device-width, initial-scale=1"> ist vorhanden.
  • Ein rel="canonical" verweist mit absoluter URL auf die maßgebliche Adresse (in der Regel Self-Canonical).
  • Die Robots-Angabe ist bewusst gesetzt und enthält kein versehentliches noindex.
  • Bei mehrsprachigen Seiten sind hreflang-Verknüpfungen vorhanden.
  • Interne Verweise und die Canonical zeigen konsequent auf https.
  • Optional: Strukturierte Daten als JSON-LD nach Schema.org, passend zum Seiteninhalt.
  • Eine XML-Sitemap existiert und ist hinterlegt.

So prüft der Seitenprüfer diese Punkte

Wenn Du den HTML-Quelltext einer Seite in den Seitenprüfer einfügst, wandern all diese Angaben in den Technik-Block der Auswertung. Die Prüfung läuft vollständig lokal in Deinem Browser, es wird nichts hochgeladen und nichts gespeichert.

Konkret schaut der Technik-Block nach: Ist ein charset gesetzt und steht es weit genug oben, trägt das html-Element ein lang-Attribut, existiert ein Viewport-Meta-Tag mit sinnvollem Inhalt, ist genau ein Canonical-Tag vorhanden und als absolute URL formuliert, und enthält die Robots-Angabe etwas Auffälliges wie ein noindex. Zusätzlich erkennt die Prüfung, ob strukturierte Daten im JSON-LD-Format eingebettet sind. Zu jedem Punkt bekommst Du eine klare Einordnung: vorhanden, fehlt oder sieht ungewöhnlich aus.

Damit hast Du in wenigen Sekunden einen Überblick, ob der technische Unterbau einer Seite sauber ist. Was Du danach angehst, entscheidet die Auswertung für Dich: erst die schwerwiegenden Fehler wie ein falsches noindex oder ein fehlendes Viewport-Tag, dann den Feinschliff. Wie die inhaltlichen Meta-Angaben dazu passen, liest Du im Ratgeber Meta-Tags, Title und Description.

Quellen

  • https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls
  • https://developer.mozilla.org/de/docs/Web/HTML/Viewport_meta_tag
  • https://schema.org/

Korrekturen oder bessere Quellen? Schreib an info@akara-solutions.de. Änderungen landen mit Datum auf /korrekturen.