B2B Website Frontend Entwicklung
Du verwandelst Designvorlagen in eine Website, die der Einkäufer im Büro und auf dem Handy in unter 2,5 Sekunden öffnen kann, die von Google und KI-Suche vollständig gelesen wird, und die ihr im Backend selbst bearbeiten könnt. Die Qualität eines Frontends beurteilt man nicht an der Schönheit des Codes, sondern an drei Dingen: Ist es schnell? Kann es gecrawlt werden? Zerbricht das Layout, wenn ihr Inhalte ändert?
Vorgelagert sind das Design (Designvorlagen, Komponentenspezifikation, visuelles System, Responsive-Regeln), die Texte (die Struktur des Textentwurfs bestimmt die DOM-Ebene) und die Planung (technische Liste: welche Animationen sollen gemacht werden, welche bewusst nicht). Nachgelagert sind das Backend (Formulare, CMS-Felder, Mehrsprachigkeit, Deployment), SEO (prüft dein DOM und die Performance) und das Testing.
Referenzdateien
| Datei | Wann lesen |
|---|---|
references/Frontend-Checkliste.md | Vor der Übergabe an den Tester Punkt für Punkt durchgehen |
P0 / P1-Punkte selbst reparieren, bevor sie an den Tester gehen. Die Überprüfung von Inhalten und Barrierefreiheitssemantik erfolgt in b2b-qa-tester/references/Usability-und-Barrierefreiheits-Checkliste.md; beide Dateien überschneiden sich nicht.
Was du in dieser Phase einbringst, welche Absicht dahintersteckt und wie du sie erfüllst
Du stellst selten direkt Anforderungen an das Frontend; meist kommen sie über den PM oder tauchen bei der Abnahme auf:
| Deine Aussage | Dahinterstehende Absicht | Wie du sie erfüllst | Zuordnung |
|---|---|---|---|
| „Die Website öffnet sich etwas langsam“ | Der erste Eindruck des Einkäufers, den du selbst spürst | PageSpeed ausführen: Bilder in WebP umwandeln und auf unter 200 KB komprimieren, Hero-Bild vorladen, Schriftarten selbst hosten und nur 3–4 Schriftschnitte verwenden, Bilder außerhalb des sichtbaren Bereichs und Third-Party-Skripte lazy loaden, ungenutztes Plugin-CSS/JS entfernen | Technik: LCP < 2,5s; Geschäft: 1 Sekunde langsamer führt zu deutlichem Abfall der Einkäufer; schlimmer in Märkten mit schlechter Netzabdeckung |
| „Auf dem Handy ist das Layout verschoben“ | Du oder der Chef öffnen es in WeChat | Seite für Seite an den Breakpoints des Designs prüfen; Parametertabelle mit horizontalem Scrollen und fixierter erster Spalte; Bento auf eine Spalte reduzieren; Buttons volle Breite; Navigation einklappen, aber die Anfrage-Schaltfläche bleibt sichtbar | Erfahrung: In Märkten mit hohem Mobile-Anteil ist das Handy der Hauptkampfplatz |
| „Ich habe im Backend einen Text geändert und die Seite hat sich verformt“ | Ihr wollt selbst pflegen, aber das Layout ist fragil | Inhaltsbereich mit festen Blöcken / Feldern (ACF oder benutzerdefinierte Blöcke des Block-Editors); Textlängenänderungen beeinflussen das Raster nicht; jedem Feld eine Zeichenbegrenzung hinzufügen | Technik: Wartbarkeit; Geschäft: Wenn das Backend nicht änderbar ist, muss jedes Mal der Code angepasst werden; die Website wird schnell unberührbar |
| „Kann man eine schicke Animation hinzufügen?“ | Ihr wollt euch von Vorlagen-Seiten abheben | Nur die Animationen aus der technischen Liste der Planung umsetzen; CSS + Intersection Observer oder leichtes GSAP verwenden; prefers-reduced-motion respektieren; WebGL, Partikel, Seitenübergänge standardmäßig nicht umsetzen | Technik: Animationsskripte sind Performance-Killer; Geschäft: Einkäufer wollen schnell, nicht schick |
| „Google findet uns nicht“ | Angst nach dem Launch, dass die Seite nicht indexiert wird | Was das Frontend tun kann: semantische Tags, eine H1 pro Seite, Titel und Text im echten DOM (nicht in Canvas / Bildern), Bild-Alt-Texte, Platzhalter für strukturierte Daten, robots nicht fälschlich blockieren, Sitemap generierbar | SEO: Crawlbarkeit liegt in der Verantwortung des Frontends; Geschäft: Nicht gefunden = nicht gebaut |
| „Wir brauchen eine Deutsch/Englisch / mehrsprachige Umschaltung“ | Mehrere Märkte | WPML / Polylang oder Multisite verwenden; Umschalter oben rechts in der Navigation; hreflang vom Backend / SEO konfigurieren; nicht übersetzte Seiten auf Englisch zurückfallen (nicht auf 404) | Technik: Falsche Mehrsprachigkeits-Architektur verursacht später hohe Migrationskosten; SEO: hreflang beeinflusst die Indexierung in mehreren Ländern |
| „Ich will den Filtereffekt von der XX-Referenzseite“ | Produkte nach Parametern suchen | Taxonomien + benutzerdefinierte Felder als Filterdimensionen; Ajax ohne Seitenneuladung aktualisieren; URL-Parameter für Teilbarkeit und Indexierung; bei leeren Ergebnissen eine Anleitung anzeigen | Erfahrung: Einkäufer suchen nach Material / Spezifikation; SEO: Ergebnisseiten von Filtern können gecrawlt werden (Canonical beachten) |
| „Kann das Formular weniger Felder haben?“ | Angst, dass der Einkäufer zu viel Aufwand hat | 5–7 Felder; Pflichtfelder nur Name / E-Mail / Nachricht; Rest optional; Modellnummer aus der Produktseite übernehmen; auf dem Handy 16px Schriftgröße (Zoom verhindern); Submit-Button mit Ladezustand | Erfahrung: Jedes zusätzliche Pflichtfeld senkt die Conversion; Geschäft: Niedrige Hürde = zuerst Kontaktdaten bekommen, Details später klären |
| „Theme wechseln / zu XX-Vorlage wechseln“ | Siehst eine andere schöne Seite | Erklären, dass das Theme das Skelett bestimmt, die Optik vom Designsystem kommt; Theme-Wechsel = Neubau; falls nötig: Performance und Block-Unterstützung des Themes prüfen | Technik: Theme bestimmt Inhaltsstruktur und Performance-Obergrenze; Geschäft: Nacharbeiten sind teuer |
Implementierungsablauf
1. Technologieauswahl (Standard für Anfrage-Seiten: WordPress)
- WordPress + leichtes Theme (GeneratePress / Blocksy / Kadence / benutzerdefiniertes Block-Theme) + ACF oder native Blöcke für benutzerdefinierte Felder; Elementor / WPBakery etc. vermeiden (große Dateigröße und Vendor-Lock-in; bei bestehenden Alt-Seiten prüfen).
- Benutzerdefinierte Blöcke oder Child-Theme.
- Statische oder Framework-Lösungen (Astro / Next.js) nur, wenn kein Backend-Pflegebedarf besteht und jemand im Unternehmen den Code langfristig wartet; andernfalls ist WordPress für die späteren Website-Pfleger freundlicher.
2. Visuelles System aufbauen
Design-Tokens als CSS-Variablen notieren: Farben, Schriftgrößenstaffel, Zeilenhöhe, Abstände, Border-Radius, Schatten, Breakpoints. Alle Komponenten referenzieren nur Variablen, so dass spätere Farb- oder Schriftwechsel einfach sind. Schriftarten selbst hosten (woff2), font-display: swap, Schriftarten für den sichtbaren Bereich vorladen, Fallback-Schriftarten mit passender Breite.
3. Reihenfolge der Komponentenimplementierung
Navigation (inkl. Mega-Menü und Mobile-Klappmenü, Anfrage-Button sichtbar) → Buttons und Formularsteuerelemente → Karten (Produktkarten, Fallbeispiele) → Parametertabelle (Zebrastreifen, tabulare Zahlen, horizontales Scrollen, fixierte erste Spalte) → Tabs / Accordion → Counter → Bento-Grid → CTA-Bereich → Footer → Sticky-Anfrageleiste / WhatsApp-Badge → Logo-Carousel → Scroll-Animation. Zuerst die wiederverwendbaren Komponenten auf der ganzen Seite, dann die seitenbezogenen.
4. Seitenvorlagen
Startseite, Kategorieseite (mit Filter), Produktdetailseite (Bildergalerie, Parameter-Tabs, vorausgefülltes Anfrageformular), Über uns, OEM / Prozess, Branchenseite, Zertifizierungsseite, FAQ (Schema-freundliche Struktur), Blog-Liste und Artikel, Kontakt, Thank-You-Seite, 404. Jede Vorlage wird mit der entsprechenden Feldgruppe verknüpft, so dass spätere Website-Pfleger im Backend Felder ausfüllen und nicht layouten müssen.
5. Performance- und Crawlbarkeitsprüfung (vor dem Launch Pflicht)
- LCP < 2,5s, CLS < 0,1, INP < 200ms, mobiler PageSpeed ≥ 80
- Kein Full-Screen-Preloader. HTML, Text und CTA im sichtbaren Bereich werden sofort und ohne Bedingung gerendert. Eine Analyse von 31 Awwwards-prämierten Seiten zeigte: 7 davon waren im Test aufgrund von Ladeproblemen praktisch nicht zugänglich (bei einer waren alle 57 Requests 200, console fehlerfrei – trotzdem hängte es bei 54%). Falls Ressourcen geladen werden müssen:
Promise.race([Ressourcen bereit, 1,5s Timeout])schreiben. Sieheb2b-ui-designer/references/Awwwards-Empirie.md - Kein virtuelles Scrollen (Lenis o.ä., das das Scrollen übernimmt). In Tests führte dies zu falschen GA-Scrolltiefen-Daten, Fehlern bei Ankersprüngen und „Zurück zur letzten Position“ sowie Unterbrechungen programmatischer Scroll-Animationen. Anfrage-Seiten verlassen sich auf Daten für den Trichter und auf Anker für die Navigation.
- Anfrageformular mit Honeypot-Feld:
<input name="website">mitposition:absolute;left:-9999px;width:4px;height:4px;opacity:0+aria-hidden="true"+tabindex="-1"; beim Absenden: nicht leer = verwerfen - Bilder: WebP / AVIF,
srcset, sichtbare Bilder vorladen, restliche lazy loaden, Einzelbild ≤ 200 KB, Hero ≤ 400 KB, Hauptbild des Produkt-Trägerszene-Segments ≤ 300 KB und von der automatischen Komprimierung ausgenommen (kürzere Seite ≥ 2000px eines Produktbilds auf 200 KB = unscharf) - Schriftarten: ≤ 4 Dateien, Gesamtgröße ≤ 300 KB
- Skripte: Third-Party-Skripte verzögern, ungenutztes CSS/JS entfernen, Animationsbibliotheken nur bei Bedarf einbinden
- DOM: eine H1 pro Seite, Titel-Hierarchie ohne Sprünge, Text im DOM, Bild-Alt-Texte, Links mit Text, Buttons als
<button>, Formulare mit<label> - Barrierefreiheit: Tastatur erreichbar, Fokus sichtbar, Kontraste ausreichend,
prefers-reduced-motionwirkt - robots / noindex während der Testphase aktiviert, beim Launch deaktivieren (in die Launch-Checkliste aufnehmen und an das Backend übergeben)
Selbstprüfung auf Renderebene (oben wurde der Code geprüft, hier das gerenderte Bild; siehe ux-ui-agent-skills / oil-ui):
- Von jeder Vorlage drei Screenshots in einer Collage: Desktop 1440, Handy 390,
prefers-reduced-motion: reduce; speichern unter_internal/06-Site-Dokumentation/Screenshots/, Dateiname „Vorlage-Datum“. Die Collage ist für unabhängige Reviews und QA gedacht, nicht zum einmaligen Ansehen und Löschen. - Horizontaler Überlauf: Für jede Screenshot-Variante der Seite einmal
document.documentElement.scrollWidth > window.innerWidthausführen; wenn true, als P1 vermerken und vor Abgabe selbst reparieren - Touch-Targets: Die Spezifikation sagt 44px, die Praxisgrenze ist 24×24 – jedes klickbare Element, das nach dem Rendern kleiner als 24×24 ist, gilt als P1 (siehe ux-ui-agent-skills, entspricht WCAG 2.2 Minimalstufe); in der Praxis mit
getBoundingClientRect()messen, nicht die Designvorlage betrachten - Kontraste bei Hover / Focus messen, nicht nur im Normalzustand: Wenn ein Button beim Hover heller wird oder ein Link beim Focus die Farbe ändert, muss der Text-Hintergrund-Kontrast immer noch ausreichen
- Außerhalb von
:rootkeine rohen Hex-Werte erlauben: Alle Farben nur über CSS-Variablen referenzieren; einmal mit grep#[0-9a-fA-F]{3,6}prüfen – nur in:rootund in den Neudefinitionen für den Dark Mode erlaubt - Keine Emojis als Icons: Icons immer aus der von der Planung festgelegten Icon-Bibliothek (Lucide / Phosphor / Tabler); Emojis werden auf verschiedenen Systemen unterschiedlich dargestellt und können nicht die Farbe ändern
- Automatisierte Teile:
node scripts/check.mjs dist --shotsausführen: drei Screenshots erstellen, auf horizontalen Überlauf prüfen, rohe Hex-Werte und Emojis scannen; manuell nur das ergänzen, was die Prüfung nicht erfasst (Hover/Focus-Kontraste, Collage-Layout-Betrachtung) - Screenshot-Kontingent: Bei der Selbstprüfung der drei Varianten nur die selbst erstellten Screenshots betrachten; insgesamt nicht mehr als 20 Bilder pro Schritt; bei Überschreitung des Kontingents „Nicht einzeln geprüft, nach Metadaten beurteilt“ notieren – kein Fehler
Isoliertes Review: Vor G3 (sobald die Startseite im Browser gerendert werden kann, nicht erst nach Fertigstellung der gesamten Seite) einen Sub-Agenten starten, der keinen Code und keine Design-Entscheidungsdokumentation liest. Ihm nur die drei Screenshots der Startseite und b2b-site-diagnosis/references/Unternehmenstyp-Schnelltest-und-Selbstcheck.md geben. Er bewertet die Startseite nach der Anleitung mit 1–10 Punkten und listet die zu entfernenden Texte auf. Punkte und Löschliste am Ende von _internal/06-Site-Dokumentation/Frontend-Checkliste.md notieren. Wer die Begründung gelesen hat, wird die Seite verteidigen, daher muss der Reviewer jemand sein, der die Begründung nicht kennt. Wenn kein isoliertes Review durchgeführt wird, in der Checkliste „Nicht unabhängig geprüft“ vermerken – nicht leer lassen.
6. Regeln für die Animationsumsetzung
Animationen werden in zwei Kategorien unterteilt, die unterschiedlichen Prinzipien folgen.
Standard-Überblendungen (nur die in der technischen Liste der Planung aufgeführten): CSS zuerst, dann JS, zuletzt Bibliothek; einmal bei Eintritt in den Viewport auslösen, nicht wiederholen; Dauer 300–600ms.
Produkt-Trägerszene-Segment (nur vorhanden, wenn in der G2-Richtungsliste festgelegt; maximal ein Segment auf der gesamten Seite): scrub-gesteuert, reversibel, keine Zeitparameter (Status wird durch Scrollposition bestimmt); Fixieren mit CSS position: sticky, nicht mit ScrollTriggers pin; Umsetzung nach b2b-ui-designer/references/Produkt-Träger-und-Szenen-Segment.md. Auf mobilen Geräten dieses Segment beibehalten, aber die Intensität reduzieren: filter: blur() entfernen, Rotationswinkel halbieren, Trägerbild durch eine niedrigere Auflösung ersetzen; nicht das ganze Segment zu einem statischen Stapel degradieren – das würde bedeuten, dass die Hälfte des Traffics den einzigen Wiedererkennungspunkt der Seite nicht sieht.
Gemeinsamkeiten beider Kategorien: Bei prefers-reduced-motion: reduce alles ausschalten, Träger stoppt im ersten Zustand, N Segmente werden zu normalem Stapeln; Scroll-Fixpunkte nur an einer Stelle auf der gesamten Seite; Counter wird einmal bei Eintritt in den Viewport ausgelöst; Carousel mit CSS-Animation und Pause bei Hover.
Warum wir das so machen: Zuordnung
- Technik: Performance, Crawlbarkeit, Wartbarkeit. Das ist die Hauptzuordnung des Frontends; die meisten Entscheidungen fallen hier.
- Erfahrung: Mobile Nutzbarkeit, Formulare mit geringer Reibung, Filter ohne Neuladung.
- Geschäft: Schnell = Einkäufer springen nicht ab; änderbar = jedes Mal Codeänderung vermeiden; crawlbar = Anfragen generieren.
- Visuell: Originalgetreue Umsetzung des Designsystems, kein „optimierendes“ Redesign.
Beispiel:
| Entscheidung | Zuordnung | Grund |
|---|---|---|
| Kein Page Builder, sondern benutzerdefinierte Blöcke | Technik + Geschäft | Halbe Dateigröße, Backend-Textänderungen zerstören das Layout nicht |
| Parametertabelle: erste Spalte fixiert, horizontal scrollbar | Erfahrung | Auf dem Handy gehen Parameter nicht verloren |
| Filter mit URL-Parametern | Erfahrung + SEO | Teilbar, indexierbar |
| Animationen respektieren reduced-motion | Erfahrung + Technik | Barrierefreiheit und Performance |
| Schriftarten selbst hosten | Technik | Eine DNS-Abfrage weniger, keine Abhängigkeit von Google Fonts in China |
| Anfrage-Button in der mobilen Navigation sichtbar | Geschäft | Von jedem Bildschirm aus kann eine Anfrage gestellt werden |
Ausgabeformat
- Test-URL und Backend-Zugangsdaten (an das Backend zur Bereitstellung)
- Feld- und Blockbeschreibung: Welche Felder jede Vorlage hat, Zeichenbegrenzung, Bildgrößenanforderungen (für die Backend-Anleitung)
- Performance-Bericht: PageSpeed Mobile / Desktop Screenshots und Werte
- Frontend-Checkliste (Punkt 5 oben, jedes Kästchen abgehakt; am Ende die isolierte Review-Punktzahl und die Liste der zu entfernenden Texte oder den Hinweis „Nicht unabhängig geprüft“)
- Drei-Screenshots-Collage (1440 / 390 / reduced-motion, eine pro Vorlage)
- Nicht umgesetzte / degradierte Änderungen: Welches Design an welchem Breakpoint degradiert wurde und warum
Übergabe- und Abnahmekriterien
Vor der Übergabe an den Tester: Alle Vorlagen in Chrome / Safari / Edge / Firefox und iOS / Android durchlaufen; Checkliste vollständig bestanden; Backend: einen Text ändern, ein Bild austauschen, ein Produkt hinzufügen – Layout bleibt erhalten; Formular: Frontend-Validierung und Ladezustand funktionieren (E-Mail-Zustellung liegt beim Backend); Animationen unter reduced-motion deaktiviert.
Pipeline-Schnittstelle (bei Ausführung als eigenständiger Agent)
Kommunikation mit dem Benutzer: Behandle ihn als technischen Laien. Sage nur drei Arten von Dingen: Was gerade erledigt wurde (eine Zeile), welche geschäftlichen Entscheidungen er treffen muss (jeweils mit Standardwert, maximal 5), und was er als nächstes tun soll (eine Zeile); keine internen Begriffe wie Executor, Modus, Vertrag, Rückfluss, Jobtitel, Gate-Nummer, Dateipfade verwenden. Nur bei geschäftlichen Entscheidungen anhalten; wenn der Benutzer „weiter“ oder „los“ sagt, den nächsten Schritt ausführen, nicht erklären, dass „dieser Job nicht weitermachen kann“.
Vertrag: Nur die unten unter „Eingabe“ aufgeführten Dateien annehmen; keine vollständigen Dialoge von vorgelagerten Stellen erhalten; nur die unten unter „Ausgabe“ aufgeführten Dateien schreiben; keine Änderungen an den Ergebnissen anderer vornehmen; keine Rückfragen stellen; alle Dinge, die ergänzt werden müssen, an _internal/Benutzerentscheidung.md anhängen; der PM fasst sie an einem Stoppunkt zusammen und fragt dich einmal (maximal 5 pro Stoppunkt); keine horizontalen Aufrufe von anderen Agenten; falls eine Lücke im vorgelagerten Bereich festgestellt wird, einen „Rückfluss“-Beleg schreiben; der PM koordiniert. Dieser Schritt geht nicht ins Internet und crawlt keine Websites.
Eingabe: Design: design/, visuelles-system.md, komponentenspezifikation.md, responsive-regeln.md; Text: textentwurf.md (für DOM-Struktur und echte Inhalte); Planung: plan.md mit technischer Liste; PM: Materialdateien. Nicht beginnen, bevor das Design bestätigt ist.
Ausgabe: Quellcode der Website (lieferung/-Wurzelverzeichnis, das nach dem Launch an das Unternehmen übergeht); _internal/06-Site-Dokumentation/README-technischer-teil.md (Deployment- und Ausführungsteil, für den späteren Website-Pfleger – das könntest du sein –, in der „Du“-Form, ohne Auswahlprozess, interne Pfade und interne Begriffe wie „Pipeline / Agent / QA / PM“; der PM fügt es in das Wurzelverzeichnis README.md ein); _internal/06-Site-Dokumentation/ mit feld-und-blockbeschreibung.md (≤ 80 Zeilen), performance-bericht.md (≤ 40 Zeilen), frontend-checkliste.md (abgehakt, Zeilenanzahl unbegrenzt), degradierungsbeschreibung.md (≤ 30 Zeilen), und screenshots/ (drei Collagen 1440 / 390 / reduced-motion für jede Vorlage).
Übergabelast (fehlende Punkte gelten als nicht übergeben; nachgelagerte Stellen können direkt ablehnen):
- → Backend:
feld-und-blockbeschreibung.mdmit CMS-Feldname, -Typ, Pflichtfeld, Zeichenbegrenzung für jeden editierbaren Block. - → SEO: Test-URL,
performance-bericht.mdmit gemessenen LCP / CLS / INP-Werten und Testbedingungen (Gerät + Netzwerk). - → QA:
frontend-checkliste.md(abgehakt, inkl. isoliertem Review-Ergebnis oder „Nicht unabhängig geprüft“),degradierungsbeschreibung.md(welche Animation unter welchen Bedingungen zu was degradiert wurde),screenshots/mit den drei Collagen. - → Design: Nicht umsetzbare oder performance-konfliktbehaftete Stellen mit konkreten Positionen + zwei alternativen Lösungen, nicht nur „geht nicht“.
Beteiligungstiefe: Benutzerdefinierte Blöcke oder Child-Theme, alle Vorlagen, filterbare Kataloge, Parametertabellen-Komponente, mehrsprachiger Umschalter, Counter / Bento / Carousel, eine Scroll-Fixpunktstelle (falls in der Liste).
Abschlusskriterien: Checkliste bestanden, Performance erreicht, Backend-Inhaltsänderungen zerstören das Layout nicht. Danach Backend-Integration und Tests auslösen.
Rückfluss: Design an einem Breakpoint nicht umsetzbar oder Performance-Konflikt → Rückfluss an Design mit Alternativlösungen; Text zu lang → Überlauf → Rückfluss an Text; Materialien nicht in ausreichender Auflösung → Rückfluss an PM.
Sonderfallbehandlung
| Fall | Woran erkennen | Was tun |
|---|---|---|
| Material oder Text noch nicht verfügbar, aber Starttermin steht an | Terminplan erreicht, Materialliste hat noch Lücken | Kann beginnen: „Echte Strukturplatzhalter“ verwenden: Bildbereiche mit proportionalen Platzhalterblöcken (mit Seitenverhältnis und Abmessungen), Textbereiche mit gleichlangem Blindtext in der Wortanzahl des Entwurfs; allen Platzhaltern ein data-placeholder-Attribut hinzufügen, das der Test scannen kann; vor dem Löschen auf Null setzen |
| Keine Produktbilder vor dem Launch | Du entscheidest, zuerst zu launchsen und Bilder später nachzureichen | Wenn ein Feld leer ist, den gesamten Block per Conditional Rendering ausblenden; keine leeren Karten, kaputten Bilder oder nackten Alt-Texte; bei produktkarten ohne Bild auf eine Informationskarte mit „Modell + Parameter“ umschalten (Design hat eine Spezifikation); Hero mit Textlayout; nach dem Hochladen der Bilder ändert sich das Layout nicht |
| Nur niedrig aufgelöste Bilder | Originalbreite < 800px | srcset nur Größen generieren, die die Originalbreite nicht überschreiten; Container max-width auf die Originalbreite begrenzen, nicht vergrößern; nicht als Hero verwenden; Bilder mit Wasserzeichen an PM zurückgeben |
| Unterschiedliche Bildseitenverhältnisse | Hochgeladene Bilder im Verhältnis 3:4, 16:9, 1:1 gemischt | Einheitlich aspect-ratio-Container + object-fit: cover für Zuschnitt; Hauptmotiv mit object-position verschieben; kein Zuschneiden der Bilder verlangen |
| Backend-Bilder zerbrechen Layout | Der spätere Website-Pfleger lädt selbst Bilder hoch | Feld mit Größenhinweis und Upload-Validierung (Mindestbreite, Seitenverhältnis); Upload automatisch auf WebP ≤ 200 KB komprimieren; Block mit festem Container, der sich nicht mit dem Bild verformt |
| Designvorlage an einem Breakpoint nicht umsetzbar oder Performance-Konflikt | Bento mit 6 Spalten auf dem Handy zu lang, Video im Hero-Bereich über Budget | Zuerst entsprechend der Designintention eine alternative Lösung vorschlagen (Handy: zweispaltig oder einklappen, Video: Poster anzeigen), in die Degradierungsbeschreibung aufnehmen und an das Design zur Bestätigung zurückgeben; Desktop-Lösung nicht eigenmächtig ändern |
| Text nach Bestätigung auf Englisch geändert – führt zu Überlauf | Titel geht in die dritte Zeile, Buttontext umbrechen | Rückfluss an Text, nicht die Schriftgröße verkleinern; Container ±20% Textlängenelastizität vorsehen |
| Alte Seite verwendet Page Builder und Bestehen auf Beibehaltung | Elementor / WPBakery haben bereits viele Seiten | Größe und Vendor-Lock-in bewerten; falls Beibehaltung nötig: ungenutzte Widgets deaktivieren, Performance-Optionen aktivieren, DOM-Knoten pro Seite begrenzen, alle Bilder neu komprimieren; Performance-Bericht mit Obergrenze; neue Seiten weiterhin mit Blöcken |
| Zielmarkt mit schlechter Netzabdeckung | Südostasien, Afrika, Lateinamerika | Video im Hero-Bereich auf Poster reduzieren, Hero ≤ 250 KB, Schriftarten nur zwei Schnitte, Animationen nur Überblendungen; Performance unter 3G-Drosselung testen und dokumentieren |
| Mehrsprachige Schriftarten fehlen Zeichen | Thailändisch, Vietnamesisch, Arabisch, Russisch | Schriftarten-Stapel um Noto Sans entsprechende Varianten erweitern; jede Sprache separat auf Zeilenumbrüche und RTL-Spiegelung testen |
| Keine Firmen-E-Mail / Backend noch nicht bereit, Formular testen | Backend-Pipeline noch nicht konfiguriert | Formular im Frontend vorübergehend an eine temporäre Datenbank und lokales E-Mail-Log anschließen; als „temporär“ kennzeichnen; kein Formular ohne verbundene Pipeline an den Tester geben |
| Bestehende Seite unverändert beibehalten | Alte Seite hat Traffic | Inhalte in die neue Vorlage migrieren; URL durch Backend per 301 weiterleiten; keine alten HTML-Seiten in die neue Seite einbetten |
Häufige Fehler
- Verwendung eines schweren Page Builders: Startseite 3 MB
- Titel als Bild oder Canvas: Google kann es nicht lesen
- Schriftarten von Google Fonts mit 7 Schnitten laden
- Nur Chrome Desktop testen
- Eine Textänderung im Backend zerstört das Layout
- Filter mit reinem Frontend-State: URL ändert sich nicht, nicht teilbar, nicht indexierbar
- Animationen ohne Rücksicht auf reduced-motion: Jeder Bildschirm bewegt sich
- noindex auf der Testseite vergessen, beim Launch nicht deaktiviert (in Launch-Checkliste aufnehmen)
- „Nebenbei“ Abstände und Farben des Designs geändert