Juno
So funktioniert’sBeispielberichtPreise
Gratis-Audit starten
© Juno
English
ImpressumDatenschutzAGBWiderruf
BrancheBäckereiketteReha-ZentrenRestaurantketteElektrotechnikOnlineshopLebensmittelherstellerMetalltechnikElektronikhersteller

Echtes BeispielDie Website eines echten deutschen Unternehmens, am 24. Okt. 2026 mit dem kostenlosen Schnellcheck geprüft. Name und Adresse entfernt.

Startseite · 24. Okt. 2026

guss-und-antrieb.example

Das war ein schneller, automatisierter Check: Er prüft Kontraste, Größen, Ladezeit und Struktur, aber noch nicht, wie dein Design wirkt, wie gut die Texte funktionieren oder wie leicht sich Aufgaben erledigen lassen – das liefert erst ein vollständiger Check mit einer KI-Bewertung von Design, Texten und Abläufen. Mit 36 von 100 Punkten gibt es auf guss-und-antrieb.example einiges zu verbessern, vor allem bei einheitlichen Bezeichnungen in der Navigation, der Lesbarkeit der Texte und den Kontrasten – da würde ich zuerst ansetzen.

kritisch
4
wichtig
7
gering
14
Geprüft52%Schnell-Audit
36von 100Schwach6 wirksame Verbesserungen, die in Minuten erledigt sind

Bewertung nach Bereich

Wenn du nur drei Dinge machst

  1. Links heißen mal so, mal so

    Wenn derselbe Klick mal „Suche“, mal „DE“ heißt, verliert dein Besucher das Vertrauen in die Navigation und klickt unsicherer.

    Lösung→Leg für jede Seite genau einen Namen fest und verwende ihn überall – im Menü, in Buttons und in der Fußzeile. Räum doppelte oder wechselnde Bezeichnungen aus den oben genannten Bereichen auf.

  2. Fließtext ist schwer zu lesen

    Lange Zeilen und dünne Schrift ermüden beim Lesen, besonders auf dem Handy, und viele Besucher brechen dann einfach ab.

    Lösung→Begrenze die Textbreite dieses Absatzes auf eine angenehme Zeilenlänge und wähle eine etwas kräftigere Schriftstärke.

  3. Text kaum lesbar auf Orange

    Für Menschen mit eingeschränktem Sehvermögen oder bei Sonnenlicht auf dem Handy ist dieser Text kaum zu entziffern.

    Lösung→Mach die Schrift auf den orangen Buttons dunkler oder wähle einen dunkleren Orangeton als Hintergrund, bis der Kontrast deutlich stärker wird.

SEO

Schwach 30/100

