Knowledge Base — Web-Performance, DSGVO, WCAG & SEOKnowledge Base — Web Performance, GDPR, WCAG & SEO

Wenn ein Audit über WebPageTest (WPT) gemessen wurde, liegen die Lighthouse-Werte oft deutlich unter denen von PageSpeed Insights (PSI). Beide Werkzeuge nutzen Lighthouse, messen aber unter verschiedenen Bedingungen. Beispiel: fepo.app am 23.10.2026 – Performance 86 bei WebPageTest, 99 bei PageSpeed Insights.

• Gerät: Beide emulieren ein Smartphone, keines misst auf einem echten Handy. WPT emuliert ein Moto G Power (Bildschirmgröße, Pixeldichte, Kennung) auf einem Linux-Rechner; die öffentliche WPT-Standortliste enthält keine echten Geräte.
• CPU-Bremse: PSI zeigt in seinen Berichten „CPU throttling: 1.2x slowdown (Simulated)“; laut Googles Release Notes (Dezember 2024) wurde die Drosselung an die langsamen CPUs der PSI-Messserver angepasst (eine Zahl nennt Google dazu nicht, die 1,2× stammen aus den PSI-Berichten). Der allgemeine Lighthouse-Standard von 4× gilt für PSI nicht. WPT bremst deutlich stärker, in einem fepo-Lauf 15-fach; der Faktor hängt vom jeweiligen WPT-Testrechner ab. Das trifft vor allem Seiten mit viel JavaScript und aufwendigem Rendering (TBT, LCP).
• Netzwerk: PSI simuliert die Drosselung rechnerisch. WPT lädt die Seite über eine echte, auf ein 4G-Profil gebremste Verbindung vom gewählten Standort (Standard: Frankfurt).
• Lighthouse-Version: WPT nutzt eine ältere Version (11.x), PSI eine aktuelle. Neuere Techniken erkennt die ältere Version teils nicht. Beispiel: Die Kompression zstd kennt Lighthouse 11 nicht und meldet fälschlich „Textkomprimierung aktivieren“. fepo gleicht solche Treffer mit den tatsächlichen Antwort-Headern ab und entfernt sie aus dem Bericht.

• Die strengeren WPT-Werte zeigen, wo auf langsamen Smartphones Rendering oder JavaScript bremsen.
• Vergleichen Sie Läufe nur untereinander, wenn sie vom selben Messort stammen; WPT-Werte und PSI-Werte sind nicht direkt vergleichbar.
• Echte Gerätedaten liefern nur Felddaten (CrUX: echte Chrome-Nutzer, letzte 28 Tage). Der fepo-Bericht zeigt sie, sofern Google für die Seite genug Daten hat.

When an audit was measured via WebPageTest (WPT), the Lighthouse scores are often clearly below those of PageSpeed Insights (PSI). Both tools use Lighthouse but measure under different conditions. Example: fepo.app on 23 October 2026 – performance 86 on WebPageTest, 99 on PageSpeed Insights.

• Device: Both emulate a smartphone; neither measures on a real phone. WPT emulates a Moto G Power (screen size, pixel density, user agent) on a Linux machine; the public WPT location list contains no real devices.
• CPU throttling: PSI reports show “CPU throttling: 1.2x slowdown (Simulated)”; according to Google’s release notes (December 2024), the throttling was adjusted to the slow CPUs of the PSI measurement servers (Google states the change but no number; the 1.2× comes from PSI reports). The generic Lighthouse default of 4× does not apply to PSI. WPT throttles much harder, 15× in one fepo run; the factor depends on the individual WPT test machine. This mainly affects pages with a lot of JavaScript and heavy rendering (TBT, LCP).
• Network: PSI simulates throttling by calculation. WPT loads the page over a real connection shaped to a 4G profile from the chosen location (default: Frankfurt).
• Lighthouse version: WPT uses an older version (11.x), PSI a current one. The older version does not recognise some newer techniques. Example: Lighthouse 11 does not know the zstd compression and wrongly reports “Enable text compression”. fepo checks such findings against the actual response headers and removes them from the report.

• The stricter WPT values show where rendering or JavaScript slows down slow smartphones.
• Compare runs with each other only if they come from the same measurement location; WPT values and PSI values are not directly comparable.
• Real-device data only comes from field data (CrUX: real Chrome users, last 28 days). The fepo report shows it when Google has enough data for the page.

LCP ist einer der drei Core Web Vitals und fließt direkt in das Google-Suchranking ein. Ein hoher Wert bedeutet, dass Besucher lange auf den Hauptinhalt warten — die Absprungrate steigt, bevor die Seite fertig ist.

• Bilder komprimieren und in modernen Formaten (WebP, AVIF) ausliefern
• Server-Response-Zeit verkürzen (TTFB optimieren, Caching aktivieren)
• Render-blockierende Ressourcen (CSS, JavaScript) reduzieren
• Beim Hero-Bild fetchpriority="high" setzen (niemals loading="lazy")
• <link rel="preload" as="image" href="hero.jpg" fetchpriority="high"> als erstes <link> im <head> einfügen — Browser startet den Download sofort beim HTML-Parsen
• CDN einsetzen, um Ladezeiten weltweit zu verkürzen

LCP is one of the three Core Web Vitals and directly influences Google search rankings. A high LCP score means visitors wait a long time for the main content — bounce rates rise before the page finishes loading.

• Compress images and serve them in modern formats (WebP, AVIF)
• Reduce server response time (optimise TTFB, enable caching)
• Remove render-blocking resources (CSS, JavaScript)
• Set fetchpriority="high" on the hero image (never loading="lazy")
• Add <link rel="preload" as="image" href="hero.jpg" fetchpriority="high"> as the first <link> in <head> — the browser starts downloading the image immediately during HTML parsing
• Use a CDN to reduce load times globally

INP hat FID im März 2024 als Core Web Vital abgelöst und bewertet die Interaktivität über die gesamte Seiten-Session — nicht nur die erste Eingabe. Langsame Reaktionen lassen die Seite eingefroren wirken und frustrieren Nutzer nachhaltig.

• Lange JavaScript-Tasks aufteilen (mit setTimeout oder scheduler.yield())
• Schwere Event-Handler optimieren — keine teuren Berechnungen direkt im Click-Handler
• Unnötige DOM-Änderungen reduzieren, die Browser-Rendering auslösen
• Code-Splitting einsetzen, damit der Main Thread nicht blockiert wird

INP replaced FID in March 2024 as a Core Web Vital and evaluates interactivity across the entire page session — not just the first input. Slow responses make pages feel frozen and frustrate users over time.

• Break up long JavaScript tasks (using setTimeout or scheduler.yield())
• Optimise heavy event handlers — avoid expensive calculations directly in click handlers
• Reduce unnecessary DOM changes that trigger browser rendering
• Use code splitting to keep the main thread unblocked

Layout-Sprünge sind frustrierend und führen zu Fehlklicks. Google bewertet CLS als Core Web Vital — besonders auf mobilen Geräten ist ein stabiles Layout ein wichtiges Rankingkriterium. Der Score ergibt sich aus Verschiebungsgröße × Bewegungsdistanz.

