Technisches SEO

Technische SEO ist eine der kompliziertesten und manchmal kostspieligsten Disziplinen im Marketing. Gleichzeitig es sie aber oft der entscheidende Faktor für den Erfolg deines Marketings, denn die Optimierung der technischen Plattform ist wichtig für das gesamte Unternehmen. Wir haben diesen Leitfaden für dich erstellt, wenn du mehr über die technische Optimierung deiner Website erfahren möchtest. Hast du nach Lesen dieses Artikels noch Fragen? Dann wende dich doch gerne an uns!

Technisches SEO ist umfassend

Wie du sicherlich auch gemerkt hast, ist technische SEO nicht etwas, das man einfach so macht. Es dauert lange, aber es gibt wirklich eine Menge Punkte, die man mit technischer SEO gewinnen kann. Wenn du dich deinem technischen SEO widmest, optimierst du bei richtiger Umsetzung die gesamte Website. Wenn wir das Beispiel nehmen, dass auf deiner Website X Sprachen angeboten werden, können wir dies mit der Anzahl der Länder multiplizieren, in denen diese gesprochen werden. Es macht also einen großen Unterschied aus, wenn man die Technik richtig beherrscht.

KOSTENLOSE SEO-ANALYSE - Ist deine Seite für Suchmaschinen optimiert?

Fülle einfach das Kontaktformular aus und du bekommst von uns eine KOSTENLOSE Überprüfung deiner Webseite im Hinblick auf SEO. Selbstverständlich stehen wir dir im Anschluss für Fragen, Probleme oder eine tiefergehende Analyse zur Verfügung.

Was umfasst das technische SEO?

Code-Optimierung

Je fehlerfreier und effizienter der Code einer Website ist, desto besser ist das Nutzererlebnis, wenn die Website besucht wird. Wahrscheinlich hast du schon einmal erlebt, dass eine Website sehr lange braucht, um zu laden, oder dass ein Link am Ende eine Fehlerseite anzeigt. Wahrscheinlich hast du auch schon einmal eine Website besucht, bei der einige der Elemente, aus denen die Website besteht, nicht geladen werden, sodass die Funktionen nicht wie vorgesehen funktionieren. All diese Unzulänglichkeiten sorgen für ein schlechtes Besuchererlebnis, weshalb moderne Suchmaschinen, allen voran Google, darauf bedacht sind, optimal funktionierende und schnell ladende Websites zu belohnen und Websites, die Probleme bereiten, indirekt zu bestrafen.

Nachdem Google dazu übergegangen ist, die mobile Version der Website vor der Desktop-Version zu indizieren, wurde den vielen technischen Aspekten, die hinter dem Aufbau der Website stehen, große Aufmerksamkeit geschenkt.

Verlangsamende Inhalte

Eines der wichtigsten Elemente für ein gutes Nutzererlebnis ist die Geschwindigkeit, mit der eine Website geladen wird, und die Reihenfolge, in der die Elemente geladen werden. Wenn viel JavaScript und CSS verwendet wird, um das Erscheinungsbild der Website zu gestalten, wirkt dies als Rendering-Block und verlangsamt den visuellen Inhalt der Seite, vor allem, wenn die Code-Referenzen in den <head> der Seite eingefügt werden. Aber auch Inline-CSS und JavaScript wirken wie ein Rendering-Block.

Es geht darum, so wenig JS und CSS wie möglich am Anfang des Codes der Website zu verwenden und weniger wichtige Skripte an das Ende des Codes zu verschieben.

Das Entfernen von Skripten, die das Rendering blockieren, ist eine Aufgabe für Entwickler und kann kostspielig sein, aber es kann einen großen Unterschied machen und muss nur einmal durchgeführt werden, um für die gesamte Website zu funktionieren.

Hier kannst du Googles eigene Empfehlungen zu diesem Thema lesen: https://developers.google.com/web/tools/lighthouse/audits/blocking-resources

Verringerung der Anzahl von Anfragen

Je mehr Ressourcen, auch Anfragen genannt, für die Erstellung einer Website benötigt werden, desto komplizierter und verwirrender wird es, sicherzustellen, dass alles zusammen funktioniert. Ein weiterer Vorteil des geringeren Ressourcenverbrauchs ist, dass die Seite schneller geladen wird. Das liegt daran, dass es eine begrenzte Anzahl von Verbindungen gibt, die einem einzelnen Benutzer/Besucher auf dem Server, auf dem sich die Seite befindet, zur Verfügung stehen.

Wenn z. B. fünf Verbindungen verfügbar sind, werden diesen die ersten fünf Ressourcen zugewiesen, und erst wenn alle fünf Ressourcen geladen sind, werden die nächsten fünf Ressourcen zugewiesen. Wenn eine dieser Ressourcen sehr groß oder kompliziert zu verarbeiten ist, wird das Laden der nächsten fünf Ressourcen daher unnatürlich lange warten.

Ein weiteres Element der Herausforderung der Ressourcenzählung besteht darin, dass Regeln dafür aufgestellt werden können, welche Ressourcen geladen werden dürfen und welche Ressourcen verarbeitet werden müssen, bevor sie geladen werden können, und zwar für jede Datei. Es kann sein, dass die Suchmaschinenroboter eine Datei aufgrund einer Regel in der robots.txt der Seite nicht laden dürfen, oder dass eine Datei aufgrund einer Regel in der .htaccess oder web.config des Servers umgeleitet werden muss

