Technisches SEO-Audit: Die Fixes, die Rankings zuerst beeinflussen

Ein Unternehmer führt ein technisches SEO Audit Tool auf der eigenen Website aus.

Der Bericht liefert vierzig markierte Probleme. JavaScript, das das Rendering blockiert. Ein fehlendes hreflang-Tag. Mehrere Bilder ohne Alt-Text. Ein paar 404-Fehler.

Im Bericht steht nirgends, welche davon tatsächlich Rankings kosten und welche nur Rauschen sind, das ein Tool erzeugt, damit es gründlich aussieht.

Also wird der Bericht überflogen, als Lesezeichen gespeichert und größtenteils ignoriert, weil es keinen offensichtlichen Einstiegspunkt gibt.

Ein technisches SEO Audit muss nicht vierzig Dinge abdecken, um nützlich zu sein. Es muss vier abdecken: ob Google Ihre Seiten crawlen kann, wie schnell sie laden, wie sie auf dem Smartphone dargestellt werden und ob Ihre strukturierten Daten gültig sind. Hier erfahren Sie, wie Sie diese vier Bereiche in der Reihenfolge durcharbeiten, die sich tatsächlich auf die Rankings auswirkt, statt eine lange Liste von oben nach unten abzuarbeiten.

Was ein technisches SEO Audit tatsächlich prüft

Ein technisches SEO Audit betrachtet die Technik einer Website, nicht die Texte darauf. Es prüft, ob eine Seite erreichbar, lesbar und schnell darstellbar ist, auf jedem Gerät, und nicht, ob der Inhalt dieser Seite gut ist.

Dieser Unterschied ist wichtig, denn eine technisch perfekte Seite mit dünnem, generischem Inhalt rankt trotzdem nicht gut, und eine wunderbar geschriebene Seite, die Google nicht crawlen kann, rankt gar nicht. Die beiden Arten von Audit lösen unterschiedliche Probleme.

Die vier Bereiche, um die es in diesem Artikel geht

Die meisten Punkte im Bericht eines technischen Audits fallen in eine von vier Kategorien: Crawlbarkeit, Ladezeit, mobile Darstellung und strukturierte Daten. Die Dokumentation von Google zu den Search Essentials formuliert die Grundanforderung einfach: Eine Seite muss technisch zugänglich und darstellbar sein, bevor irgendetwas anderes an ihr bewertet wird.

Dieser Artikel arbeitet diese vier Bereiche in der Reihenfolge durch, die meist am wichtigsten ist, und beginnt mit der Frage, ob Google Ihre Seiten überhaupt erreichen kann, denn nichts anderes in einem technischen Audit hat Bedeutung, bevor das geklärt ist.

Wie sich ein technisches Audit von einem Content-Audit unterscheidet

Ein Content-Audit fragt, ob eine Seite eine echte Frage ausreichend ausführlich beantwortet, ob sie aktuell ist und ob sie die richtige Seite für eine bestimmte Suchanfrage ist. Ein technisches Audit fragt nichts davon. Es fragt, ob die Seite lädt, ob sie blockiert ist und ob ein Smartphone sie richtig anzeigen kann.

Beide Audits sind wichtig, und eine Website braucht meist irgendwann beide. Dieser Artikel bleibt bewusst bei der technischen Seite, weil genau dort die meisten Kleinunternehmer entweder alles auslassen oder versuchen, alles auf einmal aus einer verwirrenden Problemliste zu beheben.

Diagramm mit den vier Bereichen des technischen Audits in Prioritätsreihenfolge: Crawlbarkeit, Ladezeit, mobile Darstellung und strukturierte Daten.

Crawling-Fehler: Was verhindert, dass Google Ihre Seiten liest

Bevor die Ladezeit oder das mobile Layout einer Seite überhaupt eine Rolle spielt, muss Google sie finden, abrufen und in den Index aufnehmen können. Ein Crawling-Fehler unterbricht diese Kette, und nichts weiter unten auf der Liste eines technischen Audits kann das ausgleichen.

Den Seitenindexierungsbericht in der Search Console lesen

