Zum Inhalt springen
megapromotingLassen Sie uns sprechen

Kompetenz · SEO

Optimierung für klassische Suchmaschinen: Wir gehen jede Adresse durch, setzen das Ergebnis in eine Tabelle und reparieren, was sich überprüfen lässt.

Technische und strukturelle SEO — Indexierbarkeit, kanonische Adressen, aus Daten generierte Sitemap, Weiterleitungen, Titel und Beschreibungen, dünner Inhalt, in Bytes gemessene Geschwindigkeit. Keine Positionsversprechen.

Bereits gebautDouă implementări proprii, ambele deschise pe disc. Prima: auditul acestui site — 249 de adrese parcurse cu cereri directe, 23 de coloane per adresă, rezultatul într-un fișier tabelar versionat lângă cod, plus reparațiile care au ieșit din el (adresa canonică rezolvată o dată pentru toate rutele, adresa de partajare, harta de site generată din date). A doua: `mega-seo-analyzer`, un analizor propriu cu 16 module de analiză și un scor ponderat scris explicit în cod. Ce nu putem susține și nu vom scrie: poziții obținute sau procente de creștere. Nu avem măsurători publicabile pentru așa ceva.

Klassisches SEO ist ein Inventarberuf, kein Ideenberuf. Eine Suchmaschine muss jede Seite erreichen können, verstehen, welche ihre offizielle Version ist, einen Titel und eine Beschreibung erhalten, die sich nicht wiederholen, und genug Inhalt finden, damit sich ein Platz in einer Liste lohnt. Fast alles, was hier kaputtgeht, lässt sich zählen, und was sich zählen lässt, lässt sich reparieren.

Deshalb beginnen wir mit einem vollständigen Durchlauf, nicht mit einer Stichprobe. Auf dieser Website kamen 249 Adressen heraus, jede mit 23 Spalten: Antwortcode, kanonische Adresse, Titel, Beschreibung, hreflang, Anzahl strukturierter Datenblöcke, Umfang des sichtbaren Textes und der Rest. Das Ergebnis ist eine tabellarische Datei, versioniert neben dem Code, daher lässt sich jede der folgenden Aussagen mit den Befehlen im Anhang des Berichts reproduzieren.

Was herauskam: 244 Adressen antworten mit 200 und fünf leiten weiter. 131 Seiten hatten keine kanonische Adresse. 219 von 244 erklärten die Startseite zur Share-Adresse, also zeigte jede Weitergabe die falsche Seite. 100 Titel überschritten 60 Zeichen, der längste hatte 106. 65 Seiten teilten sich eine einzige aus der Vorlage generierte Beschreibung. 96 Seiten hatten weniger als 2.000 Zeichen sichtbaren Text. Die ersten beiden wurden mit je einer Zeile in der Grundkonfiguration repariert, die auf jede Route angewendet wird; der Rest steht in der Arbeitsliste, mit festgelegter Priorität.

Diese Seite ist eine von drei. SEO kümmert sich um Suchmaschinen, die eine Linkliste zurückgeben. Die Sichtbarkeit in von Modellen generierten Antworten ist etwas anderes und hat ihre eigene Seite, weil sie anders gesteuert wird und — wichtig — nicht versprochen werden kann. Direkte Antworten und strukturierte Daten sind die dritte. Was alle drei gemeinsam haben: Die Seite muss zugänglich, serverseitig gerendert und mit einer einzigen offiziellen Adresse versehen sein. Dieser Teil wird einmal gemacht und gilt für alles.

Was dazugehört

Die Arbeit, nach Bestandteilen

Wir gehen jede Adresse durch, nicht eine Stichprobe

Direkte Anfragen an jede bekannte Adresse, ohne Weiterleitungen zu verfolgen, mit höchstens sechs gleichzeitigen Anfragen, damit der Server nicht belastet wird, und 23 Spalten pro Adresse: Code, kanonische Adresse, Titel, Beschreibung, hreflang, Anzahl strukturierter Datenblöcke, Umfang des sichtbaren Textes. Das Ergebnis ist eine tabellarische Datei, die wir übergeben. Auf dieser Website: 249 Adressen, davon antworten 244 mit 200 und 5 leiten weiter.

