Produktivseite abrufbar machen
Listen Sie die Seiten auf, die Sie gefunden haben möchten: üblicherweise die Startseite, zentrale Produkt‑ oder Service‑Seiten, wichtige Kategorien, Support‑Seiten und eigene Artikel. Erfassen Sie jede finale HTTPS-URL und ob sie für die Suche vorgesehen ist. Testen Sie die öffentliche Produktionsadresse in einem abgemeldeten Browser; Staging-, Vorschau- und angemeldete Ansichten können sich anders verhalten.
Prüfen Sie auf Passwortwände, siteweite noindex-Direktiven, robots-Regeln, Fehler, Weiterleitungsketten und fehlende renderkritische Ressourcen. robots.txt steuert den Zugriff von Crawlern; Google weist darauf hin, dass sie kein Mittel ist, eine Webseite aus der Suche zu halten. Verwenden Sie Zugriffskontrollen für private Inhalte und noindex für öffentlich bewusst von der Suche ausgeschlossene Seiten.
Trennen Sie indexierbare öffentliche Seiten, bewusste Ausschlüsse und private Bereiche vor dem Testen.
Laden Sie die bevorzugte URL sowie relevante HTTP-, Host-, Slash- und Legacy‑Varianten.
Wählen Sie pro Inhaltselement eine bevorzugte URL
Eine kanonische URL ist die repräsentative Adresse für doppelte oder sehr ähnliche Inhalte. Entscheiden Sie den bevorzugten Host, die Slash‑Konvention und die Behandlung von Parametern, Druckseiten und stillgelegten Pfaden. Navigation, XML‑Sitemaps, rel=canonical‑Links und Weiterleitungen sollten dieselbe Adresse nennen.
Verwenden Sie eine permanente serverseitige Weiterleitung beim Entfernen oder Konsolidieren eines Duplikats. Auf indexierbaren HTML‑Seiten nutzen Sie ein absolutes rel=canonical‑Link-Element im Seitenkopf und fügen Sie auf der bevorzugten Seite einen selbstreferenzierenden Link ein. Google beschreibt Weiterleitungen und kanonische Annotationen als starke Signale, die Sitemap‑Aufnahme als schwächer, und trifft manchmal dennoch eigene kanonische Entscheidungen.
Für jede sinnvolle Variante erfassen Sie Quelle, Ziel, kanonische URL und Begründung.
Führen Sie nicht eine URL in der Sitemap auf und deklarieren oder verlinken gleichzeitig eine andere als kanonisch.
Leiten Sie HTTP‑Varianten auf die funktionierende bevorzugte HTTPS‑Adresse um.
Machen Sie Prioritätsseiten klar und nützlich
Schreiben Sie einen einzigartigen, prägnanten Seitentitel, der Angebot oder Antwort genau identifiziert. Fügen Sie eine kurze, seitenbezogene Meta‑Beschreibung als Kandidaten‑Zusammenfassung hinzu, nicht als Versprechen dessen, was Google anzeigt. Google kann einen Titel aus mehreren Signalen generieren und ein Snippet aus Seiteninhalt oder manchmal aus der Beschreibung. Stellen Sie die wesentliche Erklärung und den nächsten Schritt im sichtbaren Text bereit.
Verwenden Sie beschreibende Überschriften und natürliche Sprache, die die Aufgabe des Besuchers beantwortet. Vermeiden Sie kopierten Text und nahezu identische Seiten mit wenig einzigartigem Wert. Geben Sie beschreibenden Alt‑Text für bedeutungsvolle Bilder an. Verschwenden Sie beim Launch keine Ressourcen auf ein Keywords‑Meta‑Tag: web.dev sagt, Suchmaschinen halten es nicht mehr für nützlich.
Ein Leser kann Seiten anhand ihrer Titel unterscheiden, ohne sich wiederholende Begriffe.
Die Seite beantwortet ihre zentrale Frage, bevor sie zum Verkauf oder zur Anmeldung auffordert.
Verknüpfen Sie die Site mit nützlichen internen Links
Interne Links sind Verknüpfungen zwischen Seiten derselben Website. Sie helfen Besuchern bei der Navigation und Google beim Finden von Inhalten. Verlinken Sie von der Startseite und relevanten Hubs zu Prioritätsseiten und verwenden Sie Ankertext, der das Ziel identifiziert. Fügen Sie kontextuelle Links hinzu, wenn sie die nächste Frage des Besuchers beantworten; eine lange Footer‑Liste kann eine verständliche Struktur nicht ersetzen.
Verwenden Sie kanonische URLs in Navigation, Breadcrumbs, verwandten Inhalten und Calls to Action. Auf einer kleinen Site klicken Sie jede primäre Route durch. Auf einer größeren Site verwenden Sie ein Crawl‑Tool, dem Ihr Team vertraut, um verwaiste Prioritätsseiten, defekte Links und unerwartete Antwortcodes zu untersuchen.
Jede Prioritätsseite braucht einen nützlichen Pfad aus einem Menü, Hub oder verwandten Inhalt.
Prüfen Sie mobile Menüs, Formulare, Akkordeons und Einwilligungs‑Overlays sowie Desktop‑Links.
Veröffentlichen Sie eine saubere Sitemap
Eine XML‑Sitemap sagt Suchmaschinen, welche Seiten und Dateien Sie für wichtig halten. Sie kann die Entdeckung für eine neue Site unterstützen, garantiert aber kein Crawling oder Indexierung. Wenn ein CMS eine erzeugt, prüfen Sie sie. Nehmen Sie bevorzugte öffentliche URLs auf, die für die Suche gedacht sind; schließen Sie Weiterleitungen, Fehler, Testseiten und URLs aus, die für die Indexierung blockiert sind.
Belassen Sie die Sitemap an einer stabilen Position und reichen Sie sie in der Search Console ein, falls angemessen. Sie ergänzt internales Verlinken, Inhaltsqualität und Crawl‑Zugriff, repariert diese Probleme jedoch nicht. Verwenden Sie spezialisierte Sitemap‑Erweiterungen nur, wenn sie zur Live‑Implementierung passen.
Vergleichen Sie Sitemap‑URLs mit dem Seiteninventar und der Kanonikal‑Karte.
Bestätigen Sie, dass neu bevorzugte Seiten erscheinen und stillgelegte URLs verschwinden.
Entdeckung messen und gezielte URLs diagnostizieren
Verifizieren Sie die Eigentümerschaft der Produktions‑Property in der Google Search Console. Reichen Sie die Sitemap ein, wenn Sie eine verwenden. Untersuchen Sie eine repräsentative Stichprobe: die Startseite, jede wichtige Template‑Seite, eine kürzlich geänderte Seite und eine hochrelevante Migrations‑URL. Die URL‑Prüfung (URL Inspection) liefert aktuelle Index‑Informationen und kann eine Live‑URL testen; verwenden Sie sie zur Untersuchung eines Symptoms, nicht um mechanisch jede URL anzufordern.
Dokumentieren Sie Startdatum, URL‑Konventionen, Sitemap‑Adresse, Prioritätsseiten und Ausschlüsse. Prüfen Sie die Search‑Leistung für Impressionen, Klicks, Suchanfragen, Seiten und Länder. Die Search Console ist Google‑spezifisch und Daten können Zeit brauchen, deshalb ist sie Diagnose‑Beweis, kein sofortiger Nachweis, dass jede Suchmaschine den Launch verarbeitet hat.
Speichern Sie getestete URLs, beobachtetes Ergebnis, Datum und Verantwortlichen zum späteren Vergleich.
Kontrollieren Sie Index‑Ausschlüsse, Sicherheitsprobleme und Core Web Vitals neben Seiten‑Tests.
Machen Sie SEO zu einem Release‑ und Fehlerbehebungs‑Check
Nehmen Sie das Seiteninventar, Weiterleitungen, Canonicals, Sitemap und repräsentative Live‑URL‑Checks in die Startdokumentation auf. Status Is UP betrachtet dies als proaktive Uptime‑Optimierung und Fehlerbehebung: Decken Sie Bereitstellungs‑ oder Konfigurationsfehler vor einem Release auf und führen Sie eine kontrollierte Korrektur aus, wenn einer eingeführt wird. Verfügbarkeit ist keine Ranking‑Garantie.
Benennen Sie die Person, die eine gezielte Rücknahme (Rollback) genehmigen kann, falls ein Release eine öffentliche Route, den Seitenkopf, die Navigation oder die Sitemap‑Generierung beschädigt. Testen Sie die betroffenen bevorzugten URLs nach der Behebung erneut. Ein Public‑Route‑Preflight reduziert vermeidbare Bereitstellungsfehler, kann aber das Crawling, die Indexierung oder Rankings einer Suchmaschine nicht vorhersagen.
Testen Sie repräsentative öffentliche Routen und Ressourcen nach dem Deployment, nicht nur auf Staging.
Dokumentieren Sie, wer eine schädliche Routing-, Template-, Robots- oder Sitemap‑Änderung zurücknehmen kann.