Diese Sicherung der Regeln muss für jede Ressource durchgeführt werden und erhöht natürlich die Gesamtladezeit der Seite exponentiell im Verhältnis zur Anzahl der auf der Seite zu verwendenden Ressourcen.

Tote oder umgeleitete Ressourcen

Wenn wir bei der Idee der 5 Verbindungen zu Ressourcen auf dem Server bleiben, dann ist ein weiteres Hindernis für schnelles Laden, wenn eine Ressource verschoben wurde oder nicht mehr existiert.

Wenn eine Ressource verschoben wurde und eine Regel für einen neuen Standort existiert, um sie zu finden, wird die bestehende Verbindung abgebrochen und die neue Ressource wird in die Warteschlange der nächsten Runde gestellt.

Wenn eine Ressource gelöscht wurde oder nicht geladen werden kann, führt dies zu einer unnatürlichen Zeitverzögerung, da der Server je nach Einstellung eine bestimmte Anzahl von Versuchen unternimmt, was das Laden unnötig verlangsamt.

Effiziente Codeausführung

Es gibt Regeln dafür, wie der Code, mit dem eine Website erstellt wird, zusammengesetzt sein sollte, und unordentlicher und nicht gut durchdachter Code kann die schnelle Ausführung des Codes behindern. Die meisten Browser und Suchroboter können erraten, wie der Code aussehen sollte, und so das richtige Ergebnis anzeigen, aber jedes Mal, wenn kreatives Denken erforderlich ist, braucht es Zeit.

Im Folgenden findest Sie ein Beispiel dafür, wie der Code erstellt werden sollte, und ein Beispiel für eine fehlerhafte Anwendung.

<p class=“correct“>

<strong>Dieser Text ist fett</strong> und <em>Dieser Text ist kursiv </em><br />
Dies ist ein Link zu <a href=“https://www.riveronline.dk“>RiverOnline.dk</a><br />
<img src=“https://www.riveronline.dk/kodeafvikling.jpg“ alt=“Code Abspulen“ />

</p>

<p class=“wrong“>

<strong>Dieser Text ist fett <em>und dieser</strong> Text ist kursiv <br>
Dies ist ein Link zu <a href=“https://www.riveronline.dk“>RiverOnline.dk<br>
<img src=“https://www.riveronline.dk/kodeafvikling.jpg“></em>

</p></a>

Es ist erlaubt, z. B. <strong> und <em> zu kombinieren, aber du musst daran denken, die Elemente in der umgekehrten Reihenfolge zu schließen, in der sie geöffnet werden, wie aus dem nachstehenden Code hervorgeht.

<p><strong>Dies ist fetter Text, der auch <em>kursiv</em></strong></p> sein kann.

Der Server

Es gibt einen großen Unterschied zwischen den Webhosts, die man kaufen kann, und meistens steht der Preis im Zusammenhang mit der Qualität.
Wenn wir uns ansehen, wie der Server die an ihn gesendeten Anfragen verarbeitet, ist einer der entscheidenden Faktoren, wie lange es von der auf dem Server angeforderten Ressource bis zum Empfang des ersten Datenbytes durch den Browser dauert. Dies wird Time to First Byte (Zeit bis zum ersten Byte) genannt, abgekürzt TtFB, und wird oft als „Wartezeit“ der Seite bezeichnet.

Time to First Byte

Einige der Beschränkungen, die auf einem Server eingerichtet werden können, sind, wie viel Rechenleistung und wie viel RAM für die laufende Sitzung zur Verfügung gestellt wird.

Ein weiteres Element, das die Übertragungsgeschwindigkeit des Servers verlangsamen kann, ist die Anzahl der Verbindungen und die Anzahl der Aufrufe an die Datenbank, die vorgenommen werden müssen. Je komplizierter und je größer die Datenmenge ist, die aus dem Datenspeicher abgerufen werden muss, desto länger dauert die Zusammenstellung der Daten, die an den Browser des Besuchers zurückgeschickt werden sollen.

Wir haben bereits erwähnt, welche Regeln in .htaccess und robots.txt aufgestellt werden können, und wenn es zu viele unnötige Regeln gibt, kann dies dazu beitragen, dass das erste Byte der Daten auf der Seite verzögert wird.

Neben der Sicherstellung, dass der Server über die notwendigen physischen Voraussetzungen verfügt, um die komplizierten Anfragen zu bearbeiten – eine Aufgabe, die vom Hosting-Unternehmen übernommen werden sollte -, kann das Caching zur Beschleunigung der Seiten eingesetzt werden.

Caching

Durch eine angemessene Einrichtung des Caching konnten wir die Ladegeschwindigkeit und den TtFB erheblich reduzieren. Dies liegt daran, dass das System bereits einen Großteil des Codes ausgeführt hat, der zum Aufbau des Seiteninhalts erforderlich ist.
Die beiden am häufigsten verwendeten Caching-Optionen sind Browser-Caching und Server-Caching.

Server-Cache