Die offizielle Adresse einer Seite, einmal für die gesamte Website gelöst

131 Seiten deklarierten keine kanonische Adresse, und 219 von 244 deklarierten die Startseite als Share-Adresse — also zeigte jede Verteilung in sozialen Netzwerken eine andere Seite. Beides wurde mit je einer relativen Erklärung in der Grundkonfiguration behoben, die für jede Route einzeln aufgelöst wird. Es ist eine Zeile Code statt einer Konvention, an die sich jede neue Seite selbst hätte erinnern müssen.

Aus Daten generierte Sitemap, nach der Veröffentlichung überprüft

Die Sitemap wird aus den Inhaltsquellen erstellt und durchläuft eine abschließende Deduplizierung — auf dieser Website, 147 Adressen, dieselbe Zahl im Code und in der von der Produktion ausgelieferten Datei. Ein nach der Veröffentlichung ausgeführtes Skript schlägt fehl, wenn die Sitemap eine Seite verliert oder wenn Adressvarianten auftauchen, die sich nicht öffnen lassen. Was heute fehlt, als fehlend benannt: Die Einträge tragen kein Datum der letzten Änderung, und 93 indexierbare Adressen sind noch nicht enthalten.

Die alten Adressen erhalten jeweils eine Entscheidung

Bei einer Umstrukturierung erhält jede vorhandene Adresse ein Urteil: Sie bleibt, wird dauerhaft weitergeleitet oder verschwindet. Auf dieser Website ergaben sich 43 Weiterleitungen in der Konfiguration. Getrennt geprüft wurden auch die Dinge, die niemand testet: der Sprung von der Domain ohne `www` zur Domain mit `www` ist nur einer; die Adresse mit abschließendem Schrägstrich leitet korrekt weiter; die in Großbuchstaben geschriebene Adresse gibt 404 zurück, also gibt es kein Schreibduplikat.

Titel, Beschreibungen und dünner Inhalt, gezählt

100 von 244 Titeln überschreiten 60 Zeichen, der längste hat 106 — das Risiko ist das Abschneiden in den Ergebnissen. 33 Beschreibungen überschreiten 160 Zeichen, aber keine fehlt. Ernster: 65 Seiten teilen sich eine einzige aus der Vorlage generierte Beschreibung, und 30 von ihnen unterscheiden sich insgesamt um 240 Bytes. Median des sichtbaren Textes: 2.328 Zeichen, mit 96 Seiten unter 2.000. Das sind Zahlen, keine Eindrücke, und hinter jeder steht eine Liste von Adressen.

Ein eigener Analysator, mit Modulen und Gewichten, die im Code geschrieben sind

Unser Analysator hat 16 Module — On-Page, Performance, Sitemap, Sicherheit, Barrierefreiheit, Namensinfrastruktur, Informationen zur Domainregistrierung, externe Links, soziale Netzwerke, technischer Stack, Positionen, Keyword-Recherche, allgemeines Audit — plus Vergleichsmodule: Finden von Wettbewerbern, Keyword-Differenz, Inhaltsdifferenz, Benchmarks. Der Gesamtscore ist im Code ausdrücklich gewichtet: Performance 0,20, SEO 0,20, On-Page 0,15, Sicherheit 0,15, direkte Antworten 0,10, Barrierefreiheit 0,10, Social 0,10. Module, die fehlschlagen, ziehen den Score nicht nach unten — sie fallen aus der Gewichtung heraus, damit ein ausgefallener externer Dienst keinen falschen Bericht erzeugt.

Weiterleitungen, die keine ganze Seite kosten