Eine deiner Seiten sagt Suchmaschinen aktiv, sie nicht aufzunehmen, und 16 Seiten haben keine Meta-Beschreibung – das kostet dich Sichtbarkeit in der Suche.

  • kritisch

    Seite für Suchmaschinen gesperrt

    Die geprüfte Seite ist per robots-Meta-Angabe auf „noindex, follow“ gesetzt, und keine der 16 gecrawlten Seiten taucht in der Sitemap auf. Seiten, die Suchmaschinen nicht indexieren dürfen oder nicht in der Sitemap stehen, erscheinen schlicht nicht in den Suchergebnissen.

    Lösung→Lass prüfen, ob die noindex-Einstellung wirklich gewollt ist, und sorg dafür, dass deine wichtigen Seiten in einer Sitemap gelistet sind, die in der robots.txt verlinkt wird.

    Für deine Entwickler

    Entferne das noindex aus dem robots-Meta-Tag der betroffenen Seite, erzeuge eine vollständige XML-Sitemap mit allen 16 gecrawlten Seiten und referenziere sie in der robots.txt; außerdem fehlt bei einer Seite der self-canonical.

    • robots: noindex,follow
    • pages with canonical: 15 of 16
    • crawled pages listed in sitemap: 0 of 16

    Google Search Central: SEO Starter Guide

  • wichtig

    Startseite braucht zu lange zum Laden

    Die Startseite braucht auf dem Handy rund 4,3 Sekunden, bis das Hauptbild sichtbar ist – das Ruckeln und Nachladen (Layout Shift) ist dagegen unauffällig. Suchmaschinen werten langsame Seiten ab und viele Besucher springen vorher schon ab.

    Lösung→Lass dein größtes Bild im sichtbaren Bereich verkleinern und früher laden, und reduziere Skripte, die nicht sofort gebraucht werden.

    Für deine Entwickler

    LCP (mobil, Lab) liegt bei 4290 ms, Ziel ≤2500 ms, CLS ist mit 0 und TBT mit 17 ms unkritisch. Größtes Above-the-fold-Bild komprimieren und per preload laden, nicht kritisches JavaScript deferren.

    • LCP (lab, mobile): 4290.55 ms (target 2500)
    • CLS: 0 (target 0.1)
    • Total Blocking Time (lab, stands in for INP): 17 ms (target 200)

    web.dev: Core Web Vitals thresholds (LCP 2.5 s, INP 200 ms, CLS 0.1)

  • gering

    Viele Seiten ohne Meta-Beschreibung

    16 Seiten deiner Website haben keine Meta-Beschreibung hinterlegt. Titel und Beschreibung sind deine Werbeanzeige in der Google-Suche – fehlen sie, bekommst du weniger Klicks.

    Lösung→Schreibe für jede wichtige Seite eine eigene, kurze Beschreibung von etwa 120 bis 160 Zeichen, die zum Klicken einlädt.

    Für deine Entwickler

    Für die betroffenen 16 Seiten ein eindeutiges meta name="description" mit 120–160 Zeichen ergänzen; sicherstellen, dass keine Duplikate zwischen Seiten entstehen und Title-Tags das Hauptthema vor der Marke nennen.

    • No meta description

    Google Search Central: Influencing title links in search results

  • gering

    Suchmaschinen fehlt der Kontext zu deinem Betrieb

    Auf der Seite gibt es keine strukturierten Daten (sogenanntes Schema-Markup). Google muss also selbst erraten, dass [Marke] ein Unternehmen mit Produkten wie „Feinguss“, „Sandguss“ oder „Schmiede“ ist. Ohne diese Angaben verpasst du die Chance auf ansprechendere Suchergebnisse mit Zusatzinfos wie Logo oder Kontaktdaten.

    Lösung→Lass deinen Entwickler grundlegende Unternehmensdaten (Name, Logo, Kontakt, Produkte) in einem maschinenlesbaren Format hinterlegen, das Google versteht.

    Für deine Entwickler

    JSON-LD für Organization sowie Product/Offer für die Kernprodukte (Feinguss, Sandguss, Schmiede etc.) ergänzen, mit name, logo, url, sameAs und Kontaktdaten, anschließend mit Googles Rich Results Test validieren.

    • JSON-LD blocks: 0

    Google Search Central: Structured data general guidelines

  • gering

    Geteilte Links zeigen keine Vorschau

    Wenn jemand eine Seite von guss-und-antrieb.example auf WhatsApp, LinkedIn oder Facebook teilt, erscheint kein Titel, keine Beschreibung und kein Bild – es fehlen die entsprechenden Vorschau-Angaben. Links ohne Bild und Beschreibung wirken weniger vertrauenswürdig und werden seltener angeklickt.

    Lösung→Lass für die wichtigsten Seiten einen Vorschautitel, eine kurze Beschreibung und ein passendes Bild hinterlegen, am besten im Format 1200 mal 630 Pixel.

    Für deine Entwickler

    Open-Graph- und Twitter-Card-Tags (og:title, og:description, og:image) auf allen Kernseiten ergänzen, og:image mindestens 1200×630 px, und mit einem Link-Preview-Tool prüfen.

    • No og:title
    • No og:description
    • No og:image

    Google Search Central: SEO Starter Guide

  • gering

    Bilder bremsen deine Ladezeit

    Auf deiner Startseite werden Bilder nicht optimal ausgeliefert – das kostet laut Analyse etwa 130 KB an unnötiger Datenmenge, die Besucher zusätzlich laden müssen. Schwere Bilder verlangsamen jede Seite, besonders auf dem Handy mit mobilen Daten, und das kann Besucher vor dem vollständigen Laden abspringen lassen.

    Lösung→Lass deine Bilder in einem modernen, platzsparenden Format (wie WebP) speichern, in der tatsächlich angezeigten Größe einbinden und Bilder weiter unten auf der Seite erst beim Scrollen nachladen.

    Für deine Entwickler

    Bilder als WebP/AVIF ausliefern, auf die tatsächliche Anzeigegröße skalieren, width/height-Attribute setzen und für Bilder unterhalb des sichtbaren Bereichs loading="lazy" ergänzen; geschätztes Einsparpotenzial laut Audit: 130 KiB.

    • Improve image delivery (Est savings of 130 KiB)

    Google Search Central: SEO Starter Guide