Der Server, der für die Generierung der Webseite verantwortlich ist (d. h. die Webseite zusammenstellt), hat eine Kopie davon gemacht, wie die Webseite zuletzt aussah, so dass er sie nicht erneut generieren muss. Das spart Zeit (aber keine Bandbreite), weil der Server nicht erst mühsam eine ganze Seite aufbauen muss, sondern nur das senden kann, was er beim letzten Mal gesendet hat, als der Browser danach gefragt hat. Wenn jedoch Daten auf der Internetseite geändert werden müssen, ist der Server gezwungen, sein „Gedächtnis“, wie die Seite aussieht, zu löschen und die Seite neu zu generieren. Diese Art der Zwischenspeicherung ist nützlich, wenn die Seite sehr komplex ist und ihre Erstellung viel Zeit in Anspruch nimmt.

Browser-Cache

Dein Webbrowser (Chrome, Firefox, Safari, Edge oder was auch immer du verwendest) merkt sich, wie eine Webseite aussieht, damit er den Server nicht bitten muss, die Webseite erneut zu senden. Dies spart Zeit (und Bandbreite), da fast die gesamte Netzwerkkommunikation entfällt. Wenn der Server jedoch beschließt, das Aussehen der Webseite zu ändern, ändert sich Einiges, denn das „Gedächtnis“ des Browsers, wie die Seite seiner Meinung nach aussehen sollte, ist nun veraltet, und er zeigt dir eine alte Version der Seite anstelle der neuen. Aus diesem Grund wird manchmal empfohlen, den Cache des Browsers zu leeren – dadurch wird der Browser gezwungen, zu „vergessen“, wie die Seite aussieht. Dadurch muss er dann den Server nach der neuen, aktualisierten Version der Seite zu fragen.

Eine Möglichkeit, den Cache deines Browsers zu kontrollieren, besteht darin, ein Verfallsdatum, auch TTL genannt, für die vom Server abgerufenen Ressourcen festzulegen. Es ist auch möglich, ein Verfallsdatum für einzelne Ressourcentypen festzulegen, so dass beispielsweise Bilder eine lange Lebensdauer haben, während JavaScripts und CSS-Dateien eine kürzere Lebensdauer haben sollten. Dies geschieht in den Konfigurationsdateien der Website. Auf einem Apache-Server heißt die Datei .htaccess, auf einem IIS-Server heißt sie web.config.

SSL Zertifikate

Alle Websites sollten mit einem SSL-Zertifikat ausgestattet sein, nicht nur um die Vorteile der Suchmaschinen zu nutzen, sondern auch um die Daten zu schützen, die die Besucher auf deiner Website eingeben.

Ein SSL-Zertifikat schützt Daten wie persönliche Informationen im Zusammenhang mit Anmeldungen, Newsletter-Abonnements, Online-Einkäufen und viele andere Daten, die mit dem Server ausgetauscht werden.

Was ist ein SSL-Zertifikat?

SSL steht für Secure Socket Layer und ist eine Technologie, die die Kommunikation zwischen dem Browser des Besuchers und dem Server, auf dem die Website ausgeführt wird, sichert.

Es gibt viele verschiedene Arten und Varianten von SSL-Zertifikaten, und es ist wichtig, von Anfang an das richtige zu wählen. Wenn dein SSL-Zertifikat z. B. auch Subdomains abdecken muss, sollte es ein so genanntes „Wildcard“-Zertifikat sein, und wenn es mehrere verschiedene Domains abdecken muss, solltest du ein „Multi-Domain“-Zertifikat wählen.

Innerhalb jedes Zertifikatstyps gibt es auch verschiedene Schutzniveaus, und die Grundregel lautet: Je mehr Schutz, desto höher der Preis. Es gibt keinen Hinweis darauf, dass die verschiedenen Niveaus mehr oder weniger Einfluss darauf haben, ob und wie viel Gewinn die Seite von den Suchmaschinen erhält, verglichen mit einer Seite ohne SSL-Zertifikat.

Was kostet ein SSL-Zertifikat?

Die Kosten für ein SSL-Zertifikat können von ein paar Euro pro Jahr bis zu mehreren tausend Euro reichen. Das hängt in der Regel von der Umgebung ab, in der es installiert werden soll, vom Sicherheitsniveau und davon, ob es Subdomains abdeckt.

Einige Hosting-Unternehmen bieten ihren Kunden sogar kostenloses SSL an. In der Regel kannst du Zertifikate bei deinem Hosting-Unternehmen kaufen und sich dort beraten lassen.

Umleitungen

Du solltest versuchen, die Einrichtung einer Umleitung so weit wie möglich zu vermeiden, aber es gibt Situationen, in denen sich dies nicht vermeiden lässt. So kann es beispielsweise sein, dass du von einem CMS auf ein anderes umsteigen willst, was in vielen Fällen eine Änderung der Struktur und der URLs der Website zur Folge hat. In anderen Fällen kommt es vor, dass Produkte, Kategorien oder Marken gelöscht werden, und dann muss entschieden werden, was mit den alten Inhalten geschehen soll.
Es gibt viele verschiedene Arten von Umleitungen, aber die am häufigsten verwendete ist „301 Moved Permanently“.
Aber was passiert, wenn du keine Umleitung von Inhalten einrichtest, die entfernt werden, und die Seite einfach in Ruhe schlafen lassen?
Der Wechsel von einer Suchmaschine zu einer Fehlerseite ist für den Benutzer nicht angenehm, aber es gibt noch einen weiteren Aspekt zu berücksichtigen. Wenn die Seite, die heruntergenommen wird, einen Wert hat, geht dieser Wert verloren, während bei einer Umleitung ein Großteil des Wertes auf das neue Ziel übertragen wird.