Eine aus der Anwendung heraus ausgeführte Weiterleitung baut die Seite auf und sendet erst danach die Weiterleitungsantwort. Auf dieser Website gibt es 11 solche Fälle, bei denen jeweils über 200 KB HTML erzeugt werden, bevor „gehen Sie woanders hin“ gesagt wird. Es funktioniert, ist aber Verschwendung; sie in die Konfiguration zu verlegen, ist eine kleine Arbeit mit direkter Wirkung auf das Crawl-Budget. Es steht in der Reparaturliste, als fehlend vermerkt.

Was ein Crawler sieht, geprüft mit dem Crawler, nicht angenommen

Wir haben fünf Adressen mit 18 verschiedenen User-Agent-Identifikatoren angefordert und den Code, die Größe und den Fingerabdruck des normalisierten Inhalts verglichen. Alle erhalten 200 und exakt denselben Inhalt wie ein Browser; `robots.txt` ist für alle identisch, 129 Byte; es gibt keine Blockierung, Herausforderung oder Begrenzung für Crawler. Der einzige reproduzierbare Unterschied — 237 Byte weniger auf einer dynamischen Seite für drei Agenten — kommt vom Framework selbst, das ihnen vollständiges, nicht gestreamtes HTML sendet, also mehr fertig gerenderten Inhalt, nicht weniger.

Was wir nicht versprechen, vor dem Vertrag geschrieben

Wir versprechen keine Positionen, keine Wachstumsprozente und keine Zahl von Besuchen. Wir haben keine veröffentlichbaren Messungen dafür und erfinden nichts. Was wir liefern, ist auf andere Weise prüfbar: die Liste der Adressen mit ihrem jeweiligen Status, die vorgenommenen Reparaturen, die nach der Veröffentlichung ausgeführte Prüfung und die messbare Differenz zwischen dem Zustand davor und danach — in Bytes, Codes und Seitenzahlen, nicht in Versprechen.

Wie es aussieht

Der Weg, Schritt für Schritt.

01

Vollständiges Crawling und Status-Tabelle

Die erste Lieferung ist die Tabellendatei mit jeder Adresse und ihrem Status in 23 Spalten sowie den Befehlen, die sie reproduzieren. Ab hier hat jede Diskussion eine Zeile im Hintergrund. Das ist auch der Moment, in dem die Adressen auftauchen, von denen niemand wusste, dass es sie gibt.

02

Strukturelle Reparaturen, nach Wirkung geordnet

Zuerst das, was an einem Ort behoben wird und überall wirkt: kanonische Adresse, Freigabeadresse, Verhalten der Fehlerseite, Regeln für Bots. Danach das, was Arbeit pro Seite erfordert: Titel, Beschreibungen, dünner Inhalt. Die Reihenfolge ist nicht verhandelbar — umgekehrt reparieren Sie hundert Seiten manuell für etwas, das sich mit einer Zeile erledigen ließ.

03

Sitemap und Weiterleitungen

Die Sitemap ist mit den Datenquellen verknüpft, damit eine neue Seite automatisch aufgenommen wird. Alte Adressen erhalten permanente Weiterleitungen in der Konfiguration, nicht innerhalb der Anwendung. Wir liefern die vollständige Liste der Entscheidungen, Adresse für Adresse.

04

Die Prüfung, die nach uns bleibt

Wir liefern ein Skript, das nach jeder Veröffentlichung ausgeführt wird und fehlschlägt, wenn eine kanonische Adresse verschwunden ist, wenn die Sitemap eine Seite verloren hat oder wenn `robots.txt` angefangen hat, Render-Ressourcen zu blockieren. Ohne es erodieren die Reparaturen innerhalb weniger Monate, und niemand merkt es bis zum nächsten Audit.

05

Die Messung mit Ihren Werkzeugen

Wenn Sie eine Search Console und ein Analysewerkzeug haben, setzen wir die Berichterstattung darüber auf und legen fest, was wir verfolgen. Wenn Sie keine haben, ist der erste Schritt, sie zu haben — und das sagen wir vorher, nicht danach. Was wir nicht tun: Positionen aus einem Drittanbieter-Tool so berichten, als wären es Quelldaten.