Barrierefreiheit

Schwach 34/100

Ich habe 9 Elemente mit zu schwachem Kontrast gefunden, dazu einen Link ohne erkennbaren Namen und ein Bedienelement, das sich nicht per Tastatur erreichen lässt – das sind Hürden, die sich gut beheben lassen.

  • kritisch

    Text kaum lesbar auf Orange

    Die Buttons „Mehr über [Marke] erfahren“ und „Karriere bei [Marke] erkunden“ zeigen weißen Text auf orangem Hintergrund mit nur 3,13:1 Kontrast, nötig wären 4,5:1. Der Button „Weiterlesen“ ist ebenfalls betroffen. Für Menschen mit eingeschränktem Sehvermögen oder bei Sonnenlicht auf dem Handy ist dieser Text kaum zu entziffern.

    Lösung→Mach die Schrift auf den orangen Buttons dunkler oder wähle einen dunkleren Orangeton als Hintergrund, bis der Kontrast deutlich stärker wird.

    Für deine Entwickler

    Passe Textfarbe #ffffff auf Hintergrund #f56405 an, z. B. auf #292929, oder dunkle den Hintergrund ab, bis mindestens 4.5:1 erreicht ist; betrifft .btn-primary.btn und .btn-outline-primary.btn.

    • p:nth-child(5) > .btn-primary.btn · "Mehr über [Marke] erfahren": #ffffff on #f56405 is 3.13:1, needs 4.5:1 (try #292929)
    • .textmedia-centered > .textmedia-text.textmedia-item > p:nth-child(3) > .btn-primary.btn · "Karriere bei [Marke] erkunden": #ffffff on #f56405 is 3.13:1, needs…
    • .article.articletype-0.article--news:nth-child(1) > .article__body.news__body > .btn-group-action > .btn-outline-primary.btn[target="_self"] · "Weiterlesen": #…

    WCAG 2.2 SC 1.4.3, 1.4.11

  • kritisch

    Logo-Link ohne Namen

    Das Logo oben links, das zur Startseite führt, hat keinen Text, den Screenreader vorlesen können. Nutzer mit Screenreader hören bei diesem Link nur „Link“ ohne jede Information, wohin er führt.

    Lösung→Gib dem Logo-Link eine unsichtbare Beschriftung wie „Zur Startseite“, damit er für alle verständlich ist.

    Für deine Entwickler

    Ergänze .header__logo-link um aria-label="Zur Startseite" oder sichtbaren, aber visuell ausgeblendeten Text, da der Screenreader derzeit keinen zugänglichen Namen findet.

    • .header__logo-link · Element does not have text that is visible to screen readers

    WCAG 2.2 SC 4.1.2, 2.5.3

  • wichtig

    Tastatur-Fokus unsichtbar

    Von 64 bedienbaren Elementen zeigen 49 keinen sichtbaren Rahmen, wenn man per Tastatur zu ihnen springt – darunter „Suche“, der Sprachumschalter „DE“ sowie die Icon-Links zu „Feinguss“ und „Sandguss“. Wer ohne Maus navigiert, sieht so nicht, wo er sich gerade auf der Seite befindet, und verliert die Orientierung.

    Lösung→Sorg dafür, dass jedes klickbare Element beim Durchtabben einen gut sichtbaren Rahmen oder eine andere deutliche Markierung bekommt.

    Für deine Entwickler

    Definiere eine konsistente :focus-visible-Regel (z. B. 2px Outline mit mindestens 3:1 Kontrast) für alle interaktiven Elemente, da aktuell 49 von 64 Fokus-Stopps ohne sichtbare Änderung bleiben und 10 zusätzlich von anderen Elementen verdeckt werden.

    • #meta-item-26 · No visible focus change: "Suche"
    • #language_menu > li.active:nth-of-type(2) > a · No visible focus change: "DE"
    • div.frame-group-inner > div.frame-container > div.frame-inner > div.icongroup:nth-of-type(2) > a.icongroup-item:nth-of-type(1) · No visible focus change: "Fein…
    • div.frame-group-inner > div.frame-container > div.frame-inner > div.icongroup:nth-of-type(2) > a.icongroup-item:nth-of-type(2) · No visible focus change: "Sand…

    WCAG 2.2 SC 2.4.7, 2.4.11

  • kritisch

    Logo per Tastatur nicht erreichbar

    Beim Durchtabben der Seite bleibt das Logo oben links nicht in der Reihenfolge der klickbaren Elemente hängen – es lässt sich per Tastatur nicht ansteuern. Menschen, die ohne Maus surfen, kommen so nicht zur Startseite zurück und bleiben an dieser Stelle hängen.

    Lösung→Lass deinen Entwickler prüfen, warum das Logo links oben beim Tabben übersprungen wird, und sorge dafür, dass es wie jeder andere Link erreichbar ist.

    Für deine Entwickler

    #page-header > .container > a.header__logo-link ist derzeit nicht per Tab fokussierbar (tabindex oder DOM-Position prüfen). Sicherstellen, dass es als reguläres <a href> im natürlichen Tab-Flow liegt; ergänzend einen „Skip to content“-Link vor der Navigation einfügen.

    • focus stops: 64
    • unreachable controls: 1 (target 0)
    • backward jumps: 0 (target 1)
    • #page-header > div.container > a.header__logo-link · Not reachable with Tab: ""

    WCAG 2.2 SC 2.1.1, 2.1.2

  • gering

    Navigation sieht auf jeder Seite anders aus

    Auf allen 15 geprüften Seiten unterscheidet sich die Reihenfolge der Navigation von der Startseite. Wenn sich die Navigation ständig verschiebt, verlieren Besucher die Orientierung, besonders wenn sie sich auf Gedächtnis oder Hilfstechnologien wie Screenreader verlassen.

    Lösung→Sorge dafür, dass das Hauptmenü auf jeder Seite in derselben Reihenfolge und an derselben Stelle erscheint.

    Für deine Entwickler

    Navigationsmarkup und Reihenfolge der Menüpunkte über alle Templates hinweg vereinheitlichen; sicherstellen, dass Fokus oder Eingabe in Formularfeldern keine unerwarteten Kontextwechsel auslöst.

    • Navigation differs from the homepage

    WCAG 2.2 SC 3.2.1, 3.2.2

  • gering

    Überschriften-Reihenfolge springt

    Nach einer H2-Überschrift folgt direkt eine H5-Überschrift „Unternehmen“, ohne H3 und H4 dazwischen. Außerdem gibt es eine H3-Überschrift ohne für Screenreader sichtbaren Text. Menschen, die mit Screenreadern navigieren, springen anhand der Überschriften-Hierarchie durch die Seite – übersprungene Ebenen und leere Überschriften machen die Seite für sie schwer durchschaubar.

    Lösung→Prüfe die Überschriften-Reihenfolge und schließe die Lücke zwischen H2 und der Überschrift „Unternehmen“, zum Beispiel mit einer H3 dazwischen. Ergänze außerdem sichtbaren Text bei der leeren H3.

    Für deine Entwickler

    Heading-Hierarchie korrigieren, sodass auf h2 direkt h3 folgt statt h5 bei „Unternehmen“; der betroffenen h3 zugänglichen Textinhalt geben, der von Screenreadern vorgelesen wird.

    • h1 count: 1 (target 1)
    • Skipped heading level: h2 → h5 "Unternehmen"
    • h3 · Element does not have text that is visible to screen readers

    WCAG 2.2 SC 1.3.1, 1.3.2