Teste deine neuen Umleitungen

Wenn du Umleitungen vorgenommen hast und testen möchtest, ob sie korrekt durchgeführt wurden, kannst du folgendes Tool verwenden:
https://www.riveronline.de/301-redirect-checker
Wenn es richtig gemacht wurde, siehst du eine Zeile mit der Aufschrift „301 redirect“, gefolgt von „200 OK“.

Obwohl Google angibt, dass sie bis zu fünf Konversionen verfolgen, ist es wichtig, so wenige wie möglich zu verwenden. Bei jeder Umleitung geht ein kleiner Teil des Werts verloren, aber dies wirkt sich auch auf die Ladegeschwindigkeit und das Crawl-Budget der Seite aus.

Die Verfolgung deiner Links, insbesondere zu internen Ressourcen, zeigt, dass deine Website in dieser Hinsicht gut gepflegt ist.

Robots.txt, noindex und .htaccess/web.config

Es kann viele Gründe dafür geben, Seiten von der Indizierung auszuschließen oder Suchbots davon abzuhalten, Dateien zu betrachten. Aber es ist wichtig, dass du den Unterschied verstehst, bevor du dich für eine Methode entscheidest.

Robots.txt

Wenn du Inhalte auf deiner Seite hast, die aus irgendeinem Grund nicht von Suchmaschinen angezeigt werden sollen, solltest du diese Inhalte in der robots.txt-Datei der Seite ausschließen.
Dadurch wird verhindert, dass die Suchroboter die Datei oder das Verzeichnis durchsuchen, was aber nicht bedeutet, dass der Inhalt nicht in den Suchergebnissen auftaucht.

Noindex

Um zu verhindern, dass bestimmte Ressourcen in den Suchergebnissen erscheinen, wird der Meta-Code „noindex“ verwendet und wie folgt geschrieben:
<meta name=“robots“ content=“noindex“>

Wenn du die Suchroboter fernhalten willst und gleichzeitig nicht möchtest, dass der Inhalt in den Suchergebnissen zu finden ist, ist folgendes zu tun. Wenn wir die Suchbots in der robots.txt ausschließen, kommen sie nicht hinein und lesen den Code, in dem „noindex“ steht, und können daher weiterhin in den Suchergebnissen erscheinen.

.htaccess og web.config

Eine Datei, die immer gelesen wird, ist die .htaccess des Apache-Servers und die web.config des IIS-Servers. In diesen ist es möglich, „noindex“ für einzelne Ressourcen, ganze Verzeichnisse oder bestimmte Dateitypen einzurichten.
Da es nicht möglich ist, noindex im Metacode von z.B. Bildern, PDF-Dateien, Excel-Tabellen und anderen Nicht-HTML-Ressourcen zu setzen, ist es möglich, die Indizierung über die .htaccess oder web.config des Servers zu verhindern.

Nachstehend findest du den Code, den du in die .htaccess-Datei eines Apache-Servers einfügen musst, um die Indizierung ALLER PDF-Dateien auf der Domäne auszuschließen:

<FilesMatch „\.pdf$“>
Kopfzeile setzen x-robots-tag: noindex
</FilesMatch>

Hier ist der Code zum Ausschluss einer einzelnen PDF-Datei:

<Dateien Leitfaden.pdf>
Kopfzeile setzen x-robots-tag: noindex
</Dateien>

Es ist auch möglich, diese Regeln in der web.config eines IIS-Servers einzurichten, aber wir werden hier keine Empfehlung aussprechen, da dies einen tiefen Einblick in die anderen Einstellungen des Servers und die anderen Websites auf dem Server erfordert.

Sitemaps

Es gibt grundsätzlich zwei Arten von Sitemaps, eine im XML-Code-Format und eine mit HTML. Der Zweck der beiden Arten wird im Folgenden erläutert.
Eine Sitemap wird verwendet, um das Verständnis der Struktur und des Inhalts der Website zu unterstützen, sei es als Hilfe für den Besucher oder für eine Suchmaschine.
Meistens wird die Sitemap vom CMS-System erstellt, da sie nie statisch ist. Sobald du URLs für Inhalte erstellst oder sie umbenennst, sollte die Sitemap der Website diese Änderung widerspiegeln.

XML Sitemap

Es gibt auch verschiedene Arten von Sitemaps, wobei wir hier nur die gängigste behandeln werden, nämlich eine Liste der üblichen indizierbaren URLs, die in Suchmaschinen zu finden sind.
Du kannst auch Sitemaps für Bilder, Videos und Nachrichten erstellen, die in einem späteren Blogbeitrag behandelt werden können.
Es gibt auch zwei Möglichkeiten, eine XML-Sitemap zu erstellen, die wir hier zusammenfassen, aber nicht näher erläutern, da Google den Prozess sehr gut beschrieben hat – nachfolgend findest du die Links.

Sitemap.xml

Eine überschaubare Website mit weniger als 5.000 indizierbaren URLs kann in der Regel mit der Erstellung einer sitemap.xml-Datei mit den Seiten, die auf den Ergebnisseiten der Suchmaschinen erscheinen sollen, „auskommen“.
Google-Leitfaden zur Erstellung und Übermittlung einer Sitemap

Sitemap-index.xml

Eine große Website muss ihre Sitemap in der Regel in mehrere Dateien aufteilen, entweder wegen der Größenbegrenzung oder wegen der Anzahl der URLs in einer Sitemap.