Der Seitenindexierungsbericht der Search Console ist der direkteste Weg zu sehen, wie Google Ihre Seiten tatsächlich behandelt, statt von außen zu raten. Er gruppiert Ihre URLs nach Status: indexiert oder nicht indexiert, jeweils mit einem konkreten Grund.

Gründe wie Durch robots.txt blockiert, Serverfehler (5xx), Weiterleitungsfehler und Soft 404 verweisen jeweils auf eine andere Ursache, und jede braucht eine etwas andere Lösung. Diesen Bericht einmal im Monat zu lesen dauert wenige Minuten und fängt Probleme ab, lange bevor sie als Rückgang des Traffics sichtbar werden.

Häufige Crawling-Fehler und ihre Ursachen

Eine blockierte Seite entsteht meist durch eine Zeile in robots.txt, die für einen anderen Bereich der Website gedacht war, aber versehentlich mehr erfasst hat als beabsichtigt. Ein Serverfehler bedeutet meist, dass die Seite beim Abruf durch Google eine Antwort im 500er-Bereich zurückgab, oft wegen eines Hosting- oder Plugin-Problems und nicht wegen des Inhalts der Seite.

Ein Weiterleitungsfehler bedeutet, dass Google einer Weiterleitung gefolgt ist, die an einem unerwarteten Ziel endete, oft in einer Schleife oder in einer Sackgasse. Eine Soft 404 ist eine Seite, die einen normalen Status 200 zurückgibt, aber so wenig Inhalt hat, dass Google sie als praktisch leer behandelt. Das lohnt sich zu prüfen, denn es ist manchmal ein Zeichen dafür, dass auf der Seite tatsächlich mehr Text fehlt.

Warum eine blockierte wichtige Seite jeden anderen Fix auf dieser Liste schlägt

Eine Website kann eine hervorragende Ladezeit, ein makelloses mobiles Layout und gültiges Schema auf jeder Seite haben, und nichts davon zählt, wenn die wichtigste Leistungsseite versehentlich in robots.txt blockiert ist. Eine blockierte Seite wird nicht schlecht bewertet. Sie wird gar nicht bewertet.

Deshalb kommen Crawling-Fehler in einem technischen Audit immer zuerst, noch vor allem zu Geschwindigkeit oder Darstellung. Unser Leitfaden, wie Sie Ihre Website bei Google indexieren lassen, behandelt diese Prüfung genauer, einschließlich dessen, was zu tun ist, wenn eine Seite, die indexiert sein sollte, es nicht ist.

robots.txt, Sitemaps und Weiterleitungsketten reparieren

Sobald Sie wissen, was Ihnen der Seitenindexierungsbericht sagt, liegen die eigentlichen Lösungen meist an drei Stellen: in der robots.txt-Datei, in der Sitemap und in allen Weiterleitungen, die auf der Website miteinander verkettet sind.

robots.txt auf versehentliche Blockaden prüfen

Öffnen Sie die robots.txt-Datei Ihrer Website direkt, meist im Stammverzeichnis der Domain, und lesen Sie jede Regel durch. Eine einzelne Zeile, die einen Admin-Ordner oder eine Staging-Subdomain blockieren soll, kann ein ganzes Verzeichnis echter Seiten erfassen, wenn sie zu breit formuliert ist.

Der kostenlose Robots.txt Checker von RepGet zeigt ein klares Urteil darüber, was für Suchmaschinen und KI-Bots gemeinsam blockiert ist, und das geht schneller, als jede Zeile der Syntax einzeln zu lesen. Unser Leitfaden zum robots.txt-Generator erklärt, wie Sie eine sichere Datei von Grund auf erstellen, falls die bestehende eher neu geschrieben als nur gekürzt werden muss.

Die Sitemap mit den echten Seiten synchron halten

Eine XML-Sitemap ist nur nützlich, wenn sie die Seiten auflistet, die tatsächlich existieren und einen normalen Status 200 zurückgeben. Eine Sitemap, die noch Seiten listet, die vor Monaten gelöscht wurden, oder die seit der letzten Erstellung hinzugekommene Seiten nicht enthält, sendet Google widersprüchliche Signale darüber, was auf der Website aktuell ist.