Site-ul ca teritoriu, verificările ca straturi peste el1cod de răspuns2adresă canonică3titlu și descriere4date structurate5volum de text249 de adrese, 23 de coloane, un singur fișier tabelar.
Site-ul ca teritoriu, verificările ca straturi peste el

Die Daten

Was wir anfassen, wo die Daten liegen und wie lange sie bleiben

Die Fragen, die jede Person mit einem Datenschutzbeauftragten stellt — hier gestellt, bevor er sie stellt.

Was wir von Ihrer Website lesen
Nur das Öffentliche: das HTML der Seiten, die Antwort-Header, `robots.txt`, die Sitemap. Direkte Anfragen, mit begrenztem Tempo — höchstens sechs parallel, damit das Crawling nicht wie ein Angriff wirkt. Für den Audit-Teil brauchen wir keinen Zugang zur Verwaltung.
Was wir von Ihnen brauchen, wenn Sie auch den Messeteil wollen
Lesezugriff auf die Suchkonsole und das Traffic-Analyse-Tool. Ohne sie können wir sagen, was technisch falsch ist, aber nicht, was in den Ergebnissen passiert. Das Audit dieser Website wurde absichtlich ohne solchen Zugriff durchgeführt, und die Grenze ist im Dokument ausdrücklich angegeben — damit niemand eine technische Messung mit einer Traffic-Messung verwechselt.
Wo die Ergebnisse liegen
Die Tabellen-Datei mit dem Crawl und der schriftliche Bericht liegen im Projekt-Repository, versioniert neben dem Code. Nicht in einer Präsentation und nicht in einem Abonnement-Tool, aus dem Sie sie nicht mehr herausbekommen. Wenn sich eine Zahl ändert, ist in der Dateihistorie sichtbar, wer sie wann geändert hat.
Aufbewahrung der Berichte
Sie leben so lange wie das Projekt-Repository lebt. Die gecrawlten Daten sind per Definition öffentlich — es sind Ihre Seiten, so wie sie jeder sieht. Wenn das Audit Bereiche berührt, die eine Authentifizierung erfordern, wird separat festgelegt, was gespeichert wird und wie lange.

Ein Fall

249 Adressen, 23 Spalten und zwei Codezeilen, die 350 Seiten repariert haben

Die Ausgangslage

Eine kürzlich umstrukturierte Website mit etwa 250 öffentlichen Adressen. Alle antworteten mit 200 und nichts schien falsch zu sein. Die Ausgangsfrage war nicht „wie steigern wir den Traffic“, sondern „was sagt jede Seite über sich selbst aus“.

Was wir gebaut haben

Wir haben jede Adresse mit direkten Anfragen gecrawlt, ohne Weiterleitungen zu verfolgen, mit höchstens sechs gleichzeitigen Anfragen, und für jede 23 Spalten in eine Tabellen-Datei geschrieben, versioniert neben dem Code. Darüber haben wir separate Prüfungen laufen lassen: wer welche kanonische Adresse angibt, wer welche Teilen-Adresse angibt, wie lang Titel und Beschreibungen sind, wie viele Seiten dieselbe Vorlagenbeschreibung teilen, wie viel sichtbaren Text jede hat, was der Server auf 18 verschiedene User-Agents antwortet, was er bei Komprimierung und Protokoll bietet. Jede Zahl wurde aus der echten Antwort gelesen, nicht aus der Konfiguration abgeleitet.

Was dabei herauskam

244 Adressen antworten mit 200, fünf leiten weiter. 131 Seiten gaben keine kanonische Adresse an; 219 von 244 gaben die Startseite als Teilen-Adresse an. Beide wurden mit jeweils einer relativen Anweisung in der Grundkonfiguration behoben — zwei Zeilen, die für jede Route gelten, statt einer Korrektur auf jeder Seite. Die übrigen Feststellungen sind in einen Plan mit elf Schritten eingegangen, in der Reihenfolge der Wirkung: 100 Titel über 60 Zeichen, 65 Seiten mit einer Beschreibung aus der Vorlage, 96 Seiten mit weniger als 2.000 Zeichen Text, 93 fehlende indexierbare Adressen aus der Sitemap, 11 interne Weiterleitungen.