Es kann auch von Vorteil sein, deine Seiten in Kategorien aufzuteilen, damit sie dem Indexierungsgrad der Bereiche entsprechen.

Kurz gesagt, eine sitemap-index.xml ist eine strukturierte Liste von sitemap.xml-Dateien

Google-Leitfaden zur Erstellung von Sitemaps

Wenn du dich eingehender mit den Möglichkeiten von Sitemaps und den Regeln, die für ihre Erstellung gelten, beschäftigen möchtest, kannst du sitemaps.org mehr darüber lesen

HTML sitemap

Eine HTML-Sitemap wird meist verwendet, um dem Besucher eine geordnete Liste der Seiten zu zeigen, die auf der Domain zu finden sind.

Sie kann dazu beitragen, die Website überschaubarer zu machen, aber eine Website sollte auch für sich allein stehen können. Die Notwendigkeit einer HTML-Sitemap ist häufig ein Zeichen für ein schlechtes oder unübersichtliches Design der Website.

Eine HTML-Sitemap hat auch einen SEO-Vorteil, da sie den Weg zu den inneren Seiten der Domain verkürzen kann. Dies ist jedoch nicht die Verwendung, die wir empfehlen, da sie meist durch eine unüberschaubare oder zu unübersichtliche Struktur der Website verursacht wird. Wenn deine Seiten innerhalb von 3 Klicks von der Startseite aus erreicht werden können, brauchst du aus SEO-Sicht keine HTML-Sitemap.

Wenn du dich dafür entscheidest, eine HTML-Sitemap zu erstellen, empfehlen wir, die Seite(n) auf noindex zu setzen, damit Suchmaschinen sie nicht in ihren Index aufnehmen. Aber warum? Die Seite bietet der Suchmaschine keinen Wert und handelt von nichts. Welches Schlüsselwort sollte die Suchmaschine also verwenden, um die Seite zu finden?

Sprachversionen und SEO

Wenn du mehrere Sprachversionen einer Website hast, solltest du die Seiten so zu kodieren, dass die verschiedenen Sprachversionen zusammenarbeiten, um den vollen Nutzen zu erzielen.

Zum Beispiel, wenn du eine deutsche, dänische, niederländische und englische Version deiner Website hast.

Wir empfehlen, immer eine generische Domain, auch gTLD genannt, für verschiedene Sprachversionen auf derselben Domain zu verwenden.

Die am häufigsten verwendete gTLD ist .com oder .net, aber es gibt eine große Anzahl von Optionen, die Sie unter dem untenstehenden Link finden können.

Liste der generischen Domänen oberster Stufe

Die beste Lösung, aber auch die zeitaufwändigste, ist natürlich eine eigene Domain für jedes Land, z. B. RiverOnline.de für Deutschland, RiverOnline.dk für Dänemark, RiverOnline.com für die USA. Dies kann jedoch eine teure Lösung sein, wenn nicht alle gewünschten Domains verfügbar sind. Außerdem ist die Einrichtung für den Entwickler komplizierter. Die meisten CMS-Systeme unterstützen heute jedoch mehrere Domains auf demselben CMS, sodass die Arbeit unabhängig davon, ob du eine oder mehrere Domains verwendest, gleich ist.

Die Entscheidung, welchen Domaintyp du verwenden möchtest, hängt jedoch ganz von deiner Situation ab.

Rel=alternate hreflang

Um den maximalen Querverweiswert aller Sprachvarianten Ihrer Website zu erhalten, müssen sie zusammen kodiert werden, und zwar nicht nur die Startseite, sondern alle Seiten, die eine andere Sprachvariante haben.

Sprachversionierte Inhalte auf verschiedenen Domains

Wenn du eine dänische Sprachvariante A hast, die in die deutsche Sprachvariante B übersetzt wird, und die niederländische Sprachvariante C und die englische Sprachvariante D, dann muss es zwischen ihnen allen rel=alternate hreflang-Referenzen geben.

Außerdem muss ein Verweis auf die Sprachvariante vorhanden sein, in die der Code eingefügt werden soll. Kurz gesagt, alle Seiten müssen auf alle Seiten verweisen.

Schließlich musst du für all diejenigen, die die Seite nicht auf Englisch, Deutsch, Niederländisch oder Dänisch sehen wollen, eine Sprachversion mit der Bezeichnung „x-default“ definieren, die einfach eine der bereits definierten Versionen sein kann, wobei es sich meistens um die englische Sprachvariante handelt.

Der Code für die Referenzen muss auf den vier Seiten des Seitenteils eingefügt werden.

So könnte es aussehen, ausgehend von RiverOnline.de

Sprachversionen von Inhalten auf derselben Domain

Es ist auch möglich, mehrere Sprachversionen auf derselben Domain zu haben, und im Prinzip folgt es demselben Rezept, als ob die verschiedenen Sprachversionen auf verschiedenen Domains existieren.

Sprachversionierte Inhalte auf Subdomains

Es ist auch möglich, Sprachversionen zu erstellen, indem du Subdomains für deine generische Top-Level-Domain einrichtest. Auch hier gilt die gleiche Vorgehensweise wie oben beschrieben.

Google-Leitfaden für lokalisierte Sprachvarianten

Sprachversionerte sitemap

Eine weitere Möglichkeit, die Sprachvarianten miteinander zu verknüpfen, ist eine Sitemap mit Sprachversionen.

