#82 - Google indexiert nur 4 von 22 Seiten — kein einziger Blogartikel - Phil/philflow.io

Phil commented

2026-09-06 23:07:27 +00:00

Owner

Aus dem unabhängigen SEO-Audit vom 07.09.2026, direkt nach dem Deploy. Höchste Priorität.

Befund

site:philflow.io (Google, Germany/de, Tiefe 100) liefert sechs Treffer: /, /blog, /en/, /en/blog — plus die Subdomains raven.philflow.io und cal.philflow.io. Keiner der sechs Blogartikel ist im Index, der älteste ist vom 19. Mai, also dreieinhalb Monate alt.

Die Sitemap-Reparatur (#58) war notwendig, reicht aber nicht. Drei Ursachen, alle gemessen:

1. Die Hauptnavigation ist auf 20 von 22 Seiten tot (P1)

Header und Footer verlinken „Über mich", „Branchen" und „Angebot" als ./#uber, ./#referenzen, ./#angebot. Es gibt auf keiner Seite ein <base>-Tag.

Auf /blog löst ./#angebot damit zu /blog#angebot auf — dort kommt id="angebot" null mal vor (auf / genau einmal). Nur die beiden Startseiten funktionieren. Für Crawler heißt das: von jeder Unterseite führt kein Weg zurück in die Seitenstruktur.

Ein js-anchor-Handler könnte die Links im Browser zur Laufzeit umbiegen — für Crawler ändert das nichts. (Nicht im Browser verifiziert.)

2. Die Blog-Paginierung ist ein unendlicher Duplikat-Trichter (P1)

/blog/p2   -> 200, Selbst-Canonical auf /blog/p2, robots: index, follow
             Inhalt Wort für Wort identisch mit /blog
/blog/p9   -> 200
/blog?page=2 -> 200

Bei sechs Artikeln gibt es keine zweite Seite. Google findet damit beliebig viele indexierbare Kopien der Blog-Übersicht.

3. Es gibt praktisch keine interne Verlinkung (P2)

Die vierteilige Anti-Slop-Serie enthält keinen einzigen Link auf ihre anderen Teile. /blog/anti-slop-4-whac-a-mole verlinkt intern nur Startseite, Blog, Feed, Rechtsseiten und sich selbst. Das Kategorie-Archiv listet 2 von 6 Artikeln — die Serie ist keiner Kategorie zugeordnet.

Dazu: backlinks_summary liefert Rank 7 bei 12 Backlinks aus 10 Domains. Ohne interne Verlinkung und ohne externe Signale hat Google wenig Anlass, tiefer zu crawlen.

Akzeptanzkriterien

Navigationslinks funktionieren von jeder Seite aus, nicht nur von der Startseite
/blog/pN für nicht existierende Seiten liefert 404, nicht 200 mit Duplikat; ?page= ebenso
Falls Paginierung bleibt: rel=prev/next oder Canonical auf Seite 1
Artikel derselben Serie verlinken aufeinander
Alle sechs Artikel sind einer Kategorie zugeordnet und erscheinen im Archiv
Sitemap in der Search Console neu eingereicht, Indexabdeckung nach zwei Wochen erneut gemessen

Nicht gemessen

Die Indexabdeckung stammt aus der site:-Abfrage, nicht aus der Search Console — dort fehlt der Zugang. Ob der Paginierungs-Trichter eine Regression oder Altbestand ist, ließ sich nicht belegen: der Blog stand vorher nicht in der Sitemap.

Aus dem unabhängigen SEO-Audit vom 07.09.2026, direkt nach dem Deploy. Höchste Priorität. ## Befund `site:philflow.io` (Google, Germany/de, Tiefe 100) liefert sechs Treffer: `/`, `/blog`, `/en/`, `/en/blog` — plus die Subdomains `raven.philflow.io` und `cal.philflow.io`. **Keiner der sechs Blogartikel ist im Index**, der älteste ist vom 19. Mai, also dreieinhalb Monate alt. Die Sitemap-Reparatur (#58) war notwendig, reicht aber nicht. Drei Ursachen, alle gemessen: ## 1. Die Hauptnavigation ist auf 20 von 22 Seiten tot (P1) Header und Footer verlinken „Über mich", „Branchen" und „Angebot" als `./#uber`, `./#referenzen`, `./#angebot`. Es gibt auf keiner Seite ein `<base>`-Tag. Auf `/blog` löst `./#angebot` damit zu `/blog#angebot` auf — dort kommt `id="angebot"` **null mal** vor (auf `/` genau einmal). Nur die beiden Startseiten funktionieren. Für Crawler heißt das: von jeder Unterseite führt kein Weg zurück in die Seitenstruktur. Ein `js-anchor`-Handler könnte die Links im Browser zur Laufzeit umbiegen — für Crawler ändert das nichts. (Nicht im Browser verifiziert.) ## 2. Die Blog-Paginierung ist ein unendlicher Duplikat-Trichter (P1) ``` /blog/p2 -> 200, Selbst-Canonical auf /blog/p2, robots: index, follow Inhalt Wort für Wort identisch mit /blog /blog/p9 -> 200 /blog?page=2 -> 200 ``` Bei sechs Artikeln gibt es keine zweite Seite. Google findet damit beliebig viele indexierbare Kopien der Blog-Übersicht. ## 3. Es gibt praktisch keine interne Verlinkung (P2) Die vierteilige Anti-Slop-Serie enthält **keinen einzigen Link** auf ihre anderen Teile. `/blog/anti-slop-4-whac-a-mole` verlinkt intern nur Startseite, Blog, Feed, Rechtsseiten und sich selbst. Das Kategorie-Archiv listet 2 von 6 Artikeln — die Serie ist keiner Kategorie zugeordnet. Dazu: `backlinks_summary` liefert Rank 7 bei 12 Backlinks aus 10 Domains. Ohne interne Verlinkung und ohne externe Signale hat Google wenig Anlass, tiefer zu crawlen. ## Akzeptanzkriterien - [ ] Navigationslinks funktionieren von jeder Seite aus, nicht nur von der Startseite - [ ] `/blog/pN` für nicht existierende Seiten liefert 404, nicht 200 mit Duplikat; `?page=` ebenso - [ ] Falls Paginierung bleibt: `rel=prev/next` oder Canonical auf Seite 1 - [ ] Artikel derselben Serie verlinken aufeinander - [ ] Alle sechs Artikel sind einer Kategorie zugeordnet und erscheinen im Archiv - [ ] Sitemap in der Search Console neu eingereicht, Indexabdeckung nach zwei Wochen erneut gemessen ## Nicht gemessen Die Indexabdeckung stammt aus der `site:`-Abfrage, nicht aus der Search Console — dort fehlt der Zugang. Ob der Paginierungs-Trichter eine Regression oder Altbestand ist, ließ sich nicht belegen: der Blog stand vorher nicht in der Sitemap.

Phil referenced this issue

2026-09-06 23:08:16 +00:00

Fehlende Sicherheits-Header, llms.txt beschreibt eine andere Firma, 404-Seite wird indexiert #84

Phil commented

2026-09-07 05:58:44 +00:00

Author

Owner

Vor dem nächsten Deploy zuerst #85 lesen. Auf dem Prod-Server sind noch 5,3 GB frei (93 % belegt). Das reicht für etwa zwei Image-Rebuilds — danach läuft die Platte voll, Redis stellt das Schreiben ein und die Seite liefert auf allen URLs 500. Genau das ist in der Nacht auf den 07.09. passiert.

Ablauf und die beiden Stolpersteine, die dabei aufgefallen sind, stehen in docs/DEPLOYMENT.md (Gotchas 11 und 12): nach jedem Image-Rebuild muss storage/runtime/compiled_templates/ hart geleert werden, clear-caches/all erwischt den Ordner nicht.

Reihenfolge, die ich empfehlen würde: #85 (Platte) → dieses Issue → #83 (Sprachreinheit) → #84 (Header, llms.txt, Schema).

Stand nach dem Deploy vom 07.09., live gemessen: 22 von 22 Seiten liefern 200, Startseite 0,14 s bis zum ersten Byte, Sitemap mit 9 Einträgen, hreflang auf allen Seiten selbstreferenziell.

**Vor dem nächsten Deploy zuerst #85 lesen.** Auf dem Prod-Server sind noch 5,3 GB frei (93 % belegt). Das reicht für etwa zwei Image-Rebuilds — danach läuft die Platte voll, Redis stellt das Schreiben ein und die Seite liefert auf allen URLs 500. Genau das ist in der Nacht auf den 07.09. passiert. Ablauf und die beiden Stolpersteine, die dabei aufgefallen sind, stehen in `docs/DEPLOYMENT.md` (Gotchas 11 und 12): nach jedem Image-Rebuild muss `storage/runtime/compiled_templates/` **hart** geleert werden, `clear-caches/all` erwischt den Ordner nicht. Reihenfolge, die ich empfehlen würde: #85 (Platte) → dieses Issue → #83 (Sprachreinheit) → #84 (Header, llms.txt, Schema). Stand nach dem Deploy vom 07.09., live gemessen: 22 von 22 Seiten liefern 200, Startseite 0,14 s bis zum ersten Byte, Sitemap mit 9 Einträgen, hreflang auf allen Seiten selbstreferenziell.

Phil referenced this issue from a commit

2026-09-07 08:58:48 +00:00

fix(nav): Anker-Navigation auf jeder Seite statt nur auf der Startseite

Phil referenced this issue from a commit

2026-09-07 08:58:48 +00:00

fix(seo): Paginierung erzeugt keine Duplikate mehr, Canonical wird eindeutig

Phil referenced this issue from a commit

2026-09-07 08:58:48 +00:00

feat(blog): Artikelreihen verlinken sich selbst, alle Artikel haben eine Kategorie

Phil referenced this issue from a commit

2026-09-07 08:58:48 +00:00

fix(seo): robots.txt nennt auch die englische Sitemap