Thema: seo
-
Individuelle 404-Seiten und Soft 404s: die Fehlerseite mit dem Fehlerstatus ausliefern
Eine individuelle 404-Seite hilft Nutzenden nur, wenn sie mit Status 404 ausgeliefert wird; eine Nicht-gefunden-Seite mit Status 200 ist ein Soft 404, den Crawler weiter abrufen und den Suchmaschinen ausschliessen. nginx' error_page kann den Status umschreiben (error_page 404 =200 ...), und genau so entstehen Soft 404s versehentlich; den Status beibehalten, die Seite nützlich gestalten und mit curl -I prüfen.
-
Eine Website für Agenten lesbar machen: robots.txt, Sitemaps und llms.txt
Agenten und Crawler finden Inhalte über eine kleine Menge an Konventionen: robots.txt für Zugriffsregeln und den Sitemap-Standort, eine XML-Sitemap mit echten Änderungsdaten und llms.txt als kurzer kuratierter Leitfaden; keine davon ersetzt Authentifizierung.
-
Sitemaps und kanonische Adressen: ein Inhalt, eine Adresse
Jeder Inhalt sollte genau eine kanonische HTTPS-Adresse haben, die auf der Seite selbst erklärt wird; Zwillinge wie Markdown- oder JSON-Fassungen verweisen per Link-Header darauf, Parameter ohne Inhaltswirkung erzeugen keine neuen Adressen, und die Sitemap listet nur kanonische Adressen mit wahren Änderungsdaten.
-
Weiterleitungsketten auf einen einzigen Sprung zu verkürzen erhöht auf einer grossen Website den Anteil der Crawler-Anfragen, die mit 200 enden
Hypothese: Auf einer Website mit Zehntausenden URLs und angesammelten Weiterleitungen erhöht das Umschreiben jeder Kette, sodass jede alte URL mit genau einer Weiterleitung auf ihr endgültiges Ziel antwortet, bei einem festen täglichen Anfragevolumen messbar den Anteil der Suchcrawler-Anfragen, die eine 200-Seite erreichen, weil Crawler Anfragen für jeden Sprung aufwenden; ein vorgeschlagener Vorher-Nachher-Test anhand von Server-Logs.
-
Rufen KI-Agenten llms.txt tatsächlich ab, und was ändert die Datei an ihrem Verhalten?
Offene Frage: llms.txt ist ein Vorschlag ohne Standardisierung, und viele Sites legen die Datei an, ohne zu wissen, ob ein Agent sie liest. Welche Abrufmuster zeigen Serverlogs für /llms.txt und Markdown-Zwillinge, welche Agenten oder Werkzeuge fragen sie tatsächlich ab, und lässt sich ein Unterschied in Antwortqualität oder Abrufzahl gegenüber Sites ohne die Datei zeigen?
-
Kanonische URLs und doppelter Inhalt
Jeder Inhalt sollte eine einzige kanonische HTTPS-Adresse haben, die auf der Seite deklariert ist; Alternativen wie Markdown- oder JSON-Versionen verweisen mit einem Link-Header darauf, und Parameter, die den Inhalt nicht verändern, sollten keine neuen URLs erzeugen.
-
llms.txt und agentenlesbare Websites: robots.txt, Sitemap und ein kuratierter Einstieg
Agenten und Crawler finden Inhalte über wenige Konventionen: robots.txt für Zugriffsregeln und den Ort der Sitemap (RFC 9309), eine Sitemap mit wahren Änderungsdaten und llms.txt als kurzer kuratierter Wegweiser in Markdown, ergänzt um Markdown-Zwillinge der Seiten. Keine davon ersetzt Authentifizierung.
-
Strukturierte Daten mit JSON-LD: nur, was zutrifft
JSON-LD in einem Script-Block beschreibt die Seite mit schema.org-Typen; dabei Eigenschaften verwenden, die dem sichtbaren Inhalt entsprechen, den Block gegen Injection escapen, und keine Rich-Ergebnisse erwarten, sofern nicht die Anforderungen eines bestimmten Features erfüllt sind.
-
robots.txt, noindex und Crawling-Steuerung
robots.txt steuert das Abrufen, noindex steuert die Indexierung; eine in robots.txt gesperrte URL kann kein wirksames noindex tragen, und keines von beiden ist Zugriffskontrolle. Beide für die jeweils passende Aufgabe einsetzen und private Endpunkte weiterhin durch Authentifizierung schützen.
-
Semantisches HTML und Landmarks
header, nav, main, article, section, aside und footer verwenden, mit einem h1 pro Seite und einer logischen Überschriftenreihenfolge; assistierende Technologie, Suchmaschinen und Agenten navigieren alle anhand dieser Strukturen.
Maschinenlesbar: JSON