Der einzige Unterschied zum Code, der auf den Websites der verschiedenen Domains eingefügt wird, besteht darin, dass es nicht möglich ist, eine „x-default“-Version für die Besucher zu definieren, die nicht unter die definierten Sprachen fallen.

Sprachvarianten und Regionen

Wenn du die Inhalte sprachlich anpassen musst, ist es wichtig, die richtigen Codes zu verwenden, um die Zielgruppe zu definieren. Im obigen Beispiel wird gezeigt, dass die Sprachvariationen nur auf die Sprache des Besuchers abzielen, aber es ist auch möglich, die Geographie zu definieren. Dies könnte der Fall sein, wenn du zwei Zielgruppen hast, die dieselbe Sprache sprechen, zum Beispiel einen englischsprachigen Engländer und einen englischsprachigen US-Amerikaner.

Ein rel=alternate hreflang, der auf diese beiden Zielgruppen ausgerichtet ist, könnte wie folgt aussehen:

Link zu ISO 639-1 Sprachvarianten

→ Verknüpfung mit ISO 3166-1 Alpha 2-Regionenformaten

URL-Struktur

Bei der Planung der Menüstruktur ergibt es am meisten Sinn, dass sie sich auch in der URL-Struktur widerspiegelt. Das heißt, wenn du einen Menüpunkt hast, der „Hausschuhe“ heißt, dann ist die Webadresse auch www.domain.de/hausschuhe und nicht www.domain.de/?item=1428.

Es gibt keine Regel ohne Ausnahmen, aber wenn man es dem Benutzer leicht macht, wird es auch dem Suchbot leicht gemacht, die Website zu crawlen.
Und wenn wir schon beim Thema Menüs und der Beziehung zu Suchmaschinen sind, müssen wir ein Thema erwähnen, das nicht sehr oft erwähnt wird, aber ein wichtiger Faktor dafür ist, wie Suchmaschinen Ihre Website wahrnehmen und bewerten, nämlich die „Crawl Depth“.

Was ist Crawl Depth?

Der Algorithmus-Parameter Crawl Depth gibt an, wie vielen internen Links man folgen muss, um zum Inhalt zu gelangen. Je weiter der Inhalt von deiner Startseite entfernt ist, desto weniger relevant wird er angesehen. Dies hat viele SEO-Spezialisten in der Vergangenheit dazu veranlasst, eine HTML-Sitemap zu empfehlen, aber das ist eine Flickschusterei für ein Problem, das besser auf andere Weise gelöst werden kann.

HTML Sitemap

Wir haben dies bereits besprochen, aber eine HTML-Sitemap birgt einige Herausforderungen. Während sie in diesem Fall das Problem des langen Weges zum Inhalt löst, gibt es auch andere Faktoren, die bei der Messung der Relevanz von Inhalten ins Spiel kommen. Es kommt nicht nur darauf an, mit wie vielen Klicks man zum Inhalt gelangt, sondern auch darauf, wie viele interne Seiten auf den Inhalt verweisen. Daher ist eine gut konzipierte Menüstruktur der Schlüssel zur Schaffung der besten Relevanz für Ihre Eckpfeilerinhalte. Es ist nicht beabsichtigt, dass jede Seite unbedingt zu jeder anderen Seite verlinken MUSS, aber so viele Seiten wie möglich sollten zu Ihrem Hauptinhalt verlinken.
Es gibt viele mehr oder weniger geniale Lösungen für dieses spezielle Problem. Wir müssen nicht viele Jahre zurückgehen, um ein linkes Menü mit 50-100 Links zum Seiteninhalt zu finden, aber die beliebteste Lösung ist derzeit das Mega-Menü.

Mega-Menü

Je nachdem, welches CMS du verwendest, ist es mehr oder weniger schwierig, ein Mega-Menü auf deiner Website zu implementieren, und vielleicht brauchst du nicht einmal ein Mega-Menü. Wenn du weniger als 50 Seiten hast, ist es wahrscheinlich nicht nötig, in diese Richtung zu schauen. Hier könnte ein „normales“ Dropdown-Menü, kombiniert mit einem Menü im „Servicebereich“ und einigen Reihen von Fußzeilen-Links, ausreichen. Wenn wir eine Größe erreichen, bei der du vielleicht zehn Hauptkategorien mit zehn Unterkategorien hast, dann nähern wir uns dem Punkt, an dem es notwendig sein könnte, in diese Richtung zu denken.

Es sollte erwähnt werden, dass der „Servicebereich“ einer Website der Bereich ist, in dem Besucher normalerweise Links zu „Kontakt“, „Über uns“, eine anklickbare Telefonnummer oder das Suchfeld finden, nämlich in der oberen rechten Ecke.

Wenn wir auf die Frage zurückkommen, wie eine gut aufgebaute URL-Struktur gewährleistet werden kann, dann kommen wir um Themen wie die Verwendung nicht-englischer Zeichen, die Verwendung von Parametern, den Aufbau von URLs mit mehreren Schlüsselwörtern und ein wenig mehr über die Länge nicht herum. Doch, bevor wir zu diesen Themen kommen, sollten wir definieren, was als URL gilt. Denn es sind nicht nur die URLs, die man eingibt, um zu einer Webseite oder Unterseite zu gelangen, sondern das oben Gesagte gilt auch für alle Ressourcen, die zum Aufbau der Website benötigt werden. Seien es JavaScripts, CSS-Dateien, Font-Dateien, Bilder und so weiter.