Der kostenlose Sitemap Checker & Finder von RepGet findet und validiert die Sitemap einer Website und markiert URLs, die nicht so auflösen, wie sie sollten. Die meisten Website-Plattformen erstellen eine Sitemap automatisch neu, aber es lohnt sich zu bestätigen, dass das tatsächlich passiert, statt es anzunehmen.

Weiterleitungsketten finden und beheben

Eine Weiterleitungskette entsteht, wenn eine URL auf eine zweite weiterleitet, die auf eine dritte weiterleitet, statt direkt auf die finale Seite zu zeigen. Jeder zusätzliche Sprung kostet Ladezeit und gibt Google eine weitere Stelle, an der etwas schiefgehen kann.

Solche Ketten bauen sich über Jahre unbemerkt auf, meist nachdem eine Website mehrfach neu gestaltet wurde, ohne dass jemand die alten Weiterleitungen aufräumt. Um sie zu finden, prüfen Sie Ihre meistverlinkten Seiten und verfolgen Sie, wo jede Weiterleitung tatsächlich landet. Anschließend zeigen Sie alles mit mehr als einem Sprung direkt auf sein finales Ziel.

Ladezeit als Ranking-Faktor: Was bei Core Web Vitals tatsächlich zählt

Die Ladezeit bekommt in technischen Audits viel Aufmerksamkeit, zum Teil weil sie messbar ist und zum Teil weil langsame Websites tatsächlich häufig sind. Wichtig ist zu klären, welche Ladezeit-Metriken Google tatsächlich als Ranking-Signal dokumentiert und welche nur gute Praxis sind.

Die drei Core Web Vitals in einfacher Sprache

Die Core Web Vitals, dokumentiert auf web.dev, messen drei Dinge am Ladeerlebnis einer Seite. Largest Contentful Paint (LCP) misst, wie lange das größte sichtbare Element braucht, um zu erscheinen, meist ein Bild oder ein Textblock. Interaction to Next Paint (INP) misst, wie schnell die Seite reagiert, wenn jemand auf etwas klickt oder tippt. Cumulative Layout Shift (CLS) misst, ob sich Elemente während des Ladens unerwartet verschieben.

Was ein dokumentiertes Ranking-Signal ist und was allgemeiner Geschwindigkeitsrat

Google hat Core Web Vitals als Teil seiner Signale zur Seitenerfahrung dokumentiert. Das unterscheidet sich von vielen Geschwindigkeitstipps, die online kursieren, etwa jedes Bild auf die kleinstmögliche Dateigröße zu komprimieren oder einem perfekten Wert von 100 in einem Speed-Testtool hinterherzujagen. Das geht weit über das hinaus, was Google tatsächlich misst.

Eine Seite, die die Schwellenwerte der Core Web Vitals erfüllt, hat die dokumentierte Hürde genommen. Noch eine halbe Sekunde herauszuholen lohnt sich für Besucher manchmal, aber es ist kein dokumentierter Ranking-Vorteil gegenüber einer Seite, die bereits besteht.

Die Werte Ihrer eigenen Website prüfen

Der Core-Web-Vitals-Bericht der Search Console zeigt, wie Ihre eigenen Seiten für echte Besucher tatsächlich abschneiden, gruppiert danach, ob sie jede Metrik bestehen, verbessert werden müssen oder durchfallen. Das ist ein besserer Befund für Ihre Website als ein einzelner Testlauf von einem Standort auf einem Gerät, weil er die realen Bedingungen Ihrer tatsächlichen Besucher widerspiegelt.

Für eine schnelle Stichprobe einer einzelnen Seite kann ein spezialisiertes Tool zum Testen der Ladezeit zeigen, welche konkreten Elemente bremsen, etwa ein überdimensioniertes Hero-Bild oder ein Skript, das vor dem Inhalt lädt, den es betrifft. In beiden Fällen ist das Ziel nicht ein perfekter Wert. Es geht darum, dass jede wichtige Seite die dokumentierten Schwellenwerte erreicht.

Mobile Rendering: Was Google auf dem Smartphone sieht und was Sie sehen

Eine Seite, die auf einem Desktop-Monitor gut aussieht, kann sich auf einem Smartphone ganz anders verhalten, und für die meisten Websites heute ist die Smartphone-Version diejenige, die zählt.

