> Schön, dass Ihr da seid!
> Checkliste:
> Wer bin ich?
> Was ist OMCampus?
> Was ist Bloofusion?
> Technical SEO – also SEO ohne:
> Content
> Off-Page
> Ziel:
> Wenn es optimalen Content gibt, dann diesen optimal für Suchmaschinen abbilden und indexierbar machen
> Fünf thematische Blöcke:
> Seiten + Website
> Crawling, Indexierung und Rendering
> Markup
> Internationalisierung
> Page Experience und Page Speed
> 14:00 Uhr – ca. 18:00 Uhr
> 15:30 – 16:00 Pause
> Bitte immer direkt stellen!
> … oder natürlich am Ende
> Wir haben noch ein Follow-Up:
> 11. September 10:00 Uhr
> Für alle Fragen, Unklarheiten …
> https://www.gotomeet.me/Bloofusion/technical-seo-fragestunde
> … erhaltet Ihr zeitnah
> In der Regel am nächsten Werktag per Mail (spätestens am übernächsten)
> Im HTML-Code: <head>…<title>Seitentitel</title>…</head>
> 50-60 Zeichen (inkl. Satz- und Leerzeichen, Desktop)
> Falls länger: in der Darstellung abgeschnitten
> Wichtige Suchbegriffe nach vorne
> An alle Seiten der Website identischen Brand anhängen („ – BRAND“ oder „ | BRAND“)
> Unique
> Ranking-relevant
> Im HTML-Code:
<head>…<meta name=“description“ content=„Meta Description“>…</head>
> 150-160 Zeichen (inkl. Satz- und Leerzeichen, Desktop)
> Falls länger: in der Darstellung abgeschnitten
> Wichtige Suchbegriffe irgendwo platzieren
> Gerne Sonderzeichen nutzen (2-3 Sätze)
> Unique
> Nicht Ranking-relevant
> Jede Seite sollte genau eine <h1> haben:
> Keine Längenvorgabe
> Suchbegriffe sollten vorkommen
> Für Besucher: „Du bist richtig hier“
> Idealerweise direkt oben im sichtbaren Bereich platziert
> Zwischenüberschriften:
> Nur für Content, nicht für Template
> Wenn es sinnvoll ist
> Wenn diese sich auf das Thema der Seite beziehen
> Möglichst:
> Hoch qualitativ
> Suchbegriffe aufgreifen (nicht mehr Keyword-Dichte!)
> Nicht eingeklappt oder anders „versteckt“
> Relevanten Text möglichst weit oben platziert
> Wenn sich die Bilder auf das Thema der Seite beziehen:
> Sprechende Bild-URL (also z. B. wandern-steiermark.png)
> Alt-Attribut (beschreibend ca. 6-10 Wörter)
> Bildunterschrift
> Oben platzierte Bilder ranken etwas besser als unten
> Bilder in der Nähe zu relevantem Text platzieren
> Nicht mehr sonderlich relevant
> Trotzdem:
> Keine Leerzeichen
> Keine Umlaute
> Bindestrich als Worttrenner
> Idealerweise alles in Kleinschreibung
> Am liebsten findet Google Inhalte über interne Verlinkungen
> Also:
> Alle Inhalte der Website sollten intern verlinkt werden
> Klicktiefe:
> Wie viele Klicks auf Links braucht es von der Startseite aus auf Inhalt X?
> Oftmals kritischer Faktor bei mittleren/großen Websites
> <a href=“URL“>Ankertext</a>
> Nicht:
> „hier…“, „klick!“ …
> Sondern:
> Möglichst auf Suchbegriffe abgestimmt
<a href=““>Kosmetikspiegel</a> = Seite ist relevant für „kosmetikspiegel“
> Verschiedene Metriken:
> Unique Inbound Links =
Wie viele unterschiedliche Seiten verlinken auf eine Seite?
> PageRank & Co =
Berechnungen der Link-Relevanz innerhalb der Website
> Wichtig:
> Relevante Inhalte brauchen viele Link Juice
> Irrelevante Inhalte sollten wenig Link Juice erhalten
> Wichtiges Tool für Technical SEO
> Viele Fehler kann man ohne Crawler kaum finden
> Also:
> Bitte unbedingt nutzen!
> Installation:
> Screaming Frog SEO Spider
(kostenlos bis 500 URLs, sonst 149 GBP/Jahr/Nutzer)
> Sitebulb
> Cloud:
> Ryte
> SEObility
> …
> Wichtiges kostenloses Google Tool
> Für die eigene Website Property anlegen
> Einige Reports/Funktionen schauen wir uns gleich an…
Discovery Crawling Rendering Indexing
> Crawling = Schritt 1
> Eine Seite wird von einem Crawler (Googlebot) heruntergeladen und bewertet
> Indexierung = Schritt 2
> Danach wird die Seite evtl. in den Index aufgenommen
> Alles, was gecrawlt wird, sollte im Index landen
Crawler: Seite A Crawler: Seite B Crawler: Seite C
Index: Seite A Index: Seite B Index: Seite C
> Alles, was gecrawlt wird, sollte im Index landen
Crawler: Seite A Crawler: Seite B Crawler: Seite C
Index: Seite B Index: Seite C Crawler: Seite D
Qualität gering
Alte URLs
> Der Oberbegriff für alle Google-Crawler
> support.google.com/webmasters/answer/1061943?hl=de
1. Das Crawl-Budget ist begrenzt Der Crawler ist sowohl mit neuen als auch mit alten Seiten
beschäftigt
Crawl-Budget-Optimierung = Der Crawler muss wenig „Müll“
holen
2. Die Gesamtbewertung aller Inhalte im Index
= viele dünne Inhalte schaden den guten Inhalten
Index Bloat = viele irrelevante oder dünne Inhalte im Index
3. Inhalte konkurrieren miteinander, z. B.
> Druckversion
> PDF-Export
4. Manche Inhalte sollen nicht gefunden werden
> Eine Textdatei unter http(s)://domain/robots.txt
> Anweisungen für Crawler, bestimmte Seiten nicht herunterzuladen
> = Verhindert das Crawling
> User-agent: *
Disallow: /compare Disallow: /checkout Disallow: /register
Disallow: /*action=produktfotos*
Disallow: /kommunion-2016/
Sperrt alle URLs, die mit /compare beginnen, also:
/compare /compare/
/compare/abc.php?id=33
Sperrt alle URLs, die action=produktfotos*
beinhalten, also:
/?action=produktfotos&id=33 /?id=33&action=produktfotos Gilt für alle Crawler
> Theoretisch kann man bestimmten Crawlern etwas untersagen, z. B.
> User-Agent: Googlebot-Image Disallow: /text
User-Agent: Googlebot Disallow: /bilder
> Seiten, die per robots.txt gesperrt sind, können trotzdem im Index landen
> Tag im <head>-Bereich
<meta name=“robots“ content=“Anweisungen“>
> Anweisungen:
> index, noindex = Darf indexiert werden oder nicht
> follow, nofollow = Crawler darf von hier aus Links folgen oder nicht
> Und noch viel mehr:
https://developers.google.com/search/reference/robots_meta_t ag?hl=de
> Typisch = „index, follow“ = Standard (Tag wird dafür nicht benötigt)
> „noindex, follow“ = diese Seite nicht in den Index aufnehmen, aber den Links auf dieser Seite folgen
> „noindex, nofollow“ = nicht in den Index aufnehmen, nicht den Links folgen
> Was soll das mit der nofollow-Anweisung?
> Beispiel: intranet.website.de soll komplett von der Indexierung ausgeschlossen werden
> Dann würde man „noindex, nofollow“ in alle Seiten einbauen
> Die Startseite soll nicht indexiert werden
> Folge den Links in die Tiefe nicht, da diese ohnehin auch nicht in den Index sollen
> „noindex, follow“ wird von Google langfristig als
„noindex, nofollow“ interpretiert
> Siehe: „If we see the noindex there for longer than we think this page really doesn’t want to be used in search so we will remove it completely. And then we won’t follow the links anyway.“
(https://www.youtube.com/watch?time_continue=3291&v=9GNg8R-X8LQ)
> Die Robots-Anweisungen können sich auch im HTTP-Header befinden, z. B.
> HTTP/1.1 200 OK
X-Robots-Tag: noindex
…
> Es könnte also Konflikte geben:
> Im HTML-Code steht “index”, im HTTP-Header “noindex”
> Am besten: nicht im HTTP-Header verwenden
> Beide Methoden schließen sich aus
> Eine per robots.txt gesperrte Seite kann nicht heruntergeladen werden =
das Robots-Meta-Tag wird nicht gesehen
> Die Seite darf auf keinen Fall im Index zu finden sein?
= Robots-Meta-Tag „noindex“
> Die Seite will „entscheiden“, ob sie im Index auftaucht?
= Robots-Meta-Tag „noindex“
> Es gibt kein eindeutiges URL-Merkmal?
= Robots-Meta-Tag „noindex“
> Sonst: robots.txt
> Google crawlt Seiten mit „noindex“ nach wie vor (Hausnummer: ein Jahr lang)
> Kann also viel Crawl-Budget auffressen!
> Über einen Crawl suchen:
Seiten, die nicht suchrelevant sind
> Login-Seiten
> Vergleichsseiten
> Evtl. auch Impressum/AGB/…
> Google lädt Seiten komplett runter:
> HTML + CSS, Fonts, Bilder, JavaScript-Dateien …
> Google-Richtlinien: „Damit Google die Inhalte Ihrer Website vollständig interpretieren kann, lassen Sie zu, dass alle Assets Ihrer Website gecrawlt werden, die das Rendern der Seite
wesentlich beeinflussen können. Dazu zählen z. B. CSS- und JavaScript-Dateien, die die Interpretation der Seiten
beeinflussen.“
> Kann in der Praxis ein Problem darstellen:
<h1>
> Inhalte werden per JavaScript nachgeladen oder generiert
> Es gibt also zwei HTML-Codes:
> Vor dem Rendern („ungerendert“)
> Nach dem Rendern („gerendert“)
> Wichtig:
> Einige Tools (SEO-Crawler …) können nicht rendern
> Manchmal muss es auch erst aktiviert werden
> Google Search Console > URL-Prüfung
> …gibt es manchmal oft Fehler dabei
> Also:
> Wiederholen, bis der Fehler nicht mehr auftritt
> Nicht mehrere Anfrage parallel starten
> … wenn man schon die Anfrage gestellt hat:
HTTP-Header prüfen
> An dieser Stelle: Die einzig sichere Methode, die Abfrage aus Google-Sicht zu sehen!
> Beispiel: IP-Redirects
> Ein Schreckgespenst
> DC = unterschiedliche URLs, gleicher Content
> Canonical Tag =
<link rel="canonical" href=„Vollständige, korrekte URL einer Seite" />
> Zwei URLs, dieselbe Seite:
> http://www.woodsteel.de/gartenzubehoer/garten-deko:::5_41.html
> http://www.woodsteel.de/Gartenzubehoer/Garten-Deko:::5_41.html
> Lösung (in beiden Seiten):
> <link rel="canonical"
href="http://www.woodsteel.de/Gartenzubehoer/Garten- Deko:::5_41.html " />
> Alle Seiten mit identischem Canonical Tag werden zusammengezogen
> Signale der einzelnen Dubletten werden addiert
> Es erscheint nur die eine URL („Vertreter“) in den Suchergebnissen
> Wichtig: Canonical-Tag ist keine Direktive:
> Google muss sich daran nicht unbedingt halten (tut es in der Regel aber doch)
> Das Canonical Tag verhindert keinen Duplicate Content
> Die Dubletten werden immer noch gecrawlt
> Deswegen:
> Nach Ursachen suchen und diese abstellen
> Canonical-Tag und Noindex sind keine Freunde
> Wenn eine Seite auf „Noindex“ steht:
> Kein Canonical-Tag ausliefern
> Auflistung aller relevanten URLs einer Website
> Wofür brauche ich eine XML-Sitemap?
> Bei sehr großen Websites: Crawling verbessern
> Indexierungsdaten
> Nur URLs auflisten:
> Keine doppelten URLs
> URL = Canonical Tag
> URL nicht für Suchmaschinen gesperrt
> HTTP Code = 200
> XML-Sitemaps, die zu viele Fehler produzieren, werden ignoriert!
> Google Search Console
> Nicht alles in eine große XML-Sitemap
> Besser:
> Pro Seitentyp (Produkte, Rubriken, Artikel)
> Pro Land/Sprache
> Screaming Frog SEO Spider, Mode = List
> „Respect Canonical Tag“ aus
> „Respect noindex“ aus
> „Respect robots.txt“ ein
> „Show internal URLs Blocked by robots.txt“ ein
> Upload: Download Sitemap
> Z. B. mit dem Screaming Frog SEO Spider:
> Google Search Console > Index > Sitemaps > Neue Sitemap hinzufügen
> Analog: Bing Webmaster Tools
> robots.txt > Sitemap: URL
> Pfad?parameter1=wert1¶meter2=wert2
> Zwei Fragen:
> Welche URL-Parameter gibt es auf meiner Website?
> Welche Parameter sind relevant, welche irrelevant?
• Relevant = die Seite „braucht“ den Parameter
• Irrelevant = der Parameter kann auch entfallen
> Beispiel 1: Session-ID
> https://www.fiktivewebsite.de/schraenke/?sessionid=15AB8
> https://www.fiktivewebsite.de/schraenke/
> Beispiel 2: Shopware
> https://www.religioese-geschenke.de/cd-die-bibel-und- einheitsuebersetzung.html
> https://www.religioese-geschenke.de/cd-die-bibel-und- einheitsuebersetzung.html?c=1229
> Beispiel 3: Website
> https://www.aerzteblatt.de/nachrichten?id=23147 liefert eine konkrete Nachricht
> https://www.aerzteblatt.de/nachrichten liefert die Nachricht nicht
> Relevante URL-Parameter:
> Canonical Tag zeigt auf URL mit diesem URL-Parameter
> Irrelevante URL-Parameter:
> Canonical Tag zeigt auf URL ohne diesen URL-Parameter
> Wenn es irrelevante URL-Parameter gibt:
(alte) Google Search Console > URL-Parameter
> Google entfernt die Parameter vor dem Crawling (Direktive!)
> Am besten über einen Crawl
> Z. B. Screaming Frog SEO Spider
> (Alte) GSC schlägt Parameter vor (nach dem Crawling)
> Immer die üblichen Verdächtigen eintragen:
> utm_source (Analytics)
> utm_campaign (Analytics)
> utm_medium (Analytics)
> utm_content (Analytics)
> gclid (Google Ads)
> Jede per HTTP/HTTPS angeforderte Information erhält einen Status-Code
> 200 = OK
> 301 = Permanent Redirect (umgezogen, für immer)
> 302 = Temporary Redirect (umgezogen, nur für kurz)
> 404 = Not found (Information ist nicht da)
> 410 = Gone (nicht da + kommt auch nie wieder)
> 5xx = Server geht‘s gerade nicht so gut
> Eine Seite ändert ihre URL:
> ALT www.website.de/lange-hosen
> NEU www.website.de/produkte/hosen-lang
> ALT = 404 = Index-Eintrag wird inkl. aller Signale gelöscht (=schlecht)
> ALT = 301 auf NEU = Index-Eintrag wird aktualisiert, Signale bleiben erhalten
> Nie 302, immer 301
> Hat eine Seite einen Nachfolger?
> 301 auf neue Seite
> Aber: Die Rankings werden nur transferiert, wenn alte und neue Seite eine hohe Überdeckung haben
> Alles auf die Startseite umleiten = schlechte Idee
> Wird dann oft als „Soft 404“ gewertet
> Hauptsächlich zwei Fälle:
> Fehlerseite („nicht gefunden“) liefert einen 200 aus (nicht 404)
> Umleitung alte auf neue Seite passt inhaltlich nicht
• Dann: Verlust der Rankings
> Aber manchmal auch:
> Produktdetailseite steht auf „nicht lieferbar“
> Bei kleinen URL-Mengen (<100): httpstatus.io
> Spezial-Tool: https://headmasterseo.com
> Kostenlos bis 500 URLs
> Kostenpflichtig ab 45€ (einmalig)
> Bei großen URL-Mengen (>100): Frog
> Anleitung: https://blog.bloofusion.de/seo-redirect-check/
> Warum?
> Manche Fehler (z. B. 301 auf Noindex-Seite) können nicht alle Tools erkennen
> Je früher sich eine Seite im Index befindet, desto besser sind die Chancen auf Rankings
> Also: Seiten immer möglichst früh anlegen!
> Am besten einen Crawl durchführen
> Irrelevante Seiten sperren:
> Login-Seiten
> Kontaktformulare …
> Haben alle Seiten ein Canonical-Tag?
> Kann man auch am besten mit einem Crawler testen
> Liegen XML-Sitemap(s) vor?
> Sind diese in der Google Search Console eingetragen?
> Dann: Report „Abdeckung“ prüfen
> Für alle relevanten Seitentypen prüfen:
> Können die Inhalte korrekt gerendert werden?
> Prüfen: Welche Parameter gibt es?
> Am besten mit einem Crawl
> Alte Google Search Console > URL-Parameter
> Was ist Markup?
> Warum sollte ich das nutzen?
> Wie kann ich damit starten?
> Hier kann Google nichts erkennen:
> <p>
30. Oktober 2015<br>
<a href="http://www.bloofusion.de/infos/webinar/">Webinar:
Beim SEO-Relaunch alles richtig machen</a>
</p>
> So ist es besser:
> <p itemscope="" itemtype="https://schema.org/Event">
<span class="date">30. Oktober 2015</span><br>
<a itemprop="url" href="/infos/webinar/"><span
itemprop="name">Webinar: Beim SEO-Relaunch alles richtig machen</span></a>
<meta itemprop="startDate" content="2015-10-30">
</p>
> Semantische Auszeichnung
> „Unsichtbare“ Markierungen im HTML-Code
> Keine Auswirkungen auf die Darstellung im Browser
> Sehr viele unterschiedliche Standards, z. B. https://schema.org/Event
> Unterschiedliche „Schreibweisen“:
> Microdata
> RDFa
> JSON-LD
> Microdata, RDFa:
> Unterschiedliche Methoden, Attribute zu markieren
> Typisch: Bestimmte sichtbare Elemente werden markiert
> JSON-LD:
> Losgelöst von sichtbaren Inhalten
> JSON-LD wird grundsätzlich von Google präferiert
> Bing unterstützt JSON-LD
> Praxis: unempfindlicher gegen den „Webmaster from Hell“
> Zusätzliche Informationen im Suchergebnis
= mehr Aufmerksamkeit = potenziell höhere CTR
> Derzeit: Google Jobs und Google Event-Suche
> Eher nicht…
> John Mueller (Google) sagt:
> „If we can recognize someone is looking for a car, we can say, oh well, we have these pages that are marked up with structured data for a car, so probably they are pretty useful in that regard. We don’t have to guess if this page is about a car. So I think, in the long run, it definitely makes sense to use structured data where you see that as being reasonable on the website.“
https://www.youtube.com/watch?v=QWL864VlW7I
> Kostenlos, ohne Login:
https://developers.google.com/structured-data/testing-tool/
> Warnung: wird wohl in den nächsten Monaten abgeschaltet!
> Wichtig für:
> Konkrete Fehlersuche
> Testen von Code (auch inline)
> Der „Test für Rich-Suchergebnisse“:
> https://search.google.com/test/rich-results
> Ersetzt das Tool #1
> Was ist ein Rich-Suchergebnis?
> Ein Suchergebnis, das mehr als ein normales Suchergebnis bietet
> Beispiel: Sternchen in den Suchergebnissen
> Für das große Bild: Google Search Console
> Fehler immer live überprüfen
(das Structured Data Testing Tool nutzen)
> Dann in Search Console validieren lassen
> https://developers.google.com/search/docs/data- types/breadcrumb
> Einbauen in: jede Seite
> https://developers.google.com/search/docs/data-types/sitelinks- searchbox
> Einbauen in: Startseite
> https://developers.google.com/search/docs/data-types/logo
> Einbauen in: Startseite
> Muss aber auch nicht …
> Produkte:
> https://schema.org/Product
> https://schema.org/Offer
> Siehe: https://developers.google.com/search/docs/data- types/product
> Zusätzlich bei Bewertungen:
> https://schema.org/Review
> https://schema.org/AggregateRating
> Klare Antwort von John Mueller:
„So in general the structured data markup should be specific to the one main item on the page. So if you have a list of different items then structured data markup wouldn’t apply to them […]“
http://www.thesempost.com/add-structured-data-markup-individual-products-not- categories-lists/
> https://developers.google.com/search/docs/data-types/event
> https://schema.org/VideoObject
> https://schema.org/NewsArticle
> https://schema.org/BlogPosting
> https://schema.org/LocalBusiness
> https://developers.google.com/search/docs/data- types/speakable
> „identifies sections within an article or webpage that are best suited for audio playback“
> „we recommend around 20-30 seconds of content per section of speakable structured data, or roughly two to three sentences “
> FAQ: https://developers.google.com/search/docs/data- types/faqpage
> Q+A: https://developers.google.com/search/docs/data- types/qapage
> How-To: https://developers.google.com/search/docs/data- types/how-to
> Zugangsvoraussetzung für Google Jobs:
> https://developers.google.com/search/docs/data-types/job-posting
> Bei uns im Bloofusion Blog:
> https://blog.bloofusion.de/markup-seo-checkliste/
> Bei Google:
> https://developers.google.com/search/docs/data-types/article
> https://developers.google.com/search/docs/guides/sd-policies
> “Don't mark up content that is not visible to readers of the page.”
> “The more recommended properties that you provide, the higher quality the result is to users.”
> “Put the structured data on the page that it describes.”
> Es gibt auch Penalties für falsches Markup!
> Seit September 2019 wird das eh nicht mehr erlaubt:
> “We call reviews self-serving when a review about entity A is placed on the website of entity A - either directly in their markup or via an embedded 3rd party widget.“
https://webmasters.googleblog.com/2019/09/making-review-rich-results-more-helpful.html
> Alle Seitentypen exemplarisch durchprüfen:
> Welche Markups sind schon drin?
> Gibt es Fehler/Warnungen?
> Gibt es noch Markups, die ich nutzen kann?
> Was muss man machen, wenn man mehr als eine Sprache oder
mehr als ein Land abdecken möchte?
> Es gibt ccTLDs und gTLDs
> cc = Country-Code = auf Land ausgerichtet .de, .at, .ch, .fr …
> g = generisch = nicht auf Land ausgerichtet .com, .info, .net …
> Randbemerkung: Nicht alle ccTLDs werden auch von Google als solche erkannt
> Beispiel: .tv (Tuvalu) ist eine ccTLD, wird aber als gTLD behandelt
> Vollständige Liste:
https://support.google.com/webmasters/answer/182192?hl=de
> Wie soll man‘s jetzt machen?
> Alles auf eine gTLD (also website.com/de/, at.website.com, …)?
> Jeweils lokale ccTLDs (website.de, website.at, website.ch, …)?
> Oder gemischt?
> Es gibt keine einfache Antwort
> Alles auf eine gTLD
> Alle Signale sammeln sich auf einer Domain
> Gut für „schwache“ Länder/Sprachen
> Viele verschiedene ccTLDs
> Jeweils optimale Länderausrichtung
> Websites profitieren faktisch nicht voneinander
> Vorgehen:
> ccTLDs für Top-Märkte
> Eine gTLD für alle anderen Märkte
> Also z. B.:
> www.meinewebsite.de und www.meinewebsite.fr
> www.meinewebsite.com/it/, www.meinewebsite.com/fr/ …
> Wenn man sich für eine gTLD entscheidet:
> www.website.com/ordner/ oder subdomain.website.com?
> Ein alter Glaubenskrieg der SEOs …
> Meine Meinung: Ordner ist etwas besser als Subdomain
> Was soll man nehmen?
> www.website.com/deutschland/
> www.website.com/deutsch/
> www.website.com/deutschland-deutsch/
> Keine klare Empfehlung …
> Einige Websites bieten für verschiedene Länder Content an:
> www.website.com/fi-en/
> www.website.com/no-en/
> …
> Das ist in jedem Fall sehr viel Duplicate Content
= schlechte Idee
> Für viele Unternehmen am besten:
> gTLD mit Unterordnern, z. B.
www.meinewebsite.com/fr/
> Unterordner für Sprachen, nicht für Länder
> Evtl. ccTLD für einige wenige Top Märkte
> ccTLDs umleiten auf Ordner, z. B.
www.meinewebsite.fr -> www.meinewebsite.com/fr/
> Eine ccTLD ist optimal auf ein Land ausgerichtet
> Aus einer gTLD kann man eine ccTLD „machen“
> Gilt auch für Ordner und Subdomains
> Also z. B.
> https://www.ikea.com/at/de/ = Österreich
> https://at.wetter.com/ = Österreich
> Properties können auf ein Land ausgerichtet werden
> Das bringt einen Boost für das Land
> Für alle anderen Länder kein Nachteil
> Also: Alle Ordner/Subdomains separat in der alten Google Search Console anmelden
> Tag in einer Seite, das auf Nachbarn verweist
https://www.markilux.com/de-de/wintergartenmarkisen
<link href="https://www.markilux.com/de-de/wintergartenmarkisen" rel="alternate" hreflang="de-de" />
<link href="https://www.markilux.com/en-gb/conservatory-awnings" rel="alternate" hreflang="en-gb" />
https://www.markilux.com/en-gb/conservatory-awnings
<link href="https://www.markilux.com/de-de/wintergartenmarkisen" rel="alternate" hreflang="de-de" />
<link href="https://www.markilux.com/en-gb/conservatory-awnings" rel="alternate" hreflang="en-gb" />
> Das Tag legt für eine konkrete Seite die „Nachbarn“ fest (nicht für die gesamte Website!)
> Primäres Ziel:
> Richtiges Ausliefern
> Nicht:
> Bessere Rankings
> Ein Beispiel…
> hreflang kann genutzt werden für:
> Sprache
> Sprache + Land
> Nicht für:
> Land
> Wird primär gebraucht für:
gleiche Sprache, anderes Land
> Sprache Deutsch: Deutschland, Österreich, Schweiz
> Belgien (zweisprachig), Überschneidung Frankreich/Niederlande
> URLs im hreflang-Tag ≠ Canonical-Tag
> URLs im hreflang-Tag für Suchmaschinen gesperrt
> HTTP-Code von URLS im hreflang-Tag ≠ 200
> Code nicht auf allen Nachbarn identisch
> Vor allem: Fehlende Selbstreferenz
> Generatoren:
> https://www.aleydasolis.com/english/international-seo- tools/hreflang-tags-generator/
> https://www.sistrix.de/hreflang-guide/hreflang-generator/
> Fürs Debugging:
> Laufend:
(Alte) Google Search Console > Suchanfragen > Internationale Ausrichtung
> Einmalig - für einzelne Seiten:
hreflang.org
> Einmalig – für die gesamte Website:
Screaming Frog SEO Spider
> Konfiguration anpassen
> Welche Seiten haben fehlende/fehlerhafte hreflang-Tags?
> Noch eine Besonderheit:
<link rel="alternate" hreflang="x-default" href="URL" />
> Wofür braucht man die?
> „this page doesn’t target any specific language or locale and is the default page when no other page is better suited“
> <html lang=“xx"> (xx = de, fr, …) oder
<meta http-equiv="language" content=“xx">
> Google braucht das Tag nicht
> Die Sprache wird anhand der Inhalte erkannt
> Dennoch: Tag nutzen (für evtl. andere Suchmaschinen)
> Auch Google ruft eine Seite auf (über den Googlebot)
> Weiterleitungen auf IP-Basis („IP Redirect“) sind daher schlecht
> Wenn, dann muss es eine 302-Umleitung sein!
> Lösungen:
> Erkennen der Google-IP, besser: User-Agent (=Googlebot wird nicht weitergeleitet)
> Weiterleitung per JavaScript; Script für Google gesperrt
> Auf automatische Weiterleitung verzichten
> Unbedingt prüfen mit „URL-Prüfung“
> Die internationalen Startseiten (also /de/, /en/, …) sollten auch intern gut verlinkt werden
> Am besten: Jede Seite verlinkt auf alle internationalen Startseiten (mit <a href=““>!)
> Häufig: Links in Menü oder Footer
/
/at/
/de/ /ch/
/de/xyz /at/xyz /ch/xyz
33% 33% 33%
100%
/
/at/
/de/
/ch/
/de/xyz
/at/xyz /ch/xyz
100%
~10% ~10%
100%
301
/
/at/ /ch/
/xyz
/at/xyz /ch/xyz
~10% ~10%
100%
> Server-Standort: nicht relevant
> Domain-Strategie überprüfen:
> Wie gut sind meine Domains verlinkt?
> Checkliste durcharbeiten – vor allem:
> Hreflang-Tags
> Interne Verlinkung
> x
> Wahrscheinlich kommen in der Zukunft noch weitere Signale hinzu
> Es ist nur ein Ranking-Faktor
> Können nachteilig sein
> Vermeiden: „intrusive interstitials“
> Es zählen nur Interstitials, die direkt beim Laden sichtbar sind