Erlaubte Zeichen in einer URL

Um es Suchmaschinen und Besuchern leicht zu machen, halte dich an Buchstaben des englischen Alphabets, numerische Werte und Bindestriche.

Die folgenden Zeichen sollten nicht in einer statischen URL enthalten sein: ! * ‚ ( ) ; : @ & = + $ , / ? % # [ ] < >

Diese Zeichen sind für andere Zwecke reserviert und werden z.B. dynamische URLs verwendet, bei denen Parameter helfen, den Seiteninhalt zu definieren. Das Pluszeichen wird verwendet, um ein Leerzeichen zu definieren, und wenn es irgendeinen Zweifel über die Arten von Adressen gibt, die ein @ verwenden, dann sind es E-Mail-Adressen. Die oben genannten haben also alle eine Funktion, die bei der Verwendung in URLs zu Konflikten führen kann.

Eines der Zeichen, das nicht „für andere Zwecke reserviert“ ist, von dessen Verwendung wir aber abraten, ist der Unterstrich. Das Zeichen ist die kleine Linie am unteren Rand, die oft zur Trennung von Wörtern in einer URL verwendet wird. Die Herausforderung besteht jedoch darin, dass Suchroboter den Unterstrich verwenden, um Text zu weniger Wörtern zusammenzufassen. Eine Webadresse wie www.domain.de/schwarze_hausschuhe wird als www.domain.de./schwarzehausschuhe angezeigt.

Wenn mehr als ein Keyword in der URL enthalten ist, wird empfohlen, einen Bindestrich zu verwenden, sodass die URL wie folgt aussieht: www.domain.de/schwarze-hausschuhe

Weitere Informationen über die Regeln für eine URL findest du hier: https://www.ietf.org/rfc/rfc1738.txt

Umlaute in der URL

Zwar können URLs mittlerweile auch die Umlaute ä, ö und ü enthalten – ratsam ist dies aber nicht. Stattdessen sollten Umlaute in ae, oe, und ue umgeschrieben werden.

Für Suchmaschinen macht dies keinen Unterschied. Sie verstehen, dass im deutschen „ae“ gleichbedeutend mit „ä“ ist. Ein Umlaut kann aber zu technischen Problemen führen, zum Beispiel innerhalb von Skripten oder beim E-Mail-Server.

Wenn du Zweifel hast, ob die Suchmaschinen ein ausgesuchtes Wort verstehen, versuche einfach, es in der Suchmaschine zu suchen, z. B. https://www.google.com/search?q=moehre.

INFO: URL steht für Uniform Resource Locator und ist eine Adresse für eine Ressource.

Wie lang darf eine Webadresse sein?

Es wird empfohlen, die URL so kurz und verständlich wie möglich zu halten. Bei der Arbeit mit Webshops stellen wir oft fest, dass es nicht möglich ist, sich nur auf eine Ebene zu beschränken. Ganz zu schweigen von den Optionen, die normalerweise zum Filtern und Sortieren zur Verfügung stehen. Man könnte sich vorstellen, dass die untenstehende URL die einzige Option für eine eindeutige URL in einigen CMS ist.

http://www.domain.dk/herre/hjemmesko/sorte?size=44&orderby=price&dir=desc&view=list

Diese URL ist 83 Zeichen lang, und wir haben schon URLs mit über 500 Zeichen gesehen. Es gibt eine Faustregel, mit der Sie hoffentlich nicht konfrontiert werden, die besagt, dass Sie unter 115 Zeichen bleiben sollten.

Die Verwendung von Parametern in URLs

Obwohl wir bereits geschrieben haben, dass du keine „?“und „&“in statischen URLs verwenden solltest, dies gilt nicht für dynamische URLs. Dynamische URLs werden verwendet, um Inhalte auf der Seite einzuschränken, zu sortieren oder zu definieren. Ein Beispiel für eine dynamische URL, die wir bereits erwähnt haben, und von der wir zwar abraten, die aber durchaus ihre Berechtigung hat, sind URLs wie www.domain.de/?item=1428.

Ein Beispiel für eine dynamische Webadresse, die wir in der Regel nicht vermeiden können, ist zum Beispiel www.domain.de/hausschuhe?color=black, die zu einer Seite mit Hausschuhen in der Farbe Schwarz führt. Ein weiteres Beispiel wäre www.domain.de/hausschuhe?color=black&orderby=price, das zwei Parameter hat, wobei als Trennung der beiden Parameter color und orderby ins Spiel kommt.

Bei der Verwendung von Parametern in deinen URLs sind bestimmte Vorsichtsmaßnahmen zu beachten, insbesondere das Risiko doppelter Inhalte, das sich sehr nachteilig auf die Chancen Ihrer Website auf eine Top-Platzierung für den betreffenden Suchbegriff auswirken kann. Wenn die Parameter nur die Produkte auf der Seite ändern und nicht den anderen Inhalt der Seite, wie den Titel, die Meta-Beschreibung oder den Onpage-Text, wäre die richtige Lösung, den Inhalt der vielen Kombinationen auf der Hauptseite zusammenzuführen. Die Technik, mit der bei der Anwendung von Parametern der Wert aus mehreren Kombinationen aggregiert wird, heißt rel=canonical und wird im folgenden Abschnitt erläutert.