Warum Mobile-First-Indexierung entscheidet, was zählt

Google hat dokumentiert, dass es für die Indexierung und das Ranking in erster Linie die mobile Version des Seiteninhalts verwendet, eine Praxis, die Google Mobile-First-Indexierung nennt. Das heißt, die Version Ihrer Seite, die Google am genauesten bewertet, ist nicht unbedingt die, die Sie sehen, wenn Sie Ihre Website auf dem Laptop prüfen.

Wenn ein Desktop-Layout auf dem Smartphone einen Textblock ausblendet oder zusätzliche Inhalte erst nach einem Klick lädt, den ein Besucher am Handy nie macht, fehlt in Googles Hauptansicht der Seite alles, was es nicht in die mobile Version geschafft hat. Ein technisches SEO Audit, das eine Website nur am Desktop prüft, prüft die falsche Version der Seite.

Häufige Probleme bei der mobilen Nutzbarkeit auf Websites kleiner Unternehmen

Einige mobile Probleme tauchen auf Websites kleiner Unternehmen immer wieder auf. Text, der am Desktop gut lesbar ist, schrumpft auf dem Smartphone auf eine unangenehme Größe, sodass Besucher zoomen müssen. Schaltflächen und Links liegen so eng beieinander, dass ein Tippen auf den einen versehentlich einen anderen auslöst.

Ein Vollbild-Popup, das die Seite verdeckt, bevor ein Besucher etwas gelesen hat, ist ein weiteres häufiges Problem, besonders bei Websites aus einer Vorlage, die dies standardmäßig aktiviert. Und ein Navigationsmenü, das für die Maus gebaut wurde, öffnet sich auf einem Touchscreen manchmal gar nicht, was einen Besucher unbemerkt vom Rest der Website abschneidet.

So testen Sie die mobile Version Ihrer Website

Der direkteste Test ist, Ihre Website auf einem echten Smartphone zu öffnen, über mobile Daten statt WLAN, und sie so zu nutzen, wie ein echter Besucher es täte: das Menü antippen, den Haupttext lesen, versuchen, Ihre Kontaktseite zu erreichen. Achten Sie auf alles, was eng, versteckt oder nicht reagierend wirkt.

Unser Leitfaden zu Website als Googlebot ansehen zeigt eine technischere Methode, um zu prüfen, was der Crawler von Google tatsächlich sieht, wenn er eine Seite rendert. Das geht einen Schritt weiter, als nur das visuelle Layout selbst zu prüfen.

Strukturierte Daten und Schema: Was sie bringen (und was nicht)

Schema-Markup gehört zu den am häufigsten missverstandenen Punkten in einem technischen SEO Audit, teilweise weil es mächtiger klingt, als es tatsächlich ist.

Was Schema für eine Seite wirklich bewirkt

Schema ist eine standardisierte Methode, Informationen auf einer Seite so zu kennzeichnen, dass ein Computerprogramm sie zuverlässig lesen kann, anstatt sie aus einem Fließtext zu erraten. Googles eigene Dokumentation zu strukturierten Daten erklärt, dass Schema eine Seite für bestimmte erweiterte Funktionen in den Suchergebnissen qualifizieren kann, etwa Sternebewertungen oder ein aufklappbares FAQ, sie verbessert aber nicht direkt die Ranking-Position einer Seite.

Dieser Unterschied ist wichtig. Eine Seite mit perfektem Schema und dünnen, generischen Inhalten rankt nicht besser als eine Seite ohne Schema mit wirklich nützlichen Texten. Schema ist eine Darstellungsebene über Inhalten, die auch für sich genommen gut sein müssen.

Schema-Typen, die sich für ein kleines Unternehmen lohnen

Die meisten kleinen Unternehmen brauchen kein umfangreiches Schema-Setup. Einige wenige Typen decken die Situationen ab, die tatsächlich vorkommen, und schema dokumentiert das vollständige Vokabular, falls einmal ein spezifischerer Typ nötig wird.

Markup prüfen, bevor es live geht