Was der Fall nicht sagt

Das Audit wurde absichtlich ohne Zugriff auf die Suchkonsole und ohne Traffic-Daten durchgeführt, und die Grenze ist im Bericht geschrieben: Wir können sagen, was technisch falsch ist, nicht, was in den Ergebnissen passiert. Von den elf Schritten des Plans werden zwei heute umgesetzt; der Rest sind offene Arbeiten, nicht abgehakt. Ein Bericht, der am Tag seiner Erstellung alle Schritte als erledigt ausweist, ist kein Bericht.

Fragen

Was uns die Leute fragen, bevor sie anrufen

Was ist kurz gesagt der Unterschied zwischen SEO, GEO und AEO?

Das Publikum ist unterschiedlich. SEO richtet sich an Suchmaschinen, die eine Liste von Links zurückgeben — Ihre Seite erscheint, die Person klickt. GEO richtet sich an generative Modelle, die eine Antwort zusammenstellen und eine Quelle zitieren können; dort gibt es keine Position und keine Garantie, also arbeitet man an dem, was kontrollierbar ist, nicht am Ergebnis. AEO richtet sich an direkte Antworten — das extrahierte Snippet, das Informationsfeld, die Sprachantwort — und stützt sich auf korrekte strukturierte Daten. Die Grundlage ist gemeinsam: zugängliche, serverseitig gerenderte Seite mit einer einzigen offiziellen Adresse. Dieser Teil wird einmal gemacht.

Was liefern Sie in einem SEO-Audit konkret?

Eine Tabellen-Datei mit jeder Adresse der Website und ihrem Status in 23 Spalten — Antwortcode, kanonische Adresse, Titel, Beschreibung, hreflang, Blöcke strukturierter Daten, Textumfang — plus einen schriftlichen Bericht mit den Feststellungen in der Reihenfolge der Wirkung, jeweils mit Stelle im Code, Kriterium und Behebung. Und die Befehle, die jede Zahl reproduzieren. Bei dieser Website kamen 249 Zeilen heraus; sie liegt direkt im Repository, neben dem Code.

Garantieren Sie Platz 1?

Nein, und auch keinen bestimmten Platz. Wir haben keine öffentlich verwertbaren Messungen für Ergebnisse dieser Art und erfinden keine. Was wir zeigen können, ist der überprüfbare Unterschied: wie viele Seiten vorher keine kanonische Adresse hatten und wie viele jetzt, wie viele die Teilen-Adresse falsch angaben, wie viele alte Adressen ohne Weiterleitung geblieben sind. Bei dieser Website waren es 131 beziehungsweise 219 von 244. Das sind Fakten; ein versprochener Platz ist es nicht.

Woher wissen Sie, dass das, was Sie reparieren, repariert bleibt?

Aus einem Skript, das nach jeder Veröffentlichung läuft, die kanonischen Adressen, die Content-Anker, die Sitemap und `robots.txt` prüft und fehlschlägt, wenn etwas verschwunden ist. SEO-Korrekturen erodieren genau wie jede andere ungeschriebene Konvention: Jemand fügt eine neue Seite hinzu, vergisst eine Anweisung, und niemand bemerkt es bis zum nächsten Audit. Ein Skript bemerkt es sofort.

Verfügen Sie über eigene Tools oder verwenden Sie Abonnements?