• Bilder und Videos immer mit width und height definieren, damit der Browser Platz reserviert
• Werbebanner und eingebettete Inhalte mit fester Platzhaltergröße versehen
• Keine Elemente dynamisch über bestehendem Inhalt einblenden (z.B. Cookie-Banner oben)
• Web-Schriften mit font-display: optional laden, um Schrift-bedingte Verschiebungen zu vermeiden

Layout shifts frustrate users and cause accidental clicks. Google counts CLS as a Core Web Vital — a stable layout is an important ranking factor, especially on mobile. The score is calculated from shift fraction × movement distance.

• Always set width and height on images and videos so the browser can reserve space
• Give ads and embedded content a fixed placeholder size
• Don't inject elements dynamically above existing content (e.g. cookie banners at the top)
• Load web fonts with font-display: optional to avoid font-induced shifts

FCP beeinflusst die wahrgenommene Ladegeschwindigkeit maßgeblich. Wenn lange nichts erscheint, fühlt sich die Seite "kaputt" an — auch wenn sie technisch noch lädt. FCP geht mit 10% in den Lighthouse Performance Score ein.

• Server-Response-Zeit (TTFB) verbessern — Verzögerungen hier wirken sich direkt auf FCP aus
• Render-blockierende CSS und JavaScript entfernen oder verzögert laden
• Web-Schriften mit font-display: swap laden, damit Text sofort sichtbar ist
• Kritisches CSS direkt im <head> inline einbetten

FCP heavily influences perceived loading speed. When nothing appears for a long time, the page feels "broken" — even if it's technically still loading. FCP contributes 10% to the Lighthouse Performance score.

• Improve server response time (TTFB) — any delay here directly impacts FCP
• Remove or defer render-blocking CSS and JavaScript
• Load web fonts with font-display: swap so text is immediately visible
• Inline critical CSS directly in the <head>

TTFB ist die Basis für alle anderen Metriken — ein langsamer Server zieht FCP, LCP und alle weiteren Werte nach unten. Gleichzeitig ist TTFB oft der beste erste Ansatzpunkt: Hosting-Qualität, Caching und CDN haben hier den größten Hebel.

• Server-seitiges Caching aktivieren (Redis, Varnish, Page-Cache-Plugins)
• CDN einsetzen, damit Inhalte vom nächstgelegenen Server ausgeliefert werden
• Hosting-Paket upgraden oder zu einem schnelleren Anbieter wechseln
• Datenbankabfragen optimieren und unnötige Server-seitige Berechnungen reduzieren
• HTTP/2 oder HTTP/3 aktivieren

TTFB is the foundation for all other metrics — a slow server drags FCP, LCP and everything else down with it. At the same time, TTFB is often the best first point of attack: hosting quality, caching, and CDN have the biggest impact here.

• Enable server-side caching (Redis, Varnish, page cache plugins)
• Use a CDN so content is served from the nearest server
• Upgrade your hosting plan or switch to a faster provider
• Optimise database queries and reduce unnecessary server-side processing
• Enable HTTP/2 or HTTP/3

Jede HTTP-Anfrage kostet mindestens 1 RTT — beim TLS-Handshake sind es sogar 2–3. Bei einem RTT von 170 ms (wie im fepo Mobile-4G-Testprofil) summiert sich das schnell. Ein CDN mit Standort nahe beim Nutzer ist die wirksamste Maßnahme um RTT zu reduzieren.

• CDN einsetzen — Inhalte werden vom nächstgelegenen Edge-Server ausgeliefert
• HTTP/2 oder HTTP/3 nutzen — mehrere Anfragen über eine einzige Verbindung
• Anzahl der Anfragen reduzieren — jede vermiedene Anfrage spart 1 RTT
• preconnect für wichtige Drittanbieter-Domains setzen

Every HTTP request costs at least 1 RTT — for the TLS handshake it's even 2–3. With an RTT of 170 ms (as in the fepo Mobile 4G test profile) this adds up fast. A CDN with a location close to the user is the most effective measure to reduce RTT.

• Use a CDN — content is served from the nearest edge server
• Use HTTP/2 or HTTP/3 — multiple requests over a single connection
• Reduce the number of requests — every avoided request saves 1 RTT
• Set preconnect for important third-party domains

TBT hat in Lighthouse v10 mit 30% die höchste Gewichtung aller Metriken — es ist der stärkste Lab-Indikator für wahrgenommene Interaktivität und korreliert gut mit dem realen INP-Wert. TBT wird nur im Labor gemessen, nicht aus echten Nutzerdaten (CrUX).

• Lange JavaScript-Tasks (> 50 ms) im Performance Profiler identifizieren und aufteilen
• Unused JavaScript entfernen (Tree Shaking, Code Splitting)
• Drittanbieter-Skripte (Analytics, Chat, Werbung) per async/defer laden oder lazy-loaden
• Tracking-Pixel komplett aus dem Browser entfernen mit Server-Side Tagging (SST) — reduziert Drittanbieter-JS auf null
• Main Thread durch Web Workers entlasten

TBT has the highest weighting of all metrics in Lighthouse v10 at 30% — it is the strongest lab indicator of perceived interactivity and correlates well with real-world INP. TBT is only measured in the lab, not from real user data (CrUX).

• Identify and break up long JavaScript tasks (> 50 ms) using the Performance Profiler
• Remove unused JavaScript (tree shaking, code splitting)
• Load third-party scripts (analytics, chat, ads) with async/defer or lazy-load them
• Remove tracking pixels from the browser entirely with Server-Side Tagging (SST) — reduces third-party JS to zero
• Offload work to Web Workers to free the main thread

SI bewertet das gesamte visuelle Ladeerlebnis, nicht nur einen einzelnen Moment. Er geht mit 10% in den Lighthouse Score ein. Eine langsam aufbauende Seite wirkt träge — auch wenn einzelne Elemente technisch schnell laden.

• Kritisches CSS inline einbetten, damit Above-the-Fold-Inhalte sofort erscheinen
• Render-blockierende Ressourcen reduzieren
• Bilder unterhalb der Sichtlinie lazy-loaden (loading="lazy")
• Animationen und Transitions erst nach dem Laden starten

SI evaluates the overall visual loading experience, not just a single moment. It contributes 10% to the Lighthouse score. A slowly building page feels sluggish — even if individual elements technically load quickly.

• Inline critical CSS so above-the-fold content appears immediately
• Reduce render-blocking resources
• Lazy-load images below the fold (loading="lazy")
• Start animations and transitions only after loading completes

Der Lighthouse Score und die CrUX-Daten im Dashboard messen unterschiedliche Dinge: Lighthouse läuft im Lab mit simulierten Bedingungen (gedrosseltes Netz, emuliertes Mobile). CrUX zeigt echte Nutzerdaten aus Chrome. Beide Perspektiven ergänzen sich — ein guter Lab-Score ist kein Garant für gute Felddaten, und umgekehrt.