Schema, das falsch geschrieben ist, auch mit einem kleinen Syntaxfehler, scheitert oft stillschweigend, statt auf der Seite selbst einen offensichtlichen Fehler anzuzeigen. Ein Validator prüft, ob das Markup so aufgebaut ist, wie es das Schema-Vokabular erwartet, bevor es live geht. So fallen Fehler auf, die sonst monatelang unbemerkt bleiben würden.

Die Search Console meldet außerdem Fehler bei strukturierten Daten auf Seiten, die sie bereits gecrawlt hat. Das lohnt sich regelmäßig zu prüfen, auch wenn das Markup schon eine Weile live ist, denn ein Update der Website kann es manchmal kaputt machen, ohne dass es jemand bemerkt.

Technische Probleme nach Wirkung und Aufwand sortieren

Nachdem alle vier Bereiche behandelt wurden, lautet die nächste Frage, in welcher Reihenfolge man einen echten Audit-Bericht tatsächlich abarbeiten sollte, besonders wenn er Probleme aus mehreren dieser Kategorien gleichzeitig enthält.

Warum Crawling- und Indexierungsprobleme zuerst kommen

Eine blockierte oder nicht indexierte Seite steht in dieser Liste über allem anderen, weil nichts anderes zählt, bis sie behoben ist. Eine Ladezeitverbesserung auf einer Seite, die Google nicht lesen kann, ist verschwendete Mühe, und ebenso ein Schema-Eintrag auf einer Seite, die nicht einmal im Index steht.

Deshalb ist die Reihenfolge in diesem Artikel nicht willkürlich. Crawling-Fehler kommen zuerst, weil sie jede andere Korrektur sinnlos machen können. Ladezeit und mobile Darstellung kommen als Nächstes, weil sie Seiten betreffen, die Google bereits sehen und ranken kann, nur nicht so gut, wie es möglich wäre. Schema kommt zuletzt, weil es Darstellungswert auf einer Seite ergänzt, die ohnehin schon funktioniert.

Wo Ladezeit, Mobile und Schema danach einzuordnen sind

Sobald die Crawlbarkeit geklärt ist, verdienen Ladezeit- und Mobilprobleme meist den nächsten Platz, da beide als Teil der Bewertung der Seitenerfahrung durch Google dokumentiert sind und beide jeden Besucher betreffen, der auf der Seite landet, nicht nur die, die Google crawlt. Schema folgt danach als lohnende, aber niedriger priorisierte Ergänzung.

Dasselbe Denken in Aufwand und Wirkung, das für jede Audit-Liste gilt, gilt auch hier. Eine blockierte Seite ist wenig Aufwand und hohe Wirkung, deshalb lohnt sie sich immer zuerst, unabhängig davon, was sonst auf der Liste steht. Eine langsame, bildlastige Seite braucht mehr Arbeit, ist aber trotzdem wichtig. Fehlender Alt-Text bei ein paar Bildern ist schnell erledigt, aber geringfügig. Und eine selten besuchte Archivseite, die tief in der Website versteckt ist, lohnt die Zeit meist gar nicht.

2x2-Matrix, die technische SEO-Audit-Probleme nach Aufwand und Wirkung sortiert, mit Beispielen in jedem Feld: eine blockierte wichtige Seite als schneller Gewinn, langsame bildlastige Seiten als größeres Projekt, fehlender Alt-Text als schnell, aber geringfügig, und eine selten besuchte Archivseite, die man vorerst auslässt.

Ein Praxisbeispiel: Das Audit einer kleinen Website

Stellen Sie sich vor, ein kleines Garten- und Landschaftsbauunternehmen lässt zum ersten Mal seit einigen Jahren ein technisches Audit für seine Website durchführen. Dieses Beispiel dient der Veranschaulichung.

Was sich geändert hat und in welcher Reihenfolge

Das Audit deckt vier Probleme auf, die alle vier Bereiche dieses Artikels abdecken: eine Leistungsseite, die versehentlich in der robots.txt blockiert ist, eine Startseite mit großen, unkomprimierten Bildern, ein mobiles Menü, das sich auf einem Touchscreen nicht öffnete, und auf der ganzen Website kein Schema-Markup. Die Abarbeitung in der Reihenfolge, die dieser Artikel empfiehlt, sieht so aus.

