1. Aus Versehen alles blockieren: robots.txt, Meta-Robots, HTTP-Header
Staging ist live gegangen. Die Disallow: / blieb drin. Oder ein Build setzt <meta name="robots" content="noindex,nofollow"> global. Manchmal schießt sogar ein Reverse-Proxy per Header X-Robots-Tag: noindex quer. Crawler sind weg. Umsätze rutschen hinterher.
Dein Check: Automatisiere Prüfungen in CI/CD. Teste auf „noindex“ in HTML und Headern, prüfe robots.txt auf Disallow: /, und setze Staging per Basic-Auth oder IP-Restriktion statt Noindex in Production.
# robots.txt (Production) User-agent: * Disallow: /checkout/ Disallow: /account/ Allow: /media/ Sitemap: https://www.deinshop.de/sitemap.xml2. Ressourcen blockieren: JS, CSS, Medien
Wenn Crawler CSS und JS nicht laden dürfen, verstehen sie Layout, Lazy-Loading und Navigation schlechter. Renderprobleme führen zu Fehleinschätzungen bei Content, LCP und CLS.
Dein Check: Erlaube statische Verzeichnisse. Prüfe im „Abruf wie Google“ bzw. in der Search Console Renderberichte. Keine sensiblen Assets blocken, außer wirklich private Pfade.
# robots.txt User-agent: * Allow: /static/ Allow: /assets/ Allow: /bundles/ Disallow: /admin/Mehr zu JavaScript-SEO findest du in der Google-Doku. Lies die Basics, bevor du nächste Woche wieder am Rendering schraubst: JavaScript und Google Suche.
3. Canonical Chaos: Duplicate Content durch Filter, Sortierung, Paginierung
Shops erzeugen Varianten wie Konfetti: ?sort=, ?color=, ?page=, Facetten ohne Ende. Ohne Selbstdisziplin konkurrieren URLs intern.
Dein Check: Setze auf selbstreferenzierende Canonicals für Seitenzustände, die eigenständig ranken dürfen. Für reine Sortierungen keine Indexierung. Paginierung mit stabilen Canonicals und klaren Parametern.
<link rel="canonical" href="https://www.deinshop.de/kategorie/" /> <!-- Seite 2 der Kategorie --> <link rel="canonical" href="https://www.deinshop.de/kategorie/?page=2" />4. Hreflang falsch verdrahtet
Internationalisierer lieben Hreflang, bis Traffic verschwindet. Häufige Fehler: Verweise auf non-canonical URLs, unvollständige Rückverlinkung, falsche Ländercodes, fehlendes x-default.
Dein Check: Hreflang immer auf die kanonische Version setzen und wechselseitig verknüpfen. Automatisiere die Generierung im Build.
<link rel="alternate" href="https://example.com/de/produkt" hreflang="de-DE" /> <link rel="alternate" href="https://example.com/at/produkt" hreflang="de-AT" /> <link rel="alternate" href="https://example.com/en/product" hreflang="en" /> <link rel="alternate" href="https://example.com/" hreflang="x-default" />
Seo Shop aufräumen – E-Commerce News – Tipps & Tricks – 🛠️ Warum Shop-Entwickler oft SEO unbewusst zerstören🚦
5. JavaScript-Rendering frisst Content
Wichtige Texte, Links und Meta-Tags erscheinen nur nach Client-Rendering. Wenn Google die Ressourcen drosselt oder die App hydratisiert langsam, sieht der Bot zu wenig. Ergebnis: schwache Indexierung.
Dein Check: Liefere kritische Inhalte serverseitig gerendert. Progressive Enhancement ist dein Freund. Prüfe, ob <title>, <meta description> und Hauptinhalt im Initial-HTML stehen.
6. Core Web Vitals ignorieren
LCP, CLS und INP hängen an realen Nutzerdaten. Fehlende Bilddimensionen, nachladende Webfonts, Third-Party-Skripte im Hauptthread und gigantische JS-Bundles schaden der Performance.
Dein Check: Setze Dimensionen für Bilder und Platzhalter. Lade Fonts mit font-display=swap und Preload. Splitte Bundles, entferne ungenutztes JS. Miss Web-Vitals in der Production mit RUM.
<img src="/media/hero.webp" width="1280" height="720" alt="Sommer-Sale">Ein kompaktes Canonical-How-to hilft dir beim Aufräumen der Parameter-Hölle. Lies den Leitfaden: SISTRIX: Canonical Tag erklärt.
7. Lazy-Loading ohne Fallback
Nur JavaScript-Lazy-Loader ohne loading="lazy" oder <noscript> riskieren leere Seiten für Crawler und Nutzer ohne JS.
Dein Check: Nutze natives Lazy-Loading und ergänze ein <noscript>-Fallback.
<img src="/img/p1.webp" alt="Produkt 1" loading="lazy" width="600" height="600"> <noscript><img src="/img/p1.webp" alt="Produkt 1" width="600" height="600"></noscript>8. Pagination und Filter ohne saubere Informationsarchitektur
Endlose Scrolls, unklare URLs und Filter, die jedes Facetten-Klick als indexierbare Seite rausblasen. Das produziert dünnen Inhalt und Kannibalisierung.
Dein Check: Definiere, welche Filter indexierbar sind. Nutze konsistente URL-Parameter. Verknüpfe Pagination intern gut. Biete eine „Alle anzeigen“-Seite nur, wenn sie performant ist.
9. Soft-404s und kaputte Weiterleitungen
Produkt offline? Bitte kein 200 mit „Leider ausverkauft“. Das wirkt wie Soft-404. Oder 302-Ketten nach Relaunch. Beides kostet Budget und Vertrauen.
Dein Check: Setze 404/410 korrekt. Nutze saubere 301 auf Nachfolger. Meide Ketten und Loops. Prüfe regelmäßig mit Crawl.
# NGINX Beispiel location = /altes-produkt { return 301 https://www.deinshop.de/neues-produkt; }10. Sitemaps als Afterthought
Uralte URLs, 404er und Noindex-Seiten in der Sitemap? Dann vertraut Google deinen Signalen weniger.
Dein Check: Generiere Sitemaps täglich. Nur indexierbare, kanonische URLs aufnehmen. Pro Datei unter 50.000 URLs und 50 MB bleiben. Trenne nach Typen.
11. Strukturierte Daten mit Fehlern
Product, Offer, Breadcrumb, FAQ, Organization. Alles drin, aber falsch verknüpft oder widersprüchlich zu sichtbaren Daten.
Dein Check: Generiere JSON-LD konsistent aus denselben Datenquellen wie das Frontend. Validiere im Rich-Result-Test. Halte Preise, Verfügbarkeit und Währung synchron.
<script type="application/ld+json">{ "@context":"https://schema.org","@type":"Product", "name":"Basic Hoodie","sku":"BH-001", "offers":{"@type":"Offer","priceCurrency":"EUR","price":"49.90","availability":"https://schema.org/InStock"} }</script>12. Migration ohne Redirect-Plan
Neue Architektur, neue URLs, alte Rankings weg. Ohne 1:1-Redirect-Mapping verlierst du Linkjuice und Nutzer.
Dein Check: Erstelle ein Mapping aus Alt- auf Neu-URLs. Teste mit 100%-Abdeckung kritischer Seiten. Übertrage Metadaten, Hreflang, Canonicals, Strukturierte Daten.
13. Trailing Slashes, Groß/Kleinschreibung, http/https
Kleine Inkonsistenzen erzeugen große Dubletten. Beispiel: /Kategorie vs. /kategorie, /pfad vs. /pfad/.
Dein Check: Lege eine Norm fest. Erzwinge Weiterleitungen per Server. Setze Canonicals konsistent. Teste internen Linkgraph mit einem Crawler.
14. Session-IDs und Tracking-Parameter in Links
Wenn interne Links UTM-Parameter oder Session-IDs tragen, vervielfacht sich der URL-Raum unnötig.
Dein Check: Entferne solche Parameter in internen Links. Nutze serverseitige Attribution oder First-Party-Storage statt URL-Schwemme.
15. Interne Suche indexiert
Suchergebnisse sind dünn, volatil und gehören nicht in den Index.
Dein Check: Blocke interne Suche per robots.txt und setze noindex auf Suchergebnis-Templates.
Disallow: /search Disallow: /suche16. Cookie-Banner und Overlays, die Content verdecken
Wenn ein Consent-Layer Inhalt verdeckt oder Links unbedienbar macht, sinken Nutzersignale. Bot-Erkennung sollte den Banner ausblenden, aber sauber, ohne Cloaking.
Dein Check: Serverseitiges Consent-Tuning, kein Blockieren von Hauptinhalten. Stelle sicher, dass HTML-Content unabhängig vom Banner zugänglich bleibt.
17. Produktvarianten falsch modelliert
Größen und Farben als eigene indexierbare Seiten ohne Mehrwert erzeugen Kannibalisierung.
Dein Check: Bündle Varianten auf einer starken Produktseite. Wenn separate Seiten nötig sind, liefere klaren, eigenständigen Content oder setze Canonical auf die Hauptvariante.
18. Bilder ohne Alt-Text, falsches Format, kein CDN
Bilder ranken, beschleunigen und erklären. Ohne Alt-Text, mit riesigen JPEGs statt WebP/AVIF, dazu ohne Caching, verschenkst du Performance und Suchtraffic.
Dein Check: Nutze moderne Formate, Alt-Texte mit Kontext, Breiten/Höhen, sinnvolles Caching. Liefere responsive <source>-Sets.
<picture> <source srcset="/img/p1.avif" type="image/avif"> <source srcset="/img/p1.webp" type="image/webp"> <img src="/img/p1.jpg" alt="Herren Sneaker weiß" width="800" height="800"> </picture>Wenn du Hreflang noch vertiefen willst, liefert das Ryte-Wiki eine gute Übersicht: Ryte Wiki: Hreflang.
19. HTTP-Header und Caching-Regeln kollidieren
Fehlkonfigurierte Proxies oder CDNs überschreiben Metadaten. Plötzlich hat deine Kategorienseite einen veralteten Canonical oder einen falschen Statuscode aus dem Cache.
Dein Check: Versioniere HTML, differenziere Cache-Policies für HTML vs. Assets, invalidiere nach Deploy zielgenau.
20. Monitoring fehlt
Ohne Alerts merkst du Probleme erst, wenn Umsatz weg ist. Du brauchst Metriken für Indexierung, Statuscodes, interne Verlinkung, Web-Vitals und SERP-Klicks.
Dein Check: Richte Health-Checks ein. Automatisiere Crawls nach Deploy. Logge Bot-Traffic. Baue Dashboards für 404-Trends, 5xx-Spitzen und Sitemap-Fehler.
Praktische Quick-Wins für deine nächste Sprint-Planung
Checkliste „Vor Livegang“
- robots.txt geprüft, Staging-Reste entfernt
- Kein globales Noindex, Header sauber
- Core-URLs serverseitig gerendert
- Canonicals konsistent, Parametrisierung definiert
- Sitemap frisch, nur indexierbare URLs
- Redirect-Mapping vorhanden und getestet
- Hreflang validiert, wechselseitig
- Web-Vitals RUM aktiv, Budgets gesetzt
Was du in CI/CD automatisierst
- Linting für Meta-Robots und Canonical
- Snapshot-Tests für kritische Templates
- Crawl-Smoke-Test nach Deploy
- Sitemap-Validierung und Link-Graph-Checks
Canonical Tags falsch gesetzt = Duplicate Content Hölle. Hatten wir. War teuer.
Wir haben die Erfahrung gemacht, dass viele Entwickler SEO als ‚Bremse‘ sehen. ‚Das macht den Shop langsamer‘, ‚Das verkompliziert den Code‘, ‚Das ist old school‘. Dabei ist modernes SEO das genaue Gegenteil! Ein gut optimierter Shop ist schneller, benutzerfreundlicher und technisch sauberer. Das Problem ist die Ausbildung. In den meisten Coding-Bootcamps wird SEO mit keinem Wort erwähnt. Die Leute lernen React, Node, Docker – aber nicht, wie Suchmaschinen funktionieren. Das rächt sich später bitter. Wir haben jetzt einen festen SEO-Consultant, der bei JEDEM Shop-Projekt von Anfang an dabei ist. Kostet mehr? Ja. Spart es langfristig Geld? Absolut!
Faceted Navigation Horror Story: 50.000 Filter-Kombinationen = 50.000 URLs = Crawling Chaos. Danke für nichts, lieber Entwickler.
Was auch immer vergessen wird: Mobile First! Unser Entwickler hat den Shop perfekt für Desktop optimiert. Mobile? ‚Das machen wir später.‘ Google indexiert aber Mobile First! Die Rankings sind komplett abgestürzt, weil die mobile Version grauenhaft war. Keine responsive Bilder, horizontales Scrolling, winzige Buttons. Ein Albtraum!
Kurz und knapp: Nach Shop-Relaunch 70% Umsatz verloren. Entwickler hatte alle /produkt/ URLs auf /p/ gekürzt. ‚Ist doch besser so!‘ Nein, ist es nicht.
Structured Data nicht vergessen! Unser Dev kannte nur Schema für Artikel, nicht für Produkte. Rich Snippets = Fehlanzeige.
Der Artikel spricht mir aus der Seele! Ich bin seit 15 Jahren im E-Commerce und habe schon alles erlebt. Das krasseste war ein Entwickler, der meinte, er hätte eine ‚geniale SEO-Innovation‘ entwickelt. Seine Idee: Alle Produkttexte dynamisch per JavaScript generieren lassen, basierend auf Keywords. Das Problem? Google konnte NICHTS davon lesen! Der ganze Content war client-seitig gerendert, ohne SSR, ohne Fallback. 8.000 Produktseiten, komplett unsichtbar für Suchmaschinen. Als ich ihm das erklärt habe, war seine Antwort: ‚Aber Google kann doch JavaScript!‘ – Ja, KANN, aber nicht immer und nicht sofort! Wir haben 6 Monate gebraucht, um das wieder hinzubiegen. Seitdem bestehe ich darauf, dass bei jedem Shop-Projekt ein SEO-Experte von Tag 1 dabei ist. Anders geht es einfach nicht.
Kann ich bestätigen. Unser Entwickler: ‚SEO macht man doch mit Google Ads!‘ 🤯
Das mit dem Crawl-Budget hatte ich auch noch nie gehört. Erklärt aber, warum Google bei unserem Shop mit 50k Produkten nur 10% indexiert hat…
Ich bin Shop-Betreiberin und SEO-Enthusiastin. Was mich am meisten nervt: Entwickler, die denken, ein schneller Shop reicht für gute Rankings. Ja, Speed ist EIN Faktor von über 200! Was bringt mir ein Shop, der in 0,5 Sekunden lädt, aber keine vernünftigen Title-Tags hat, keine interne Verlinkung, keine strukturierten Daten? Wir haben letztes Jahr einen Entwickler gehabt, der war super proud auf seine Core Web Vitals. Alles grün! Nur: Er hatte vergessen, die XML-Sitemap einzurichten, die robots.txt war falsch konfiguriert, und die Breadcrumb-Navigation hat er ‚aus Performance-Gründen‘ weggelassen. Ich musste ihm erstmal erklären, dass Breadcrumbs nicht nur für User wichtig sind, sondern auch für Google! Sein Kommentar: ‚Ach, das wusste ich nicht.‘ – Ja, genau das ist das Problem! Entwickler müssen endlich verstehen, dass SEO kein nice-to-have ist, sondern essentiell für den Erfolg eines Online-Shops. Ohne Sichtbarkeit keine Kunden, ohne Kunden kein Umsatz. So einfach ist das.
Paginierung ist auch so ein Thema! Unser Dev hatte bei Kategorieseiten einfach alle Seiten auf noindex gesetzt, außer Seite 1. Resultat: 500+ Produkte nicht mehr auffindbar.
Wir hatten mal einen Entwickler, der meinte, robots.txt sei ‚Sicherheitsrisiko‘ und hat einfach alles auf Disallow gestellt. Nach 2 Wochen waren wir komplett aus Google verschwunden. True Story! Als wir ihn darauf angesprochen haben, meinte er nur ‚Aber der Shop ist doch trotzdem erreichbar?‘ – Ja klar, nur findet ihn halt keiner mehr! Das Schlimmste: Er hat bis heute nicht verstanden, was das Problem war. Manche Entwickler leben echt in ihrer eigenen Bubble.
True Story: Entwickler baut mega geilen Shop. Alle Produktbilder über Lazy Loading. Problem: Auch die Above-the-fold Bilder. LCP im Keller. Rankings weg. 🤦♂️
Super Artikel! Besonders der Part über die URL-Struktur hat mich angesprochen. Unser Entwickler hatte alle Kategorien in kryptische IDs umgewandelt (/cat/12345 statt /herrenschuhe/). Hat Monate gedauert, bis wir das wieder hinbekommen haben.
Kann die Kritik verstehen, aber als Entwickler muss ich auch sagen: Viele Kunden wollen einfach nicht für SEO zahlen. ‚Macht erstmal den Shop fertig, SEO machen wir später‘ höre ich ständig. Dann wundern sie sich, wenn später teurer wird.
Interessanter Punkt mit den JavaScript-Frameworks! Wir nutzen Vue.js und hatten massive Probleme mit der Indexierung. Google konnte unsere Produktseiten teilweise gar nicht crawlen. Die Lösung war Server-Side-Rendering, aber das hat nochmal 3 Monate Entwicklung gekostet. Hätte man vorher wissen können…
Bei uns war es noch schlimmer: Shop-Relaunch im Januar, bis März 80% Traffic-Verlust, im April Insolvenz angemeldet. Kein Witz.
Ich arbeite selbst als Entwicklerin und muss leider zugeben: Der Artikel trifft ins Schwarze. In meiner Ausbildung kam SEO genau NULL vor. Wir haben gelernt, wie man performante, sichere und schöne Shops baut – aber niemand hat uns erklärt, wie Google eigentlich funktioniert. Das Problem ist systemisch: Die meisten Entwickler-Bootcamps und Studiengänge behandeln SEO als ‚Marketing-Thema‘, nicht als technische Anforderung. Dabei ist technisches SEO zu 80% Entwickler-Arbeit! Canonical-Tags, strukturierte Daten, Core Web Vitals, Crawl-Budget-Optimierung – das sind alles Entwickler-Themen. Ich habe mir das Wissen erst nach 3 Jahren Berufserfahrung selbst angeeignet, nachdem ich gemerkt habe, wie viele Kunden-Shops ich unbewusst ‚kaputt optimiert‘ hatte. Mein Vorschlag: SEO sollte Pflichtbestandteil jeder Webentwickler-Ausbildung sein!
DANKE für diesen Artikel! Schicke ich direkt an unseren Entwickler weiter 😅
Das Problem kenne ich nur zu gut. Die meisten Entwickler denken tatsächlich, dass ein schneller Shop automatisch gut für SEO ist. Dabei vergessen sie die Basics.
Endlich spricht es mal jemand aus! Wir haben letztes Jahr unseren Shop relaunchen lassen – 45.000€ Budget, tolle Agentur aus Hamburg. Der Shop sieht MEGA aus, läuft butterweich, super UX. Aber: Nach 3 Monaten waren 60% unserer Rankings weg! Die Entwickler hatten einfach alle URLs geändert, keine Weiterleitungen eingerichtet, Meta-Descriptions gelöscht und die ganze Seitenstruktur über den Haufen geworfen. Mussten dann nochmal 15k für SEO-Recovery ausgeben. Mein Learning: NIEMALS wieder einen Shop ohne SEO-Begleitung entwickeln lassen!