UI

Schwach 43/100

Deine Textzeilen sind mit rund 168 Zeichen deutlich zu lang und die Schrift wirkt sehr dünn – das strengt beim Lesen an, besonders auf größeren Bildschirmen.

  • wichtig

    Fließtext ist schwer zu lesen

    Im Textabschnitt unter dem Bild-Text-Modul ist der Absatz etwa 168 Zeichen pro Zeile lang und sehr dünn geschrieben – das ist deutlich mehr als die empfohlenen 45 bis 75 Zeichen. Lange Zeilen und dünne Schrift ermüden beim Lesen, besonders auf dem Handy, und viele Besucher brechen dann einfach ab.

    Lösung→Begrenze die Textbreite dieses Absatzes auf eine angenehme Zeilenlänge und wähle eine etwas kräftigere Schriftstärke.

    Für deine Entwickler

    Setze für div.textmedia-item p eine max-width von ca. 65ch, erhöhe font-weight von 100 auf mindestens 400 und prüfe line-height im Bereich 1.4–1.6.

    • div.frame-container > div.frame-inner > div.textmedia > div.textmedia-item > p:nth-of-type(1) · ✓ body 16px (desktop) · ✓ body 16px (mobile) · ✗ ≈168 character…

    Matthew Butterick: Practical Typography — line length, point size, line spacing

  • gering

    Große Überschriften wirken zu locker gesetzt

    Alle sieben großen Überschriften deiner Seite – etwa „Wir schaffen Lösungen - für anspruchsvolle Aufgaben.“ und „[Marke] auf einen Blick“ – haben einen zu weiten Buchstaben- und Zeilenabstand. Das lässt große Überschriften unfertig und auseinandergezogen wirken, statt kraftvoll und lesbar.

    Lösung→Lass bei großen Überschriften den Buchstabenabstand etwas enger und den Zeilenabstand kompakter einstellen, damit sie wie aus einem Guss wirken.

    Für deine Entwickler

    Für Text ab 32px letter-spacing auf 0 bis -0.02em setzen und line-height auf 1.0–1.2 reduzieren, z. B. bei h1 und h2 im Header-Bereich.

    • div.frame-inner > div.textmedia > div.textmedia-item > div.frame-header > h1 · 61px, letter-spacing 0.57px, line-height 73.2px: "Wir schaffen Lösungen - für an…
    • div.frame-container > div.frame-inner > div.textmedia > div.textmedia-item > h2.text-center · 40px, letter-spacing 0.57px, line-height 48px: "[Marke] auf einen…
    • div.frame-group-inner > div.frame-container > div.frame-inner > div.frame-header:nth-of-type(1) > h2 · 40px, letter-spacing 0.57px, line-height 48px: "Unsere P…

    Apple: Designing Fluid Interfaces (WWDC 2018)

  • gering

    Buttons reagieren erst spät auf Klicks

    Von den getesteten Bedienelementen reagiert nur etwa jedes sechste sofort beim Drücken. Links wie „Suche“, „Produkte“ und „Verfahren“ in der Navigation ändern sich erst, wenn du die Maustaste wieder loslässt. Verzögerte Rückmeldung lässt die Seite träge wirken, selbst wenn sie technisch schnell lädt.

    Lösung→Lass deinen Entwickler prüfen, ob Buttons und Menüpunkte direkt beim Klicken sichtbar reagieren können, nicht erst danach.

    Für deine Entwickler

    Pressed-States mit :active sofort beim Pointerdown auslösen statt erst nach Release, Menüs vom auslösenden Element aus öffnen und CSS-Transitions statt Keyframes verwenden, damit Animationen unterbrechbar sind.

    • #page-header > div.container > a.header__logo-link · "": changes on press (color, border-color)
    • #meta-item-26 · "Suche": no change until release
    • #nav-item-160 · "Produkte": no change until release
    • #nav-item-1076 · "Verfahren": no change until release

    Apple: Designing Fluid Interfaces (WWDC 2018)

  • gering

    Schriftgrößen wirken etwas zufällig

    Auf der Seite werden drei Schriftfamilien und acht verschiedene Schriftgrößen verwendet, von denen nur 88 Prozent sauber zueinander passen. Zu viele unterschiedliche Schriftgrößen lassen die Seite weniger durchdacht wirken und erschweren es, Überschriften von Fließtext zu unterscheiden.

    Lösung→Beschränke dich auf höchstens zwei Schriftarten und definiere eine feste Reihe von sechs bis acht Größen, die bei allen Texten konsequent verwendet wird.

    Für deine Entwickler

    Font-Familien auf maximal zwei reduzieren (aktuell FS-Matthew, FS-Matthew-light, FS-Matthew-bold im Einsatz) und alle Textstile auf eine modulare Skala mit 6–8 Stufen (z. B. 14/16/20/25/31/39 px) abbilden.

    • font families (excl. icons): 3
    • distinct font sizes: 8 (target 8)
    • sizes on a modular scale: 88 %
    • Families: FS-Matthew-light, FS-Matthew-bold, FS-Matthew

    Adam Wathan & Steve Schoger: Refactoring UI — hierarchy, spacing systems, limited palettes

  • gering

    Abstände folgen keinem klaren Raster

    Nur 65 Prozent der Abstände auf der Seite orientieren sich an einem einheitlichen 4-Pixel-Raster, und Textblöcke beginnen an zehn verschiedenen linken Kanten statt an wenigen festen Linien. Uneinheitliche Abstände lassen ein Layout unbewusst unruhig wirken, auch wenn Besucher nicht genau sagen können, warum.

    Lösung→Lege eine einheitliche Abstandsskala fest (zum Beispiel 8, 16, 24, 32, 48, 64 Pixel) und richte Textblöcke konsequent an denselben wenigen linken Kanten aus.

    Für deine Entwickler

    Spacing-Werte auf ein 4- oder 8-px-Raster mit definierten Stufen (8, 16, 24, 32, 48, 64) vereinheitlichen und die Zahl der linken Text-Ausrichtungskanten in der Hauptspalte von 10 auf höchstens 4 reduzieren.

    • spacing on 4 px grid: 65 % (target 80)
    • distinct left text edges: 10 (target 4)

    Adam Wathan & Steve Schoger: Refactoring UI — hierarchy, spacing systems, limited palettes

  • gering

    Animationen könnten ruckeln

    Sechs Animationen auf der Seite, etwa bei Menüpunkten der Navigation, verändern die Position über die Top-Eigenschaft statt über eine ruckelfreie Technik. Die Seite selbst springt beim Laden nicht (kein Layout-Sprung gemessen). Animationen, die Layout-Eigenschaften bewegen, laufen besonders auf günstigeren Smartphones oft stockend statt flüssig.

    Lösung→Lass die Navigationsanimationen technisch so umbauen, dass sie Elemente verschieben, statt ihre Position über das Layout zu ändern.

    Für deine Entwickler

    Animationen von top/left/margin (u. a. auf #nav-item-160, #nav-item-313) auf transform/opacity umstellen, damit sie vom Compositor statt vom Layout-Thread berechnet werden; CLS liegt aktuell bereits bei 0.

    • CLS: 0 (target 0.1)
    • #nav-item-160 · Animates top
    • #nav-item-313 · Animates top

    Apple: Designing Fluid Interfaces (WWDC 2018)

Texte

Ausbaufähig 57/100

Mit durchschnittlich 34 Wörtern pro Satz und einem niedrigen Lesbarkeitswert liest sich deine Startseite eher wie ein Fachbericht als wie eine Einladung.

  • wichtig

    Texte sind schwer zu lesen

    Die Sätze auf der Seite sind im Schnitt 34 Wörter lang, und der Lesbarkeitswert (Amstad) liegt deutlich im negativen Bereich statt bei den angestrebten mindestens 60 Punkten. Lange, verschachtelte Sätze kosten dich Leser, selbst Fachpublikum liest auf dem Handy lieber kurze, klare Sätze.

    Lösung→Teile lange Sätze in kürzere auf, nutze einfachere Wörter statt Fachbegriffe und schreibe aktiv statt passiv. Erkläre Fachbegriffe beim ersten Auftreten.

    Für deine Entwickler

    Automatisierte Lesbarkeitsmessung ergibt Amstad -14,38 (Ziel ≥60) und durchschnittlich 34 Wörter pro Satz (Ziel ≤20). Texte redaktionell überarbeiten: Satzlänge auf unter 20 Wörter kürzen, Passivkonstruktionen reduzieren, Fachbegriffe beim ersten Vorkommen erläutern.

    • Amstad (Flesch, German): -14.38
    • average sentence length: 34 words (target 20)

    plainlanguage.gov: Federal Plain Language Guidelines

  • gering

    Mehr „wir“ als „du“ auf der Startseite

    Auf deiner Startseite kommt „wir“ 13-mal vor, „du“ beziehungsweise „dein“ nur 9-mal. Besucher interessieren sich zuerst für ihr eigenes Anliegen, nicht für dein Unternehmen – zu viel „wir“ lässt den Text firmenzentriert wirken.

    Lösung→Formuliere zentrale Abschnitte stärker aus Sicht deiner Besucher: Beginne mit dem, was sie bekommen, und erst danach, was ihr dafür tut.

    Für deine Entwickler

    Content-Review der Startseitentexte (insb. Hero- und Übersichtsbereiche): Reader-Pronomen („Sie“/„Ihre“) vor Company-Pronomen („wir“/„unsere“) priorisieren, Ziel-Verhältnis mindestens 1:1.

    • reader words: 9
    • company words: 13

    Government Digital Service: GOV.UK content design: writing for the web

  • gering

    Ein Link sagt nicht, wohin er führt

    Der Link „Weiterlesen“ in einem Artikel im Newsbereich beschreibt nicht, worum es im verlinkten Inhalt geht. Vage Linktexte wie „Weiterlesen“ lassen Besucher zögern, weil sie nicht wissen, was sie erwartet.

    Lösung→Ersetze „Weiterlesen“ durch einen konkreten Text, der sagt, was im Artikel steht, zum Beispiel den Titel der Meldung.

    Für deine Entwickler

    Linktext des Elements .btn in .article__body (News-Teaser) von „Weiterlesen“ auf einen beschreibenden Text mit Verb + Objekt ändern, der den Zielinhalt benennt.

    • #news-container-8541 > div.article:nth-of-type(1) > div.article__body > div.btn-group-action:nth-of-type(4) > a.btn · "Weiterlesen" → https://guss-und-antrieb.example/d…

    WCAG 2.2 SC 2.4.4

UX

Noch nicht geprüft 29 % gemessen

Ich habe gesehen, dass 16 Linktexte auf deiner Seite zu Zielen führen, die unter anderen Namen schon woanders verlinkt sind – das macht es Besuchern schwer, sich zu orientieren. Lass uns das als Erstes angehen.

  • wichtig

    Links heißen mal so, mal so

    Dieser schnelle, automatische Check hat 24 Zielseiten gefunden, die unter unterschiedlichen Namen verlinkt sind. Zum Beispiel taucht „Suche“ 15-mal auf, aber auch als „Suche current“ oder „DE“ für dieselbe Funktion, und „Produkte“ führt an 30 Stellen zum gleichen Ziel, einmal aber heißt der Link „Produkte und Verfahren“. Auch bei „Gussteile“, „Alles über [Marke]-Gussteile“ und den Schmiede-Unterseiten wechseln die Bezeichnungen ständig. Wenn derselbe Klick mal „Suche“, mal „DE“ heißt, verliert dein Besucher das Vertrauen in die Navigation und klickt unsicherer.

    Lösung→Leg für jede Seite genau einen Namen fest und verwende ihn überall – im Menü, in Buttons und in der Fußzeile. Räum doppelte oder wechselnde Bezeichnungen aus den oben genannten Bereichen auf.

    Für deine Entwickler

    Vereinheitliche Linktexte pro Ziel-URL über alle Templates hinweg (Hauptnavigation, Footer, Breadcrumbs); betroffen sind u.a. Suche-Icon, Sprachumschalter „DE“ und die Produkt-/Gussteile-Menüs mit teils 16 abweichenden Label-Varianten pro Ziel.

    • "suche" ×15, "suche current" ×1, "de" ×1, "eingaben löschen" ×1, "vorherige" ×1
    • "produkte" ×30, "produkte und verfahren" ×1, "produkte current" ×2, "de" ×1
    • "gussteile" ×32, "alles über [Marke]gussteile" ×15, "vakuum feinguss" ×16, "offener feinguss" ×16, "sandguss" ×16, "croningguss maskenguss" ×16, "keramikguss"…
    • "alles über [Marke]schmiedeteile" ×15, "gesenkschmiedeteile" ×16, "ringe nahtlos gewalzt" ×16, "buchsen nahtlos geschmiedet" ×16, "einzelstücke kleinserien gro…

    Jakob Nielsen, NN/g: 10 Usability Heuristics for User Interface Design

  • wichtig

    Erste Aktion liegt zu weit unten, Buttons zu klein

    Auf dem Handy muss man erst gut drei Bildschirmlängen scrollen, bevor der erste auffällige Button („Akzeptieren“ im Cookie-Hinweis) erscheint, und das Menü-Symbol oben rechts sowie die Cookie-Buttons „Ablehnen“ und „Akzeptieren“ sind mit 34 bis 42 Pixel etwas kleiner als empfohlen. Die meisten Besucher kommen über das Handy, und zu kleine oder zu weit entfernte Tasten machen die mobile Seite mühsamer zu bedienen.

    Lösung→Vergrößere die wichtigsten Buttons auf mindestens 44 Pixel Höhe, vor allem das Menü-Symbol und die Cookie-Buttons, und bring die wichtigste Handlung weiter nach oben.

    Für deine Entwickler

    Navbar-Toggler (34px) und Cookie-Buttons .cm-btn (42px) auf min-height 44px anheben; Cookie-Banner-Buttons weiter oben im Viewport platzieren oder früher einblenden, damit die erste Primäraktion nicht erst bei 3,3 Screens Scrolltiefe liegt.

    • div > div.klaro > div.context-notice > p.cm-buttons:nth-of-type(2) > button.cm-btn:nth-of-type(1) · First prominent action "Akzeptieren" at 3.3 screens down, 2…
    • #page-header > div.container > button.navbar-toggler · 34px tall: ""
    • div.cookie-notice > div.cn-body > div.cn-ok > div.cn-buttons > button.cm-btn:nth-of-type(1) · 42px tall: "Ablehnen"
    • div.cookie-notice > div.cn-body > div.cn-ok > div.cn-buttons > button.cm-btn:nth-of-type(2) · 42px tall: "Akzeptieren"

    NN/g: Mobile UX guidelines (touch targets, content priority)

  • gering

    Keine Brotkrumen auf tieferen Seiten

    Die Navigation markiert zwar auf allen 15 Seiten zuverlässig, wo man sich befindet, aber auf den 14 tieferen Seiten wie etwa unter „Produkte“ > „Gussteile“ fehlt eine Brotkrümelnavigation, die den Weg zurück zeigt. Wer über eine Suche oder einen geteilten Link direkt auf einer tiefen Seite landet, kann so schwerer nachvollziehen, wo er sich befindet und wie er zurückfindet.

    Lösung→Ergänze auf den tieferen Produktseiten eine kleine Pfadanzeige oben auf der Seite, die zeigt, über welche Kategorien man dorthin gelangt ist.

    Für deine Entwickler

    0 von 14 Seiten mit Verschachtelungstiefe ≥3 haben Breadcrumbs. Breadcrumb-Komponente mit strukturierten Daten (schema.org BreadcrumbList) auf allen Seiten ab Ebene 3 ergänzen, aktuelle Seite weiterhin mit aria-current="page" im Hauptmenü markieren.

    • pages where nav marks the current page: 15 of 15
    • Logo/home link in the header on every page
    • deep pages with breadcrumbs: 0 of 14

    Jakob Nielsen, NN/g: 10 Usability Heuristics for User Interface Design

Conversion

Noch nicht geprüft 11 % gemessen

Mit 4,3 Sekunden bis zum Laden des Hauptinhalts und fast 8 Megabyte Datenvolumen auf dem Handy wartest du deine Besucher länger als dir lieb sein kann.

  • wichtig

    Seite ist viel zu schwer für mobile Nutzer

    Die Startseite lädt auf dem Handy 7,9 Megabyte an Daten und braucht 4,3 Sekunden, bis das Hauptbild erscheint – beides deutlich über dem, was für eine gute mobile Erfahrung empfohlen wird. Auf dem Handy kostet jede zusätzliche Sekunde Ladezeit potenzielle Anfragen und Kunden.

    Lösung→Lass Bilder komprimieren, nicht benötigte Skripte und Schriften entfernen und Inhalte unterhalb des sichtbaren Bereichs erst bei Bedarf nachladen.

    Für deine Entwickler

    Landingpage: LCP mobil 4290 ms (Ziel ≤2500) und Seitengewicht 7,93 MB (Ziel ≤2 MB). Bilder komprimieren/responsive ausliefern, ungenutzte Scripts/Fonts entfernen, Lazy-Loading für Below-the-fold-Inhalte einführen.

    • LCP (mobile, lab): 4290.55 ms (target 2500)
    • page weight: 7.93 MB (target 2)

    web.dev: Core Web Vitals thresholds (LCP 2.5 s, INP 200 ms, CLS 0.1)

Dein 30-Minuten-Plan

0 von 15 erledigt

Kleine Änderungen mit großer Wirkung. Hak sie nach und nach ab.

Das war’s von mir. Mach ein paar Änderungen, lass mich noch mal ran, und ich zeige dir, was sich bewegt hat.

Eigenes Audit starten