Diese Zahlen sind veranschaulichend.

Die blockierte Seite wurde zuerst behoben, da nichts anderes zählte, bis Google sie tatsächlich lesen konnte. Ladezeit und Mobile kamen danach, da beide echte Besucher betrafen und beide Teil dessen sind, wie Google die Seitenerfahrung dokumentiert. Schema kam zuletzt, ergänzt, nachdem alles darunter bereits funktionierte.

Ein wöchentlicher 20-Minuten-Check für die technische Gesundheit Ihrer Website

Ein vollständiges technisches Audit muss nicht jede Woche wiederholt werden. Ein kurzer Check verhindert aber, dass aus kleinen Problemen die Art von Schaden wird, die erst Monate später als Rückgang des Traffics sichtbar wird.

Was Sie jede Woche prüfen sollten

Beginnen Sie mit dem Bericht zur Seitenindexierung in der Search Console und schauen Sie in der Spalte der nicht indexierten Seiten nach allem Neuen. Eine Seite, die letzte Woche in Ordnung war und diese Woche blockiert ist oder Crawling-Fehler liefert, deutet meist auf eine kürzliche Änderung irgendwo auf der Website hin. Solange sie frisch ist, lässt sie sich viel leichter nachvollziehen.

Werfen Sie danach einen Blick auf den Bericht zu den Core Web Vitals. Achten Sie auf Messwerte, die von „bestanden“ auf „verbesserungsbedürftig“ gewechselt haben. Oft reicht ein einziges neues Bild oder Skript ohne Größenanpassung, um eine Seite über den dokumentierten Schwellenwert zu drücken. Wer das früh erkennt, hat eine Korrektur von fünf Minuten statt einer langwierigen Fehlersuche später.

Zum Schluss prüfen Sie auf neue Hinweise zu Problemen bei der mobilen Nutzbarkeit und auf Fehler bei strukturierten Daten, die die Search Console neuerdings meldet. Beide treten häufig nach einem Theme-Update, einer Plugin-Änderung oder einem Redesign auf, auch wenn es nur klein war. In der Woche, in der sie auftauchen, lassen sie sich deutlich schneller beheben als drei Monate später.

Wie ein wiederkehrendes Problem aussieht

Eine einzelne blockierte Seite oder ein einziges langsames Bild ist eine einmalige Korrektur. Ein Muster, etwa wenn drei verschiedene Seiten im selben Monat ihre Schema-Validierung verlieren, bedeutet meist, dass etwas weiter vorn in der Kette, etwa ein Template, ein Plugin oder eine kürzliche Änderung an der Website, das Problem immer wieder verursacht. Es ist also nicht jeweils ein eigener, unzusammenhängender Zufall.

Der eigentliche Wert dieser kurzen, regelmäßigen Routine liegt darin, dieses Muster beim wöchentlichen Check zu erkennen, statt es erst beim jährlichen Audit zu entdecken. Die Routine sollte nicht erst dann beginnen, wenn etwas sichtbar kaputtgeht.

Häufige Fehler beim technischen SEO Audit

Einige Gewohnheiten machen den Nutzen eines ansonsten sorgfältigen technischen SEO Audits immer wieder zunichte. Die meisten davon entstehen, wenn ein Bericht in der falschen Reihenfolge abgearbeitet wird oder einer falschen Zahl hinterhergejagt wird.

Strukturierte Daten vor einem Crawling-Problem zu beheben, gehört zu den häufigsten Fehlern. Wer einen Nachmittag damit verbringt, FAQ-Markup auf einer Seite zu ergänzen, die in der robots.txt blockiert ist, sorgt dafür, dass dieses Markup ungenutzt bleibt, bis die zugrunde liegende Blockade aufgehoben ist. Deshalb zählt die Reihenfolge der Arbeit oft mehr als die Qualität der Arbeit selbst.

Ein perfekter Geschwindigkeitswert ist der nächste Fehler. Eine Seite, die die dokumentierten Core Web Vitals Schwellenwerte bereits erreicht, gewinnt durch weitere Hundertstelsekunden keinen zusätzlichen Vorteil bei der Ladezeit als Ranking-Faktor, auch wenn die Bewertung eines Testtools mit 100 von 100 Punkten das trotzdem lohnenswert erscheinen lässt. Ein Audit der Ladezeit sollte deshalb auf echte Schwellenwerte zielen, nicht auf eine Zahl.