fepo zeigt zwei Lighthouse-Messungen: unsere eigene (Programmatic Lighthouse, lokal auf unserem Server) und den PageSpeed Insights Score (Google's Infrastruktur). Abweichungen zwischen beiden Werten sind normal und haben mehrere Ursachen:

• Hardware: Unser Server (Xeon E3-1275 v5) hat eine andere CPU-Baseline als Google's Testumgebung. CPU-Throttling (4×) ist relativ zur Host-Hardware — gleicher Faktor, unterschiedliches Ergebnis.
• Standort: fepo misst aus Frankfurt (DE), PageSpeed Insights von Google's Infrastruktur. Bei Servern in der EU kann die Latenz aus Google's Perspektive höher sein.
• Normale Varianz: Lighthouse-Ergebnisse schwanken zwischen einzelnen Runs um ±5–10 Punkte. Das ist kein Fehler, sondern systembedingt — Netzwerkschwankungen, Server-Last und Rendering-Unterschiede beeinflussen jede Messung.

The Lighthouse score and the CrUX data in your dashboard measure different things: Lighthouse runs in a lab with simulated conditions (throttled network, emulated mobile). CrUX shows real user data from Chrome. Both perspectives complement each other — a good lab score doesn't guarantee good field data, and vice versa.

fepo shows two Lighthouse measurements: our own (Programmatic Lighthouse, running locally on our server) and the PageSpeed Insights score (Google's infrastructure). Differences between both values are normal and have several causes:

• Hardware: Our server (Xeon E3-1275 v5) has a different CPU baseline than Google's test environment. CPU throttling (4×) is relative to the host hardware — same factor, different result.
• Location: fepo measures from Frankfurt (DE), PageSpeed Insights from Google's infrastructure. For EU-based servers, latency from Google's perspective may be higher.
• Normal variance: Lighthouse results fluctuate between runs by ±5–10 points. This is not a bug but systemic — network jitter, server load, and rendering differences affect every measurement.

Jede Komponente fließt mit einem festen Gewicht in den Score ein. Wenn eine Datenquelle nicht verfügbar ist (z.B. kein Lighthouse-Lauf), wird ihr Gewicht auf die übrigen Komponenten verteilt — der Score bleibt dadurch immer fair und vergleichbar.

Each component contributes with a fixed weight. If a data source is unavailable (e.g. no Lighthouse run), its weight is redistributed across the remaining components — keeping the score fair and comparable at all times.

Der Lighthouse Performance Score bewertet ausschließlich die Ladegeschwindigkeit. Der fepo Score bewertet Ihre Website ganzheitlich — er berücksichtigt zusätzlich Sicherheit, SEO, Barrierefreiheit, CSS-Qualität, Bilder und Kompression. Wenn CrUX-Felddaten (echte Nutzer) verfügbar sind, fließen diese ebenfalls ein und erhöhen die Aussagekraft des Scores.

The Lighthouse Performance score evaluates loading speed only. The fepo Score rates your website holistically — it additionally considers security, SEO, accessibility, CSS quality, images and compression. When CrUX field data (real users) is available, it is incorporated too, further sharpening the score.

• Ad-Blocker und Browser-Tracking-Schutz greifen nicht — die Daten kommen zuverlässig an
• Tracker feuern nicht mehr im Browser des Nutzers, wodurch Consent-Probleme (DSGVO) minimiert werden
• Externe Tracking-Skripte (Google Tag Manager, Meta Pixel, TikTok Pixel…) werden vollständig aus dem Browser entfernt — die Seite lädt schneller
• Datenkontrolle: Sie entscheiden, welche Daten wirklich an Drittanbieter weitergeleitet werden
• Bessere Datenqualität durch weniger Browser-Interferenzen (ITP, ETP, SameSite-Cookie-Einschränkungen)

• Google Analytics 4 — vollständig über SST abbildbar inkl. E-Commerce-Events
• Google Ads — Conversion-Tracking und Remarketing
• Meta (Facebook) Pixel — Conversions API (CAPI) als serverseitiges Pendant
• TikTok Pixel — Events API
• LinkedIn Insight Tag — Conversion-Tracking
• Pinterest Tag, Snapchat Pixel, Criteo, Hotjar — je nach Anbieter vollständig oder teilweise
• Jeder Service, der über Google Tag Manager (GTM) eingebunden wird, kann serverseitig verwaltet werden
• Scripts, die das DOM direkt manipulieren (z. B. Live-Chat-Widgets, Session-Recording-Tools, visuelle A/B-Testing-Snippets), können nicht über SST ausgeführt werden

• TAGGRS — Dediziertes WooCommerce-Plugin, befüllt den GTM-Datalayer automatisch. Ideal für WooCommerce-Shops.
• Stape.io — Managed GTM Server-Side Hosting. WordPress-Plugin verfügbar, kostengünstigster Einstieg.
• Addingwell — Französischer Anbieter. Hochverfügbarkeit, Premium-Support — ideal für Agenturen und hohen Traffic.
• Tracklution — Managed Server-Side-Tracking aus der EU (Helsinki), First-Party-CNAME, ISO-27001-/SOC-2-zertifiziert. Wartungsfrei, code-los — ideal für DSGVO-sensible Werbetreibende.
• Selbst gehostet — GTM Server-Side Container auf eigenem Cloud Run, VPS oder Kubernetes. Maximale Kontrolle, erfordert technisches Know-how.

• Ad-blockers and browser tracking protection don't interfere — data arrives reliably
• Trackers no longer fire in the user's browser, minimising consent issues (GDPR)
• External tracking scripts (Google Tag Manager, Meta Pixel, TikTok Pixel…) are removed from the browser entirely — the page loads faster
• Data control: you decide exactly what data gets forwarded to third parties
• Better data quality with fewer browser interferences (ITP, ETP, SameSite cookie restrictions)

• Google Analytics 4 — fully supported via SST including e-commerce events
• Google Ads — conversion tracking and remarketing
• Meta (Facebook) Pixel — Conversions API (CAPI) as the server-side equivalent
• TikTok Pixel — Events API
• LinkedIn Insight Tag — conversion tracking
• Pinterest Tag, Snapchat Pixel, Criteo, Hotjar — fully or partially supported depending on provider
• Any service managed via Google Tag Manager (GTM) can be handled server-side
• Scripts that directly manipulate the DOM (e.g. live chat widgets, session recording tools, visual A/B testing snippets) cannot be run via SST

• TAGGRS — Dedicated WooCommerce plugin, automatically populates the GTM data layer. Ideal for WooCommerce stores.
• Stape.io — Managed GTM server-side hosting. WordPress plugin available, most cost-effective entry point.
• Addingwell — French provider. High availability, premium support — ideal for agencies and high-traffic sites.
• Tracklution — Managed server-side tracking based in the EU (Helsinki), first-party CNAME, ISO 27001 / SOC 2 certified. Maintenance-free, no-code — ideal for GDPR-conscious advertisers.
• Self-hosted — GTM server-side container on your own Cloud Run, VPS or Kubernetes. Maximum control, requires technical expertise.

• Art. 12 DSGVO (Transparenz) — die Einwilligung muss in verständlicher und leicht zugänglicher Form eingeholt werden. Ein Banner unterhalb des Folds erfüllt das nicht.
• § 25 TDDDG — Cookies/Tracking dürfen erst nach Einwilligung gesetzt werden. Wenn der Banner gar nicht sichtbar ist, kann der Nutzer auch nicht zustimmen.
• EuGH C-673/17 (Planet49) — Einwilligung muss aktiv, informiert und freiwillig erteilt werden. Verzögerte Sichtbarkeit untergräbt das.
• Dark Patterns — versteckte oder verzögerte Banner sind in der EDPB-Leitlinie 03/2022 als Verstoß kategorisiert.

• Initialer Viewport — ist der Banner direkt nach dem Page-Load sichtbar?
• Scroll-Trigger (scroll_triggered: true) — Banner erschien erst nach Scroll-Aktion. Im Report wird ein Warnhinweis unter dem Screenshot angezeigt.
• CSS-Verstecken (hidden_via_css: true) — Banner per display:none, visibility:hidden oder Off-Canvas verborgen. Klar bußgeldrelevant.
• Reject-Pfad — gibt es einen gleichwertigen "Ablehnen"-Button? (Art. 7 Abs. 3 DSGVO: Einwilligung muss so einfach widerrufbar wie erteilbar sein.)

• CMP wird per JavaScript dynamisch eingefügt und braucht ~2-3 Sekunden — in dieser Zeit feuern Tracker bereits.
• Banner liegt bewusst unterhalb der ersten Bildschirmhöhe, um "Akzeptieren"-Conversions zu erhöhen.
• Mobile-Layout zeigt Banner, Desktop-Layout nicht (oder umgekehrt) — fepo prüft im Mobile-Profil (Moto G4, 360×640).
• Anti-Bot-Heuristiken (Cloudflare, Akamai) blockieren den Banner für Crawler — sieht für Nutzer korrekt aus, der Audit-Crawler sieht aber nichts. In dem Fall flaggt fepo es als cmp_ghost.

• Art. 12 GDPR (transparency) — consent must be obtained in a clear and easily accessible form. A banner below the fold doesn't meet that bar.
• § 25 TDDDG (German implementation of ePrivacy) — cookies/tracking only after consent. If the banner isn't visible, the user can't consent.
• CJEU C-673/17 (Planet49) — consent must be active, informed, and freely given. Delayed visibility undermines that.
• Dark patterns — hidden or delayed banners are categorised as violations in EDPB Guidelines 03/2022.

• Initial viewport — is the banner visible right after page load?
• Scroll trigger (scroll_triggered: true) — banner only appeared after scrolling. The report adds a warning hint below the screenshot.
• CSS hiding (hidden_via_css: true) — banner hidden via display:none, visibility:hidden, or off-canvas. Clearly grounds for a fine.
• Reject path — is there an equivalent "Reject" button? (Art. 7(3) GDPR: withdrawing consent must be as easy as giving it.)

• The CMP is injected dynamically via JavaScript and takes ~2-3 seconds — trackers fire in that window.
• Banner is intentionally placed below the fold to boost "Accept" conversion.
• Mobile layout shows the banner, desktop doesn't (or vice versa) — fepo audits in the mobile profile (Moto G4, 360×640).
• Anti-bot heuristics (Cloudflare, Akamai) block the banner for crawlers — looks fine to users, but our crawler sees nothing. fepo flags this as cmp_ghost.

• BFSG (Barrierefreiheitsstärkungsgesetz) — Deutschland, verpflichtend ab 28. Juni 2025 für digitale Produkte und Dienstleistungen
• EAA (European Accessibility Act) — EU-weit, Richtlinie (EU) 2019/882, nationale Umsetzung in allen Mitgliedstaaten
• ADA / Section 508 — USA, Americans with Disabilities Act und Section 508 des Rehabilitation Act
• Technischer Standard: EN 301 549 referenziert WCAG 2.1 Level AA als Mindestanforderung

• Kritisch — Inhalte sind für bestimmte Nutzergruppen komplett unzugänglich (z.B. fehlende Alt-Texte bei Bildern, kein Tastatur-Zugang)
• Schwerwiegend — Nutzung stark eingeschränkt (z.B. unzureichender Farbkontrast, fehlende Formular-Labels)
• Mittel — Nutzung erschwert aber möglich (z.B. fehlende Landmarks, unklare Link-Texte)
• Gering — Best-Practice-Verstöße mit minimalem Einfluss auf die Zugänglichkeit

• color-contrast — Text hat nicht genug Kontrast zum Hintergrund (mindestens 4.5:1 für normalen Text, 3:1 für großen Text)
• image-alt — Bilder ohne Alt-Text, Screenreader können den Inhalt nicht vorlesen
• label — Formularfelder ohne zugehöriges Label-Element
• link-name — Links ohne erkennbaren Text (z.B. leere <a>-Tags oder nur Icons)
• html-has-lang — Das <html>-Element hat kein lang-Attribut

• BFSG (Barrierefreiheitsstärkungsgesetz) — Germany, mandatory from June 28, 2025 for digital products and services
• EAA (European Accessibility Act) — EU-wide, Directive (EU) 2019/882, national implementation in all member states
• ADA / Section 508 — USA, Americans with Disabilities Act and Section 508 of the Rehabilitation Act
• Technical standard: EN 301 549 references WCAG 2.1 Level AA as the minimum requirement

• Critical — Content completely inaccessible to certain user groups (e.g. missing alt text on images, no keyboard access)
• Serious — Usage severely restricted (e.g. insufficient colour contrast, missing form labels)
• Moderate — Usage hindered but possible (e.g. missing landmarks, unclear link text)
• Minor — Best practice violations with minimal impact on accessibility

• color-contrast — Text does not have sufficient contrast against its background (at least 4.5:1 for normal text, 3:1 for large text)
• image-alt — Images without alt text, screen readers cannot convey the content
• label — Form fields without an associated label element
• link-name — Links without discernible text (e.g. empty <a> tags or icon-only links)
• html-has-lang — The <html> element is missing a lang attribute

• AVIF — Bestes Kompressionsverhältnis, 40–60% kleiner als JPEG bei gleicher Qualität. Unterstützung: Chrome, Firefox, Safari 16.4+
• WebP — 25–35% kleiner als JPEG, breite Browser-Unterstützung seit 2020
• <picture>-Element nutzen: AVIF als erste Source, WebP als Fallback, Originalformat als <img>-Fallback

• fepo misst die tatsächliche Darstellungsgröße jedes Bildes auf einem Desktop-Viewport (2560×1440 px)
• Ein Bild gilt als überdimensioniert, wenn seine intrinsische Breite mehr als 2× die angezeigte Breite beträgt (Retina-Toleranz)
• Beispiel: Ein 3840 px breites Bild, das nur 800 px breit angezeigt wird, könnte auf 1600 px verkleinert werden — Einsparung ~75% der Pixel
• srcset und sizes nutzen, damit der Browser die passende Auflösung wählt

• loading="lazy" — Bilder unterhalb des Viewports erst bei Bedarf laden (aber nicht für das LCP-Bild!)
• width/height-Attribute setzen, um Layout-Shifts (CLS) zu vermeiden
• fetchpriority="high" — Für das Hero-/LCP-Bild, damit es priorisiert geladen wird

• AVIF — Best compression ratio, 40–60% smaller than JPEG at equal quality. Support: Chrome, Firefox, Safari 16.4+
• WebP — 25–35% smaller than JPEG, broad browser support since 2020
• Use the <picture> element: AVIF as first source, WebP as fallback, original format as <img> fallback

• fepo measures the actual displayed size of each image on a desktop viewport (2560×1440 px)
• An image is flagged as oversized when its intrinsic width exceeds 2× the displayed width (Retina tolerance)
• Example: A 3840 px wide image displayed at only 800 px could be resized to 1600 px — saving ~75% of pixels
• Use srcset and sizes so the browser picks the appropriate resolution

• loading="lazy" — Defer off-screen images until needed (but not the LCP image!)
• Set width/height attributes to prevent layout shifts (CLS)
• fetchpriority="high" — For the hero/LCP image so it loads with priority

• DSGVO-Pflicht — Google Fonts über fonts.googleapis.com zu laden überträgt die IP-Adresse des Nutzers an Google. Seit dem Urteil des LG München (Az. 3 O 17493/20) ist das ohne Einwilligung unzulässig
• Performance — Self-Hosted Fonts eliminieren DNS-Lookup + TCP-Verbindung zu Google. Eine externe Domain weniger = schnellerer LCP
• Tools: google-webfonts-helper generiert fertige @font-face-Regeln mit WOFF2-Dateien

• Die meisten Fonts enthalten tausende Glyphen (Kyrillisch, Griechisch, CJK). Für eine deutsche Website reichen Latin + Latin Extended
• Subsetting reduziert die Dateigröße oft um 50–80%
• unicode-range in @font-face nutzen, damit der Browser nur die benötigten Subsets lädt

• font-display: swap — Text sofort mit Fallback-Font anzeigen, dann tauschen wenn der Web-Font geladen ist. Verhindert unsichtbaren Text (FOIT)
• font-display: optional — Für nicht-essentielle Fonts. Browser zeigt den Font nur an, wenn er bereits im Cache ist. Beste Performance, kein Layout-Shift
• Font-Dateien mit rel="preload" vorladen: <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

• GDPR requirement — Loading Google Fonts via fonts.googleapis.com sends the user's IP address to Google. Under EU law, this requires explicit consent
• Performance — Self-hosted fonts eliminate a DNS lookup + TCP connection to Google. One fewer external domain = faster LCP
• Tools: google-webfonts-helper generates ready-to-use @font-face rules with WOFF2 files

• Most fonts contain thousands of glyphs (Cyrillic, Greek, CJK). For a German website, Latin + Latin Extended is sufficient
• Subsetting typically reduces file size by 50–80%
• Use unicode-range in @font-face so the browser only downloads the required subsets

• font-display: swap — Show text immediately with a fallback font, then swap when the web font loads. Prevents invisible text (FOIT)
• font-display: optional — For non-essential fonts. Browser only uses the font if it's already cached. Best performance, no layout shift
• Preload font files: <link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

• Brotli (br) — Bestes Verfahren, 15–25% kleiner als Gzip. Standard in allen modernen Browsern seit 2017. Erfordert HTTPS
• Gzip (gz) — Universell unterstützt, gute Kompression. Fallback wenn Brotli nicht verfügbar
• Zstd — Neues Verfahren von Facebook/Meta, noch geringe Browser-Unterstützung (Chrome 123+)
• Unkomprimiert — Verschwendung. Jede Text-Ressource ohne Komprimierung verschwendet 60–90% Bandbreite

• Apache — mod_brotli aktivieren: AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript
• Nginx — brotli on; brotli_types text/html text/css application/javascript;
• Statische Vorab-Komprimierung — .br und .gz Dateien neben den Originalen ablegen. Der Server liefert automatisch die komprimierte Version
• Bilder (JPEG, PNG, WebP, AVIF) nicht komprimieren — sie sind bereits komprimiert, Gzip/Brotli bringt keinen Gewinn

• Brotli (br) — Best method, 15–25% smaller than Gzip. Supported by all modern browsers since 2017. Requires HTTPS
• Gzip (gz) — Universally supported, good compression. Fallback when Brotli is unavailable
• Zstd — New method by Facebook/Meta, limited browser support so far (Chrome 123+)
• Uncompressed — Wasteful. Every text resource served without compression wastes 60–90% of bandwidth

• Apache — Enable mod_brotli: AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript
• Nginx — brotli on; brotli_types text/html text/css application/javascript;
• Static pre-compression — Place .br and .gz files alongside the originals. The server automatically serves the compressed version
• Don't compress images (JPEG, PNG, WebP, AVIF) — they're already compressed; Gzip/Brotli adds no benefit

• XSS (Cross-Site Scripting) — verhindert das Ausführen injizierter Skripte, auch wenn ein Angreifer schadhaften Code in die Seite einschleusen konnte
• Clickjacking — frame-ancestors 'none' verhindert das Einbetten Ihrer Seite in fremde iframes
• Datenlecks — connect-src schränkt ein, wohin die Seite Daten per fetch/XHR/WebSocket senden darf
• Mixed Content — verhindert, dass HTTPS-Seiten unsichere HTTP-Ressourcen laden

• default-src 'self' — Fallback für alle nicht explizit gesetzten Direktiven: nur die eigene Domain
• script-src — erlaubte Skript-Quellen (kritischste Direktive — Fehler hier öffnen XSS-Lücken)
• style-src — erlaubte CSS-Quellen
• img-src 'self' data: https: — eigene Domain + Base64-Bilder + alle HTTPS-Bildquellen
• font-src 'self' https://fonts.gstatic.com — eigene Fonts + Google Fonts CDN
• connect-src 'self' — fetch/XHR/WebSocket nur zur eigenen Domain
• frame-ancestors 'none' — Seite darf nirgendwo eingebettet werden (ersetzt den älteren X-Frame-Options: DENY Header)

Statt Content-Security-Policy zunächst Content-Security-Policy-Report-Only verwenden. Der Browser blockiert nichts, loggt aber alle Verstöße in der Konsole (DevTools → Console). So können Sie die Policy 2–4 Wochen beobachten und anpassen, bevor sie aktiv Ressourcen blockiert.

'unsafe-inline' in script-src erlaubt alle Inline-Skripte und hebt damit den XSS-Schutz weitgehend auf. Besser:

• Nonce — serverseitig pro Request ein zufälliger Wert generiert, der gleichzeitig im Header und im <script nonce="...">-Tag steht. Nur dieses eine Script wird ausgeführt. Erfordert serverseitige Implementierung (PHP, Node.js, etc.).
• Hash — SHA-256-Hash des Inline-Script-Inhalts in die Policy schreiben ('sha256-abc123...'). Geeignet für statischen Inline-Code, der sich nicht ändert.
• 'unsafe-inline' in style-src ist weniger kritisch als in script-src, sollte aber langfristig ebenfalls entfernt werden

WordPress-Core und viele Plugins setzen Inline-Skripte und -Styles. Empfohlene Vorgehensweise:

• CSP zunächst als Report-Only in der .htaccess setzen
• Browser-Konsole 2–4 Wochen beobachten und notieren, welche Quellen blockiert würden
• Policy schrittweise erweitern, bis keine Verstöße mehr erscheinen
• Danach auf Content-Security-Policy umstellen
• Plugins, die ausschließlich externe Drittanbieter-Domains laden, explizit zur Policy hinzufügen (z. B. Google Analytics: connect-src https://www.google-analytics.com)

<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only \
    "default-src 'self'; \
     script-src 'self' 'unsafe-inline'; \
     style-src 'self' 'unsafe-inline'; \
     img-src 'self' data: https:; \
     font-src 'self' https://fonts.gstatic.com; \
     connect-src 'self'; \
     frame-ancestors 'none'"
</IfModule>

Sobald keine Verstöße mehr auftreten, Report-Only durch Content-Security-Policy ersetzen und 'unsafe-inline' schrittweise durch Nonces oder Hashes ablösen.

• XSS (Cross-Site Scripting) — prevents injected scripts from executing, even if an attacker managed to insert malicious code into the page
• Clickjacking — frame-ancestors 'none' prevents your page from being embedded in third-party iframes
• Data leaks — connect-src restricts where the page can send data via fetch/XHR/WebSocket
• Mixed content — prevents HTTPS pages from loading insecure HTTP resources

• default-src 'self' — fallback for all directives not explicitly set: own domain only
• script-src — allowed script sources (most critical directive — mistakes here open XSS vulnerabilities)
• style-src — allowed CSS sources
• img-src 'self' data: https: — own domain + base64 images + all HTTPS image sources
• font-src 'self' https://fonts.gstatic.com — own fonts + Google Fonts CDN
• connect-src 'self' — fetch/XHR/WebSocket to own domain only
• frame-ancestors 'none' — page cannot be embedded anywhere (replaces the older X-Frame-Options: DENY header)

Instead of Content-Security-Policy, start with Content-Security-Policy-Report-Only. The browser blocks nothing but logs all violations to the console (DevTools → Console). This lets you observe and refine the policy over 2–4 weeks before it actively blocks any resources.

'unsafe-inline' in script-src permits all inline scripts and largely defeats XSS protection. Better alternatives:

• Nonce — a random value generated server-side per request, included in both the header and the <script nonce="..."> tag. Only that specific script executes. Requires server-side implementation (PHP, Node.js, etc.).
• Hash — write the SHA-256 hash of the inline script content into the policy ('sha256-abc123...'). Suitable for static inline code that never changes.
• 'unsafe-inline' in style-src is less critical than in script-src, but should also be removed over time

WordPress core and many plugins inject inline scripts and styles. Recommended approach:

• Start with CSP in Report-Only mode via .htaccess
• Monitor the browser console for 2–4 weeks, note which sources would be blocked
• Gradually extend the policy until no violations appear
• Switch to Content-Security-Policy
• Plugins loading third-party domains must be added explicitly (e.g. Google Analytics: connect-src https://www.google-analytics.com)

<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only \
    "default-src 'self'; \
     script-src 'self' 'unsafe-inline'; \
     style-src 'self' 'unsafe-inline'; \
     img-src 'self' data: https:; \
     font-src 'self' https://fonts.gstatic.com; \
     connect-src 'self'; \
     frame-ancestors 'none'"
</IfModule>

Once no violations appear, replace Report-Only with Content-Security-Policy and gradually replace 'unsafe-inline' with nonces or hashes.

CSS blockiert das Rendering: Kein Pixel wird gezeichnet bevor alle CSS-Dateien geladen und geparst sind. Jedes Kilobyte unbenutztes CSS verzögert den First Contentful Paint (FCP) und den Largest Contentful Paint (LCP) direkt.

• Unbenutztes CSS entfernen — Tools wie PurgeCSS oder der Coverage-Tab in Chrome DevTools zeigen genau welche Regeln nicht verwendet werden
• Critical CSS inlinen — die Styles für den sichtbaren Bereich direkt im <head> als <style> einbetten
• CSS-Dateien zusammenführen — weniger HTTP-Requests beschleunigen den Ladevorgang
• Drittanbieter-CSS prüfen — Plugins und Widgets laden oft eigene Stylesheets die auf vielen Seiten ungenutzt bleiben
• CSS minifizieren — Whitespace und Kommentare entfernen spart 10–30%

CSS blocks rendering: not a single pixel is painted until all CSS files are loaded and parsed. Every kilobyte of unused CSS directly delays First Contentful Paint (FCP) and Largest Contentful Paint (LCP).

• Remove unused CSS — tools like PurgeCSS or the Coverage tab in Chrome DevTools show exactly which rules aren't used
• Inline critical CSS — embed above-the-fold styles directly in the <head> as a <style> tag
• Combine CSS files — fewer HTTP requests speed up loading
• Review third-party CSS — plugins and widgets often load their own stylesheets that remain unused on many pages
• Minify CSS — removing whitespace and comments saves 10–30%

Jeder DOM-Node kostet Speicher und Rechenzeit. Bei über 1.500 Nodes werden Layout-Neuberechnungen spürbar langsamer, bei über 3.000 kann die Seite auf mobilen Geräten merklich ruckeln. Tiefe Verschachtelung (> 15 Ebenen) belastet CSS-Selektor-Matching und Event-Bubbling zusätzlich.

• Unnötige Wrapper-<div>s entfernen — Page-Builder erzeugen oft 3–5 Verschachtelungsebenen für ein einzelnes Element
• Listen und Tabellen virtualisieren — bei hunderten Einträgen nur die sichtbaren rendern
• Lazy Rendering für Below-the-Fold-Inhalte — erst beim Scrollen ins DOM einfügen
• HTML-Struktur vereinfachen — semantische Elemente (<section>, <article>) statt verschachtelter <div>s

Every DOM node costs memory and CPU time. Above 1,500 nodes, layout recalculations become noticeably slower; above 3,000, the page may visibly stutter on mobile devices. Deep nesting (> 15 levels) further impacts CSS selector matching and event bubbling.

• Remove unnecessary wrapper <div>s — page builders often create 3–5 nesting levels for a single element
• Virtualise lists and tables — only render visible items when dealing with hundreds of entries
• Lazy-render below-the-fold content — insert into the DOM only when scrolled into view
• Simplify HTML structure — use semantic elements (<section>, <article>) instead of nested <div>s

Meta-Tags sind der erste Eindruck Ihrer Seite — in Google-Suchergebnissen, bei Social-Media-Shares und für Crawler. Ein fehlender Title kostet Klicks, fehlende OG-Tags machen Shares unattraktiv, und ohne Canonical riskieren Sie Duplicate Content.

• Title: 50–60 Zeichen, einzigartig pro Seite, Keyword am Anfang
• Meta Description: 150–160 Zeichen, aussagekräftig, mit Call-to-Action
• Open Graph: Mindestens og:title, og:description, og:image für ansprechende Social-Media-Previews
• Canonical: Auf jeder Seite eine <link rel="canonical"> setzen um Duplicate Content zu vermeiden
• Viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> ist Pflicht für Mobile

Meta tags are your page's first impression — in Google search results, social media shares, and for crawlers. A missing title costs clicks, missing OG tags make shares unattractive, and without a canonical URL you risk duplicate content issues.

• Title: 50–60 characters, unique per page, keyword at the start
• Meta description: 150–160 characters, descriptive, with a call to action
• Open Graph: At least og:title, og:description, og:image for appealing social media previews
• Canonical: Set a <link rel="canonical"> on every page to avoid duplicate content
• Viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> is mandatory for mobile

JS-Fehler sind für Besucher unsichtbar aber oft geschäftskritisch: ein kaputtes Tracking-Script bedeutet fehlende Daten, ein fehlerhaftes Checkout-Script kostet direkt Umsatz. Jeder Fehler ist auch ein Hinweis auf technische Schulden.

• Fehlende Ressourcen (404) — Scripts oder Stylesheets die nicht mehr existieren
• CORS-Fehler — Drittanbieter-Scripts die von einer falschen Domain geladen werden
• Veraltete APIs — document.write(), synchrone XHR, nicht-sichere Cookies
• Plugin-Konflikte — mehrere Scripts die auf dasselbe DOM-Element zugreifen
• Mixed Content — HTTP-Ressourcen auf einer HTTPS-Seite

JS errors are invisible to visitors but often business-critical: a broken tracking script means missing data, a faulty checkout script directly costs revenue. Every error is also a sign of technical debt.

• Missing resources (404) — scripts or stylesheets that no longer exist
• CORS errors — third-party scripts loaded from the wrong domain
• Deprecated APIs — document.write(), synchronous XHR, insecure cookies
• Plugin conflicts — multiple scripts accessing the same DOM element
• Mixed content — HTTP resources on an HTTPS page

Jede Plattform hat eigene Stärken und Limitierungen. WordPress erlaubt volle Kontrolle über CSS und JS, Shopify beschränkt den Zugriff auf das Theme und liefert eigene Scripts aus. Zu wissen welche Plattform im Einsatz ist, hilft bei der Einschätzung welche Empfehlungen umsetzbar sind.

• CMS: WordPress, Shopify, Wix, Squarespace, TYPO3, Drupal, Joomla, HubSpot, Webflow
• Page Builder: Elementor, Divi, WPBakery, Oxygen, Bricks
• Frameworks: Next.js, Nuxt, Gatsby, SvelteKit, Astro
• Server: Apache, Nginx, LiteSpeed, Cloudflare, Vercel, Netlify
• Optimierbar vs. eingeschränkt: Wir zeigen welche Bereiche (CSS, JS, Bilder, Fonts) bei Ihrer Plattform optimiert werden können und welche nicht

Every platform has its own strengths and limitations. WordPress allows full control over CSS and JS, while Shopify restricts access to the theme and ships its own scripts. Knowing the platform helps assess which recommendations are actionable.

• CMS: WordPress, Shopify, Wix, Squarespace, TYPO3, Drupal, Joomla, HubSpot, Webflow
• Page builders: Elementor, Divi, WPBakery, Oxygen, Bricks
• Frameworks: Next.js, Nuxt, Gatsby, SvelteKit, Astro
• Servers: Apache, Nginx, LiteSpeed, Cloudflare, Vercel, Netlify
• Optimisable vs. restricted: We show which areas (CSS, JS, images, fonts) can be optimised on your platform and which cannot

• robots.txt: Sind AI-Crawler (GPTBot, ClaudeBot, PerplexityBot, etc.) erlaubt? Wenn blockiert, kann keine KI Ihre Inhalte indexieren.
• llms.txt: Eine vorgeschlagene Datei, die KI-Systemen beschreibt, was Ihre Seite bietet — ähnlich wie robots.txt für Suchmaschinen. Ob die großen KI-Anbieter sie auswerten, ist nicht belegt.
• Schema.org Markup: Article, Organization, Author — maschinenlesbare Angaben, die Google nutzt. ChatGPT und Claude entfernen JSON-LD beim Abruf (Studie Ramos, Oktober 2026): Wichtige Angaben gehören deshalb zusätzlich sichtbar auf die Seite. FAQPage prüft fepo nicht mehr — Google zeigt FAQ-Rich-Results seit Mai 2026 nicht mehr.
• Content-Struktur: Überschriften als Fragen formuliert? Antwort in den ersten 40-60 Wörtern? TL;DR-Block vorhanden? In einem Versuch mit KI-Assistenten wurden Seiten mit Frage-Formulierung deutlich häufiger gefunden und zitiert.
• Quellenangaben: Externe Links zu Primärquellen. Quellenangaben erhöhten in einer Studie die Sichtbarkeit in KI-Antworten um bis zu 40 % (Aggarwal u. a., KDD 2024, Testumgebung).
• Aktualität: datePublished und dateModified im Schema/Meta — das Datum zusätzlich sichtbar auf der Seite nennen.
• Open Graph: og:title, og:description, og:image — verbessert die Darstellung in KI-Antworten und Social Media.
• KI-Erfassbarkeit (Roh-HTML): Steht Ihr Textinhalt im HTML-Quelltext — oder wird er erst per JavaScript im Browser erzeugt? KI-Crawler wie GPTBot und ClaudeBot führen kein JavaScript aus. Bei rein clientseitig gerenderten Seiten (CSR) sehen sie fast nichts. fepo misst, wie viel Prozent Ihres Inhalts im Roh-HTML erfassbar ist.

Ein KI-Crawler holt Ihre Seite als reinen HTML-Quelltext — er führt kein JavaScript aus und scrollt nicht. Entscheidend ist deshalb, wie Ihre Seite gebaut ist:

• Server-Rendering (SSR/SSG) — z. B. WordPress, Next.js, Astro, statische Seiten: Der fertige Text steht im Quelltext. Die KI sieht alles. ✅
• Client-Rendering (CSR) — reine React/Vue-SPAs, App-Dashboards: Der Quelltext ist fast leer (<div id="root"></div>), der Inhalt entsteht erst im Browser. Die KI sieht fast nichts. ❌

Es kommt nicht aufs Framework an, sondern aufs Rendering-Modell: react.dev selbst ist serverseitig gerendert und voll KI-sichtbar. Faustregel: Was in „view-source:" steht, sieht die KI. (Googlebot ist die Ausnahme — er rendert JavaScript, weshalb CSR-Seiten bei Google ranken und den Betreiber in falscher Sicherheit wiegen.)

Immer mehr Nutzer suchen über KI statt über klassische Suchmaschinen. Google AI Overviews, ChatGPT Search, Perplexity — diese Systeme zitieren Websites die technisch und inhaltlich für KI optimiert sind. Wer nicht optimiert ist, wird nicht zitiert und verliert Sichtbarkeit.

• AI-Crawler in der robots.txt erlauben (GPTBot, ClaudeBot, PerplexityBot)
• Eine llms.txt Datei erstellen die Ihre Website beschreibt
• FAQ-Schema für häufig gestellte Fragen einbauen (JSON-LD im <head>)
• Überschriften als Fragen formulieren und direkt beantworten
• Statistiken und Aussagen mit Quellen belegen
• Veröffentlichungsdatum und Änderungsdatum im Schema pflegen
• Open Graph Tags vollständig einrichten

fepo generiert für jeden fehlgeschlagenen Check eine konkrete Empfehlung mit Copy-Paste-Code — Schema.org JSON-LD, Open Graph Tags, llms.txt Template — alles basierend auf dem tatsächlichen Inhalt Ihrer Seite.

• robots.txt: Are AI crawlers (GPTBot, ClaudeBot, PerplexityBot, etc.) allowed? If blocked, no AI can index your content.
• llms.txt: A proposed file that tells AI systems what your site offers — similar to robots.txt for search engines. Whether the major AI providers use it is not established.
• Schema.org Markup: Article, Organization, Author — machine-readable data that Google uses. ChatGPT and Claude strip JSON-LD when fetching a page (Ramos study, October 2026), so important details belong visibly on the page as well. fepo no longer checks FAQPage — Google stopped showing FAQ rich results in May 2026.
• Content structure: Headings as questions? Answer in the first 40-60 words? TL;DR block? In an experiment with AI assistants, pages phrased as questions were found and cited markedly more often.
• Citations: External links to primary sources. Citing sources raised visibility in AI answers by up to 40% in a study (Aggarwal et al., KDD 2024, test setting).
• Freshness: datePublished and dateModified in Schema/Meta — also show the date visibly on the page.
• Open Graph: og:title, og:description, og:image — improves presentation in AI answers and social media.
• AI availability (raw HTML): Is your text content in the HTML source — or is it only built by JavaScript in the browser? AI crawlers like GPTBot and ClaudeBot don't run JavaScript. On purely client-rendered sites (CSR) they see almost nothing. fepo measures what percentage of your content is available in the raw HTML.

An AI crawler fetches your page as plain HTML source — it doesn't run JavaScript and doesn't scroll. So what matters is how your page is built:

• Server rendering (SSR/SSG) — e.g. WordPress, Next.js, Astro, static sites: the finished text is in the source. The AI sees everything. ✅
• Client rendering (CSR) — pure React/Vue SPAs, app dashboards: the source is nearly empty (<div id="root"></div>), the content is only built in the browser. The AI sees almost nothing. ❌

It's not about the framework, but the rendering model: react.dev itself is server-rendered and fully AI-visible. Rule of thumb: what's in "view-source:" is what the AI sees. (Googlebot is the exception — it renders JavaScript, which is why CSR sites rank on Google and lull operators into a false sense of security.)

More and more users search via AI instead of traditional search engines. Google AI Overviews, ChatGPT Search, Perplexity — these systems cite websites that are technically and content-wise optimised for AI. Those who are not optimised will not be cited and lose visibility.

• Allow AI crawlers in robots.txt (GPTBot, ClaudeBot, PerplexityBot)
• Create an llms.txt file describing your website
• Add FAQ schema for frequently asked questions (JSON-LD in <head>)
• Phrase headings as questions and answer them directly
• Back up statistics and claims with source links
• Maintain publication and modification dates in schema
• Set up complete Open Graph tags

fepo generates a concrete recommendation with copy-paste code for each failed check — Schema.org JSON-LD, Open Graph tags, llms.txt template — all based on the actual content of your page.

Die robots.txt hat keinen Einfluss auf die fepo-Messung: fepo ruft Ihre Seite wie ein Besucher mit einem echten Browser auf. Wichtig ist sie für die Felddaten (CrUX): Google nimmt in den Chrome-Nutzerdatensatz nur Seiten auf, die Suchmaschinen indexieren dürfen. Zeigt der Bericht „Keine Felddaten: Ihre robots.txt sperrt Suchmaschinen“, enthält Ihre robots.txt eine Komplettsperre wie diese:

The robots.txt has no effect on the fepo measurement: fepo loads your page like a visitor with a real browser. It matters for field data (CrUX): Google only includes pages that search engines may index in the Chrome user dataset. If the report shows "No field data: your robots.txt blocks search engines", your robots.txt contains a full block like this:

User-agent: *
Disallow: /

Soll Ihre Seite in Suchmaschinen erscheinen, entfernen Sie die Sperre oder erlauben Sie Googlebot ausdrücklich — eine eigene Googlebot-Gruppe gilt vor der Gruppe für *:

If your page should appear in search engines, remove the block or explicitly allow Googlebot — a dedicated Googlebot group takes precedence over the * group:

User-agent: Googlebot
Allow: /

Auch ein noindex (Meta-Tag oder X-Robots-Tag) schließt die Seite aus. Und ohne genügend Chrome-Besucher gibt es ebenfalls keine Felddaten — das lässt sich nicht erzwingen.

A noindex (meta tag or X-Robots-Tag) also excludes the page. And without enough Chrome visitors there is no field data either — this cannot be forced.

Cloudflare kann den fepo-Test mit einer Challenge („Prüfung Ihres Browsers“) aufhalten. fepo erkennt das und berechnet den Versuch nicht. Welcher Schutz greift, sehen Sie unter Security → Events an der geblockten Anfrage. Davon hängt die Lösung ab:

Cloudflare can stop the fepo test with a challenge ("checking your browser"). fepo detects this and does not charge the attempt. Which protection fired is shown under Security → Events for the blocked request. The fix depends on it:

1. Bot Fight Mode (Free-Tarif): lässt sich mit keiner Regel umgehen. Schalten Sie ihn für den Test vorübergehend aus: Security → Bots → Bot Fight Mode.
2. Super Bot Fight Mode (ab Pro): unter Security → WAF → Custom rules eine Regel an erster Stelle anlegen: Field = IP Source Address, Operator = equals, Value = 138.201.131.59. Action = Skip mit All Super Bot Fight Mode rules und All remaining custom rules.
3. Browser Integrity Check / Security Level: in derselben Regel zusätzlich unter More components to skip → Products beide auswählen.
4. Bot Fight Mode (Free plan): cannot be bypassed by any rule. Turn it off temporarily for the test: Security → Bots → Bot Fight Mode.
5. Super Bot Fight Mode (Pro and above): under Security → WAF → Custom rules, add a rule in first position: Field = IP Source Address, Operator = equals, Value = 138.201.131.59. Action = Skip with All Super Bot Fight Mode rules and All remaining custom rules.
6. Browser Integrity Check / Security Level: in the same rule, also select both under More components to skip → Products.

fepo-Server-IP: 138.201.131.59. Viele Tests kurz hintereinander können Cloudflare zeitweise misstrauisch machen — dann hilft die Regel oder etwas Abstand zwischen den Tests. Lässt Cloudflare den fepo-Server trotzdem nicht durch, versucht fepo die Messung über WebPageTest; dessen Messknoten haben andere IP-Adressen.

fepo server IP: 138.201.131.59. Many tests in quick succession can make Cloudflare suspicious for a while — the rule or some time between tests helps. If Cloudflare still blocks the fepo server, fepo tries measuring via WebPageTest, whose test nodes use different IP addresses.

Erlauben Sie die fepo-Server-IP 138.201.131.59 in Ihrer Firewall-Konfiguration. Eine Ausnahme per User-Agent hilft nicht: fepo meldet sich als gewöhnliches Chrome. Bei Wordfence: Firewall → Whitelisted IPs. Bei Sucuri: Settings → Allowlisting.

Allow the fepo server IP 138.201.131.59 in your firewall configuration. A user-agent exception does not help: fepo identifies as ordinary Chrome. For Wordfence: Firewall → Whitelisted IPs. For Sucuri: Settings → Allowlisting.

Wenn der fepo-Crawler durch eine WAF blockiert wird, kann fepo automatisch auf WebPageTest (WPT) umschalten. WPT-Testserver sind bei vielen WAFs bekannt und whitelisted. Lighthouse-Metriken werden dann über die WPT-API gemessen statt lokal — mit identischem Throttling-Profil (Moto G4, Mobile 4G).

If the fepo crawler is blocked by a WAF, fepo can automatically fall back to WebPageTest (WPT). WPT test servers are known and whitelisted by many WAFs. Lighthouse metrics are then measured via the WPT API instead of locally — with an identical throttling profile (Moto G4, Mobile 4G).