Aber ich möchte für „Schwarze Hausschuhe“ gefunden werden?

Wenn du bei einer Suche gefunden werden willst. die eine Eingrenzung eines Themas enthält, wie z.B. „Hausschuhe“, erstelle hierfür eine eigene Landingpage für die Produkte, auf der du einen optimierten Titel, eine Meta-Beschreibung und Onpage-Inhalte definieren kannst. Dies könnte unter der URL www.domain.de/schwarze-hausschuhe geschehen.

Eine andere Lösung könnte darin bestehen, die Seite über Hausschuhe so zu optimieren, dass sie auch „schwarze Hausschuhe“ erfassen kann, aber dies ist selten die optimale Lösung, wenn es viele Farbvarianten gibt. Es kann schnell sehr umfangreich werden, wenn du zehn verschiedene Farben aus zehn verschiedenen Materialien mit 20 verschiedenen Größen haben.

Das sind insgesamt 2.000 Seiten, für die du einen eindeutigen Text erstellen und einen einprägsamen Titel und eine Metabeschreibung verfassen müsstest.

Eine gründliche Keyword-Analyse kann dabei helfen, herauszufinden, welche Bereiche es „wert“ sind, verfolgt zu werden.

Was ist rel=canonical?

Die Methode bzw. Technologie wurde 2009 von den Suchgiganten Google, Bing und Yahoo entwickelt, um das wachsende Problem der Identifizierung einzigartiger Inhalte und des Umgangs mit doppeltem Inhalt zu lösen.

In diesem Zusammenhang sollte erwähnt werden, dass rel=canonical nicht als Regel angesehen wird, was bedeutet, dass Suchmaschinen „entscheiden“ können, ein definiertes canonical zu ignorieren, aber es wird als ein starkes Signal für Suchmaschinen angesehen. Seine Verwendung wird als Methode zur Konsolidierung von Inhalten beschrieben, die nicht eindeutig sind.

Wir haben einen der Verwendungszwecke, nämlich die Konsolidierung von Inhalten im Zusammenhang mit der Verwendung von Parametern in URLs, bei denen sich der Inhalt nicht wesentlich ändert, abgerundet, und es ist auch die am häufigsten verwendete Option. Eine weitere Option, die in einigen CMS vorhanden ist, auch in einigen der großen, von denen man eigentlich erwarten würde, dass sie sich mit einem solch schwerwiegenden Problem befassen, sind Inhalte, die unter mehr als einer URL abgerufen werden können.

Fahren wir mit den schwarzen Hausschuhen fort, die einige Content-Management-Systeme unter mehreren URLs zulassen, z. B. www.domain.de/hausschuhe/schwarz und www.domain.de/schwarz/hausschuhe, je nach dem für den Zugriff auf den Inhalt verwendeten Pfad. Mit anderen Worten, derselbe Inhalt wäre anders, wenn Sie zuerst die Farbe und dann den Typ, d. h. Hausschuhe, auswählen würden.

In diesem Fall sollte man eine „Master-Variante“ für den Inhalt wählen und diese als „canonical“ der Seite definieren. Dies geschieht durch Einfügen eines Codes in den Quellcode der Seite. Der Code sollte im Kopfbereich der Seite eingefügt werden und wie folgt aufgebaut sein:

Wir persönlich würden das Hauptthema an die erste Stelle der URL setzen, in diesem Fall „Hausschuhe“ und nicht „schwarz“.

Eine weitere Möglichkeit, doppelte Inhalte zu vermeiden, besteht darin, eine URL auf die gewünschte Version umzuleiten, was jedoch nicht immer möglich ist, z. B. bei der Verwendung von Parametern. Der Vorteil der Verwendung von Weiterleitungen gegenüber kanonischen Weiterleitungen besteht darin, dass Weiterleitungen als Regel für Suchmaschinen gelten, die sie befolgen müssen, und dass wir daher doppelte Inhalte effektiv ausschließen.

Mehr über Redirects, oder Weiterleitungen auf Englisch, erfährst du mehr in diesem Artikel:

https://en.wikipedia.org/wiki/Canonical_link_element

Angebot für eine technische SEO-Analyse anfordern

Wenn du eine technische SEO-Analyse für deine Website erhältst, überprüfen wir die gesamte Website, finden alle technischen Herausforderungen und senden dir diese in einer nach Prioritäten geordneten Reihenfolge zu. Wir empfehlen oft, dass dein Entwickler für jede Aufgabe einen Preis festlegt. Auf diese Weise können wir gemeinsam entscheiden, worauf wir unsere Anstrengungen zuerst richten. Denn es kann teuer werden, alles reparieren zu lassen. Aber die Wirkung ist auch groß und lang anhaltend.

Kontaktiere uns und lassen dir dein individuelles Angebot für eine technische SEO-Analyse geben. Alle unsere technischen SEO-Maßnahmen werden von Mitarbeitern durchgeführt, die sowohl über einen Programmierhintergrund als auch über jahrelange Erfahrung im Bereich SEO verfügen.

Möchtest du deinen Online-Auftritt nachhaltig verbessern?

Dann lass dich von uns beraten und erhalte eine kostenlose Erstanalyse für deine Online Marketing Strategie.

Finn Lorenz
SALES DIRECTOR GERMANY & TEAM LEADER HAMBURG

   +49 174 90 94 766     fl@riveronline.de

Medarbejder