Mobile Tests zu überspringen und nur ein Desktop-Browserfenster zu verkleinern, übersieht echte Probleme. Ein verkleinertes Fenster bildet weder einen Touchscreen nach noch eine langsamere mobile Verbindung oder die Art, wie das Betriebssystem eines Smartphones Schriften darstellt. Probleme, die nur auf einem echten Gerät auftreten, bleiben so unbemerkt.

Zuletzt die fehlende Kontrolle nach der Umsetzung. Eine Korrektur, die nicht wirklich gespeichert wurde oder durch eine spätere Änderung überschrieben wurde, kann monatelang kaputt bleiben, wenn niemand noch einmal nachsieht, ob sie funktioniert.

Wo RepGet hineinpasst

Der größte Teil dieses Artikels lässt sich mit der Search Console und einem Smartphone in der Hand erledigen. Ein erster Durchgang über die ganze Website geht allerdings mit einem dafür gebauten Tool schneller. Das kostenlose Website-Audit von RepGet crawlt eine Website und vergibt einen SEO-Wert von 0 bis 100. Dabei werden technische Probleme markiert, die eine Untersuchung wert sind, neben inhaltlichen Punkten. Dazu gehören mehrere Punkte aus diesem Artikel: ob Seiten erreichbar und indexiert sind und grundlegende Probleme mit der Seitenerfahrung. Es ist ein sinnvoller Ausgangspunkt, um zu sehen, wo eine Website bei den meisten Punkten dieser Liste gerade steht. Es ist kein Konto und keine Kreditkarte erforderlich.

RepGet ersetzt die eigenen Berichte der Search Console zur Seitenindexierung und zu den Core Web Vitals nicht. Diese stützen sich auf Daten echter Besucher, die ein einmaliger Crawl nicht sehen kann. RepGet nimmt Ihnen außerdem nicht die Entscheidung ab, welche Korrektur für Ihre Website diese Woche am wichtigsten ist. Und es garantiert weder ein Ranking, eine Position in Google Maps noch ein Traffic-Ergebnis durch eine technische Korrektur, egal wie sorgfältig sie umgesetzt wurde.

Das Fazit

Für die meisten Websites kleiner Unternehmen muss ein technisches SEO Audit nur vier Dinge abdecken: ob Google Ihre Seiten crawlen und indexieren kann, wie schnell sie laden, wie sie auf einem Smartphone dargestellt werden und ob Ihre strukturierten Daten gültig sind. Wer sich mit Schema Markup für kleine Unternehmen beschäftigt, sollte diesen Punkt also als letzten Schritt einplanen.

Die Reihenfolge, in der Sie diese Punkte abarbeiten, ist wichtiger als die Abarbeitung aller vierzig Punkte, die ein langer Bericht vielleicht markiert. Eine blockierte Seite macht alles andere auf der Liste wirkungslos, deshalb kommt sie zuerst. Geschwindigkeit und mobile Darstellung betreffen jeden echten Besucher, deshalb folgen sie als Nächstes. Strukturierte Daten bringen Mehrwert auf einer Seite, die bereits funktioniert, deshalb kommen sie zuletzt.

Kein Audit, so gründlich es auch ist, kann versprechen, wo eine Seite in den Suchergebnissen landet, sobald die Korrekturen umgesetzt sind. Es kann aber sicherstellen, dass Google tatsächlich die beste Version Ihrer Website sieht und nicht rät, anhand einer Version mit Problemen, die niemand bemerkt hat.

Finden Sie zuerst heraus, was Ihre Website braucht

Bevor Sie eine lange Problemliste von Hand abarbeiten, sehen Sie nach, wo Ihre Website tatsächlich steht. Starten Sie ein kostenloses Website-Audit mit RepGet, um Crawlbarkeit, Indexierung und grundlegende Seitenerfahrung zusammen mit Ihren Inhalten zu prüfen. Es ist kein Konto und keine Kreditkarte erforderlich.