Beides hat seinen Sinn, aber die technische Analyse machen wir mit einem eigenen Analyzer: 16 Module — On-Page, Leistung, Sitemap, Sicherheit, Zugänglichkeit, Namensinfrastruktur, Domainregistrierung, externe Links, soziale Netzwerke, technischer Stack, Positionen, Schlüsselwörter — plus Vergleichsmodule mit Wettbewerbern. Der Gesamtwert hat im Code festgeschriebene, nicht verborgene Gewichtungen: Leistung und SEO je 0,20, On-Page und Sicherheit je 0,15, der Rest je 0,10. Ein Modul, das ausfällt, fällt aus der Gewichtung heraus, statt einen falschen Wert zu erzeugen.

Was machen Sie mit hundert fast identischen Seiten?

Wir markieren sie als Risiko, nicht als Chance. Bei dieser Website sind 100 der 147 Adressen in der Sitemap Kombinationen Dienst × Domain, und 65 Seiten teilen sich eine einzige Beschreibung aus der Vorlage — 30 davon unterscheiden sich untereinander insgesamt um 240 Bytes. Eine Suchmaschine behandelt das als in großem Maßstab erzeugten Inhalt, und das Risiko ist eine Sanktion, nicht ein Plus an Sichtbarkeit. Die Lösung ist echter Inhalt auf jeder Seite oder weniger Seiten. Wir empfehlen nicht, Seiten als Strategie zu erzeugen.

Spielt Geschwindigkeit für SEO eine Rolle?

Ja, aber nicht in der Form, in der sie üblicherweise verkauft wird. Wir geben Ihnen keinen Laborwert, weil er sich leicht verschieben lässt und nicht sagt, was ein Besucher erlebt. Wir geben Ihnen gemessene Bytes: wie viel das komprimierte HTML wiegt, was bei jeder Navigation übertragen wird, was die JavaScript-Pakete enthalten, ob der Server moderne Komprimierung und ein neues Protokoll anbietet. Bei dieser Website: weder Brotli noch HTTP/2, der Übersetzungskatalog kostet auf jeder Navigation etwa 70 KB komprimiert, und ein 443-KB-Paket enthält vier Sprachkataloge, von denen nur einer genutzt wird. Alle drei stehen auf der Reparaturliste.

Blockieren Sie KI-Crawler?

Das ist eine Entscheidung des Websiteinhabers, nicht unsere, und sie verlangt die Trennung von drei Kategorien, die heute auf den meisten Websites identisch behandelt werden: Such-Crawler, die Menschen zurückführen, von einem Menschen ausgelöste Agenten, der die Seite angefordert hat, und Trainings-Crawler. Die Regeln für sie sind unabhängig. Auf dieser Website gibt es derzeit nur eine allgemeine Regel, also ist die Position implizit — und wir sagen das, statt so zu tun, als wäre es eine Strategie. Die Details gehören zur Seite über die Sichtbarkeit in generierten Antworten.

Was machen Sie nicht?

Wir kaufen keine Links und bauen keine Netzwerke von Websites auf. Wir erzeugen keine Seiten in großem Maßstab, um Wortkombinationen abzudecken. Wir melden keine aus einem Drittinstrument übernommenen Positionen so, als wären sie Quelldaten. Und wir erklären kein Audit ohne Tabellen-Datei und die Befehle, mit denen es reproduziert wird — ein Bericht, den Sie nicht selbst prüfen können, ist kein Audit, sondern eine Meinung.

Worauf die obigen Aussagen beruhen (14 Quellen)

14 davon sind Code und Dateien aus unseren Repositories. Wir veröffentlichen weder ihren Namen noch die Zeile: zusammen, auf einer einzigen Seite, würden sie zu genau beschreiben, wie Systeme gebaut sind, die nicht nur uns gehören. Wir gehen sie mit Ihnen durch, im Repository, auf Anfrage — die Überprüfung bleibt möglich, sie findet nur in einem Gespräch statt.

Was sollte bei Ihnen besser laufen?

Erzählen Sie uns von Ihrem Prozess. Gemeinsam legen wir fest, was sich zu bauen lohnt, was wir anbinden können und wie wir das Ergebnis prüfen.

Lassen Sie uns sprechen