Website auf iPhone Safari fehlerhaft? Ursachen und Lösungen

Bei Talha Aslan und Team hören wir diese Beschwerde sehr oft: „Bei mir passt alles, aber auf dem iPhone des Kunden ist alles verschoben.“ Der entscheidende Punkt: Alle Browser auf dem iPhone, Chrome eingeschlossen, nutzen WebKit. Deshalb liefert Chrome auf dem iPhone nicht dasselbe Ergebnis wie Chrome auf Android.

Dieser Beitrag konzentriert sich auf eine einzige Frage. Warum bricht die Seite auf iPhone Safari, und in welcher Reihenfolge beheben Sie das? Allgemeine Probleme auf dem Smartphone behandeln wir im Beitrag zu mobilen SEO Fehlern, die nur am Handy auftreten. Hier bleiben wir bei Safari.

Liegt das Problem wirklich an Safari?

Zunächst kommt die Diagnose. „Auf dem iPhone kaputt“ beschreibt oft drei verschiedene Probleme: einen echten WebKit Unterschied, einen responsiven Fehler bei schmaler Breite oder eine veraltete Datei im Cache. Daher grenzen Sie das Problem zuerst ein.

1. Öffnen Sie dieselbe Seite auf einem Android Smartphone und in der Geräteansicht Ihres Desktop Browsers.
2. Zeigt nur das iPhone den Fehler, testen Sie zuerst Safari und dann einen zweiten Browser auf dem iPhone.
3. Tritt der Fehler in beiden iPhone Browsern auf, liegt die Ursache fast sicher bei WebKit.
4. Bricht auch Android bei schmaler Breite, liegt es an den Breakpoints und nicht an Safari.
5. Laden Sie die Seite im privaten Tab neu, damit Sie alte Cachedateien ausschließen.

Geht es um die Breite, hilft unser Leitfaden, wie Sie Breakpoints im responsiven Webdesign festlegen. Betrifft der Fehler dagegen nur iPhones, prüfen Sie die folgenden Ursachen der Reihe nach.

Welches Symptom deutet auf welche Ursache hin?

Wer das Symptom richtig benennt, spart viel Zeit bei der Reparatur. Zum Beispiel deutet „der untere Button fehlt“ meist auf eine Höheneinheit hin. „Die Seite zoomt von selbst“ betrifft dagegen meist die Schriftgröße eines Formularfelds. Die Tabelle fasst die Zuordnungen zusammen, die wir in der Praxis am häufigsten sehen.

Geben Sie Ihren Entwicklern außerdem das iPhone Modell und die iOS Version an. Kurz gesagt: Screenshot plus Geräteangaben bringen schneller ein Ergebnis als stundenlanges Raten.

Warum ragt 100vh auf iPhone Safari über den Bildschirm hinaus?

Das ist die mit Abstand häufigste Ursache. Viele Websites setzen den Startbereich auf 100 Prozent der Viewport Höhe. Allerdings blenden mobile Browser Adressleiste und Toolbar beim Scrollen ein und aus. Laut der Erklärung von web.dev zu Viewport Einheiten aktualisiert sich die Einheit vh nicht, wenn sich diese Leisten verändern.

Folglich ragt ein 100vh Bereich beim ersten Laden, also bei sichtbaren Leisten, über den sichtbaren Bereich hinaus. Der Button „Angebot anfordern“ oder „Jetzt anrufen“ liegt dann außerhalb des Bildschirms. Erst wenn die Besucherin scrollt und die Leiste schrumpft, passt der Bereich. Zudem wirkt diese Verschiebung wie ein Zucken des Inhalts.

Auf iPhone Safari fällt der Effekt besonders auf, denn die Leisten bewegen sich dort beim Scrollen stark. Android Browser zeigen teils ein ähnliches Verhalten. Trotzdem testen viele Teams am Desktop, deshalb kommt die erste Meldung meist von einem iPhone Nutzer.

Wie lösen dvh, svh und lvh das Höhenproblem?

Die neuen Viewport Einheiten gibt es genau für diesen Fall. web.dev beschreibt drei Varianten:

• svh (small viewport): 1 Prozent des sichtbaren Bereichs bei eingeblendeten Leisten. Der Wert bleibt stabil.
• lvh (large viewport): 1 Prozent des sichtbaren Bereichs bei ausgeblendeten Leisten. Auch dieser Wert bleibt stabil.
• dvh (dynamic viewport): wechselt zwischen beiden Werten, sobald sich die Leisten ein oder ausblenden.

In der Praxis ist svh für den Startbereich meist die sicherste Wahl. Denn so bleibt der wichtigste Button beim ersten Laden sichtbar, und beim Scrollen findet keine Neuberechnung statt. dvh füllt den sichtbaren Bereich dagegen in jedem Moment. Allerdings ändert sich die Größe mit jeder Bewegung der Leiste, daher wirken animierte Bereiche schnell unruhig.

Für ältere Browser schreibt unser Team immer zuerst einen vh Wert und danach die neue Einheit. Somit greift ein Browser ohne Unterstützung auf den alten Wert zurück. Den aktuellen Stand prüfen Sie bei MDN oder caniuse, denn Browserversionen ändern sich, und wir nennen hier bewusst keine Versionsnummern.

Warum zoomt die Seite beim Antippen eines Formularfelds?

Die zweithäufigste Beschwerde lautet so. Eine Besucherin tippt in das Namensfeld des Kontaktformulars, und die Seite zoomt plötzlich hinein. Nach dem Absenden bleibt die Ansicht vergrößert, und eine horizontale Scrollleiste erscheint. Auf iPhone Safari passiert das bei Eingabefeldern, Auswahllisten und Textbereichen mit kleiner Schrift.

Safari möchte damit kleinen Text lesbar machen. Hat die Gestaltung das Formular jedoch in einer kleinen, eleganten Schrift belassen, löst jedes Antippen den Zoom aus. Unsere Lösung aus der Praxis: Halten Sie die Schrift der Formularfelder auf dem Smartphone groß genug. Entwickler nutzen dafür häufig 16 Pixel oder mehr. Betrachten Sie diesen Wert als Startpunkt aus der Praxis, nicht als offizielle Grenze, und prüfen Sie ihn auf Ihrem eigenen Gerät.

Ein häufiger Fehler besteht darin, den Zoom im Viewport Tag komplett zu sperren. Das schadet der Barrierefreiheit, weil Menschen mit Sehschwäche den Text dann nicht mehr vergrößern können. Lösen Sie das Problem also über die Schriftgröße. Außerdem regelt die CSS Eigenschaft zur Textanpassung bei MDN einen anderen Mechanismus, nämlich die Textvergrößerung, und verhindert den Formularzoom nicht.

Warum springen fixe Kopfzeilen und untere Leisten?

Eine fixe Leiste unten mit „Anrufen“ oder WhatsApp, eine fixe Kopfzeile oder ein Cookiebanner machen auf iPhone Safari die meisten Probleme. Schrumpft die Toolbar beim Scrollen, schwebt die untere Leiste kurz und rastet dann wieder ein. Zudem verschiebt die eingeblendete Tastatur fixe Elemente oft an unerwartete Stellen.

Der Grund liegt im Bezugsbereich der fixen Positionierung. Bei geöffneter Tastatur schrumpft der sichtbare Viewport, der Layout Viewport bleibt jedoch gleich. Daher verschwindet ein unten fixiertes Element manchmal hinter der Tastatur oder hängt mitten auf dem Bildschirm.

Unsere praktische Checkliste:

• Blendet sich die untere Leiste auf Seiten mit Formularen aus, sobald die Tastatur erscheint?
• Verdeckt die Kopfzeile Inhalte, die direkt darunter liegen?
• Steckt die klebende Kopfzeile in einem Container mit overflow hidden? Dann funktioniert sticky überhaupt nicht.
• Überlappen sich Cookiebanner und untere Leiste?
• Berücksichtigt die untere Leiste den sicheren Bereich am unteren Rand?

Die meisten Punkte sind Gestaltungsentscheidungen. Anders gesagt: Fragen Sie vor jeder Codeänderung, ob das Element wirklich ständig sichtbar bleiben muss.

Warum schneidet die Notch Inhalte am Rand ab?

iPhones mit Notch oder Dynamic Island haben abgerundete Ecken, oben einen Kamerabereich und unten den Home Indikator. Laut dem offiziellen Leitfaden von WebKit steht die Einstellung für die Viewport Anpassung standardmäßig auf auto. Safari setzt Inhalte dann in den sicheren Bereich.

Probleme beginnen, wenn das Design für eine randlose Optik den Wert cover wählt. Der Inhalt füllt dann den ganzen Bildschirm. Allerdings können die runden Ecken und der Sensorbereich Teile eines Textes oder Buttons verdecken. Im Querformat liegt das Menüsymbol sogar manchmal hinter der Kamera.

WebKit empfiehlt die Funktion env() mit den vier Abstandswerten für den sicheren Bereich, also oben, rechts, unten und links, als Innenabstand. Zudem kombinieren Sie diese Werte mit max(), damit ein Mindestabstand bleibt und der Abstand auf keinem Gerät auf null fällt. Kurz gesagt: Nutzen Sie cover, dann ergänzen Sie immer den Safe Area Abstand. Ohne cover genügt das Standardverhalten meist.

Warum werden Zahlen auf dem iPhone zu blauen Links?

Lange Ziffernfolgen wie Preise, Bestellnummern, Steuernummern oder Datumsangaben erscheinen auf dem iPhone manchmal blau und unterstrichen. Tippt man darauf, bietet das Telefon einen Anruf an. Die Referenz von Apple zu Safari Meta Tags beschreibt das direkt: Safari auf iOS verwandelt Text im Format einer Telefonnummer standardmäßig in einen Anruflink.

Manchmal hilft das, manchmal zerstört es die Gestaltung. Zum Beispiel schadet eine blau dargestellte Artikelnummer sowohl der Marke als auch dem Vertrauen. Die Lösung hat zwei Schritte. Zunächst schalten Sie die Erkennung über das Meta Tag zur Formaterkennung ab. Dann markieren Sie Ihre echten Telefonnummern bewusst mit tel Links.

So bestimmen Sie selbst, welche Nummern anrufbar sind, und messen die Klicks. Wie Sie diesen Button aufbauen und Anrufe messen, zeigt unser Beitrag zum Click to Call Button auf der Website. Deshalb wiederholen wir das hier nicht.

Warum erscheinen Bilder auf dem iPhone nicht?

Lädt ein Bild auf Android, zeigt auf dem iPhone aber nur ein leeres Feld, liegt das meist am Format. Moderne Formate wie WebP und AVIF sparen Dateigröße. Allerdings kam die Unterstützung in älteren iOS Versionen später. Hat die Besucherin ihr Telefon nicht aktualisiert, sieht sie das Bild schlicht nie.

Bieten Sie deshalb bei modernen Formaten immer ein Ersatzformat an. Mit dem picture Element nennen Sie zuerst AVIF, dann WebP und zuletzt JPEG oder PNG. Der Browser wählt dann das erste Format, das er kennt. Prüfen Sie außerdem, ob Ihr Server den richtigen Dateityp meldet, denn ein falscher Typ bringt Safari leicht aus dem Tritt.

Den aktuellen Stand prüfen Sie bei caniuse, weil sich das Bild mit jeder iOS Version ändert. Beispielszenario: Ein Onlineshop lädt Kategoriebilder nur als AVIF hoch, und Kunden mit älteren iPhones sehen leere Kacheln. Mit einem Ersatzformat verschwindet das Problem, und die verlorenen Conversions hören auf.

Wie zerstören nicht unterstützte CSS Eigenschaften das Layout?

Manche CSS Eigenschaften erreichen Chrome früher als Safari. Ein Entwickler testet die neue Eigenschaft in Chrome am Desktop und sieht kein Problem. Kennt die iOS Version des iPhone Nutzers die Eigenschaft jedoch nicht, ignoriert der Browser die Regel komplett. Dann fällt das Grid auf eine Spalte zusammen, Abstände verschwinden, oder die Hintergrundunschärfe erscheint nie.

Diese Gruppen begegnen uns am häufigsten:

• Unterschiede bei gap in Flex Layouts älterer Versionen.
• Neuere Farbfunktionen und Farbmischung.
• Container Queries und relativ neue Selektoren wie has().
• Effekte wie Hintergrundunschärfe, die teils noch ein Präfix brauchen.
• Datums und Zeitfelder, die in Safari ganz anders aussehen.

Der Ansatz bleibt gleich. Zunächst schreiben Sie eine sichere Grundregel. Dann ergänzen Sie die neue Eigenschaft innerhalb einer Abfrage mit @supports. Somit erhalten Browser ohne Unterstützung ein schlichtes, aber sauberes Layout. Die Kompatibilitätstabelle am Ende jeder Seite bei MDN führt Safari und Safari auf iOS in getrennten Zeilen; prüfen Sie es dort.

Warum gibt es nur auf dem iPhone horizontales Scrollen?

Rutscht die Seite leicht zur Seite, ragt ein Element über den Bildschirm hinaus. Manche Android Browser verdecken diesen Überlauf. Auf iPhone Safari wackelt dagegen die ganze Seite seitlich, und das nervt beim Scrollen mit dem Daumen schnell.

Häufige Quellen sind Abschnitte mit Breitenangaben in Viewport Einheiten, die den Platz der Scrollleiste ignorieren. Auch lange Links oder E-Mail Adressen ohne Umbruch verursachen das. Ebenso Kartenreihen, die nicht schrumpfen, sowie eingebettete Karten oder Videos. Außerdem hinterlässt der oben beschriebene Formularzoom oft eine horizontale Scrollleiste.

Zur Diagnose suchen Sie das überstehende Element in den Entwicklertools und korrigieren seine Breite. overflow hidden am äußeren Container wirkt als schneller Flicken. Allerdings bricht diese Regel eine klebende Kopfzeile. Daher führt die Suche nach dem eigentlichen Element immer zu einem besseren Ergebnis.

Was ändert sich bei iPads und älteren iPhones?

Das Problem mit iPhone Safari endet nicht beim Telefon. Auf dem iPad fordert Safari bei vielen Websites standardmäßig die Desktopversion an. Deshalb greifen Ihre Regeln für Tabletbreiten dort womöglich nie, und das Menü erscheint im Desktoplayout mit kleinen Links, die sich schwer antippen lassen.

Bei älteren iPhones fallen zwei Faktoren auf. Erstens fehlt ohne aktuelles iOS oft die Unterstützung für neue CSS Eigenschaften und Bildformate. Zweitens sind kleine Modelle sehr schmal, daher laufen zweispaltige Karten über, die auf großen Bildschirmen gut aussehen.

Wir empfehlen drei Profile im Testplan:

• Ein aktuelles iPhone mit Notch oder Dynamic Island und neuestem iOS.
• Ein kleineres iPhone mit einer iOS Version, die einige Releases zurückliegt.
• Ein iPad mit Standardeinstellungen.

Dieses Trio bildet ein einfaches Startset. Trotzdem lohnt ein Blick in den Gerätebericht Ihres Analysetools, damit Sie die Testpriorität nach echten Daten festlegen.

Beeinflussen Dunkelmodus und Textgröße die Darstellung?

Manche Beschwerden stammen nicht vom Browser, sondern von den Systemeinstellungen. Zum Beispiel erscheinen Formularfelder, Scrollleisten oder die Datumsauswahl in unerwartet dunklen Farben, wenn das iPhone im Dunkelmodus läuft und Ihre Website kein Farbschema angibt. Dann steht ein dunkelgraues Eingabefeld auf weißem Grund, und das Design wirkt kaputt.

Ähnlich verhält es sich, wenn Nutzer die Textgröße in den Bedienungshilfen erhöht haben. Dann läuft Text aus Buttons mit fester Höhe heraus. Das ist kein Fehler des Browsers; es zeigt vielmehr, dass das Design zu starr ist. Innenabstand statt fester Höhe funktioniert deshalb besser.

Kurz gesagt: Notieren Sie beim Screenshot, ob das Gerät im Dunkelmodus lief und welche Textgröße eingestellt war. Dann kann Ihr Entwickler den Fehler unter gleichen Bedingungen nachstellen.

Warum sehen Schriften und Icons auf dem iPhone anders aus?

Schriften und Icons sorgen für einen weiteren häufigen Unterschied. Lädt etwa Ihre eigene Schrift nicht, greift Safari auf die Systemschrift zurück. Zeilenhöhen ändern sich, und Überschriften brechen auf zwei Zeilen um. Auch Menübuttons verschieben sich, weil der Text mehr Platz braucht.

Icons aus Emojis oder Sonderzeichen übernehmen die Emojidarstellung von Apple. Zudem wendet Safari eigene Standardstile auf Formularbuttons und Auswahllisten an. Hat das Design diese Stile nicht zurückgesetzt, erscheinen Buttons mit runden Ecken und Schatten.

Prüfen Sie diese Fragen:

• Lädt die Schriftdatei auf dem iPhone, oder sehen Sie die Systemschrift?
• Sitzen Menü und Buttontexte in Boxen mit fester Breite?
• Sind die Standardstile der Formularbuttons zurückgesetzt?
• Sind die Icons SVG Dateien oder Zeichen, die je nach Gerät variieren?

Keiner dieser Punkte macht eine Website allein unbrauchbar. Allerdings leidet die Markenwirkung, und Besucher bekommen einen nachlässigen Eindruck. Behandeln Sie diese Punkte also in der Feinschliffrunde.

Wie testen Sie iPhone Safari ohne Mac?

Nicht jeder hat einen Mac auf dem Schreibtisch, und trotzdem können Sie testen. Eine Regel gilt allerdings. Kein Browser unter Windows oder Android bildet das Verhalten von WebKit exakt nach. Die Geräteansicht im Desktop Browser simuliert nur die Bildschirmgröße und tauscht die Engine nicht aus.

Ihre Möglichkeiten im Überblick:

1. Leihen Sie sich ein echtes iPhone. Ideal sind zwei Geräte mit unterschiedlichen iOS Versionen.
2. Prüfen Sie cloudbasierte Testdienste mit echten Geräten. Diese übertragen entfernte iPhones in Ihren Browser.
3. Testen Sie Desktopwerkzeuge auf Basis der WebKit Engine. Die endgültige Entscheidung treffen Sie trotzdem am echten Gerät.
4. Bitten Sie den Nutzer direkt um Screenshot oder Bildschirmaufnahme sowie die iOS Version.
5. Mit Zugang zu einem Mac verbinden Sie das Telefon per Kabel und untersuchen die Seite live mit dem Web Inspector von Safari.

Für einen allgemeinen Layoutcheck nutzen Sie unseren Mobile Friendly Test und den Leitfaden, wie Sie die Mobilfreundlichkeit testen. Diese Werkzeuge finden Layoutprobleme. Für safarispezifische Unterschiede brauchen Sie jedoch die Schritte am echten Gerät.

In welcher Reihenfolge beheben Sie die Fehler?

Wer alles gleichzeitig repariert, erzeugt neue Fehler. Deshalb beginnt unser Team mit dem Problem, das die Conversion am stärksten bremst. Diese Reihenfolge funktioniert bei den meisten Firmenwebsites:

1. Höhe des Startbereichs: Liegt der Hauptbutton außerhalb des Bildschirms, beheben Sie das zuerst.
2. Formularzoom: Wird das Kontakt oder Angebotsformular mühsam, folgt das an zweiter Stelle.
3. Fixe untere Leiste und Kopfzeile: Verrutschen Anruf und WhatsApp Buttons, kommen sie als Drittes.
4. Bildformate: wenn Produkt oder Leistungsbilder leer bleiben.
5. Notch und Randabstände: wenn im Querformat Inhalte abgeschnitten sind.
6. Automatisch verlinkte Telefonnummern und kleinere CSS Unterschiede: die abschließende Feinschliffrunde.

Nach jedem Schritt testen Sie erneut auf demselben iPhone im privaten Tab. Leeren Sie außerdem Cache Plugin oder CDN. Sonst sehen Sie die Korrektur nicht und suchen womöglich nach der falschen Ursache.

Was tun Sie bei fertigen Themes oder Baukästen?

Bei fertigen Themes stammt ein Teil der Fehler aus dem Theme selbst. Hat der Autor den Startbereich etwa fest auf 100vh gesetzt, bleibt Ihnen wenig Spielraum. Installieren Sie zunächst die neueste Version, denn viele Themes beheben solche Fehler in späteren Releases.

Hilft das Update nicht, ergänzen Sie gezielte Korrekturen über den Bereich für eigenes CSS. Allerdings überschreibt ein Themeupdate diese Änderungen unter Umständen. Halten Sie Anpassungen daher in einem Child Theme oder einer separaten Stildatei. Baukästen mit Drag and Drop schränken den Codezugriff oft komplett ein. Dann wenden Sie sich mit Ihren Geräteangaben an den Support der Plattform.

Die Grenzen solcher Baukästen beschreiben wir im Beitrag Google Sites für Unternehmen: Reicht das?. Ohne Zugriff auf den eigenen Code lassen sich Safari Fehler kaum dauerhaft lösen.

Wann lohnt sich professionelle Unterstützung?

Die meisten Schritte oben erledigen Sie auf Ebene der Diagnose selbst. Die Reparatur verlangt allerdings Wissen über die Themestruktur, die Cacheschicht und Tests über mehrere iOS Versionen. Zum Beispiel repariert eine neue Höheneinheit eine Seite und bricht zugleich eine Animation auf einer anderen.

Betrifft das Problem mehr als einige Seiten, weil das Theme Safari nie berücksichtigt hat, kostet eine Überarbeitung der Struktur weniger als einzelne Flicken. Möchten Sie eine neue Firmenwebsite erstellen lassen, fragen Sie schon im Angebot schriftlich nach, auf welchen Geräten und Browsern das Team testet.

Unser Ansatz: Vor der Übergabe läuft dieselbe Checkliste auf echten iPhones und Android Geräten. Somit schließt sich die Lücke zwischen „bei mir passt es“ und „beim Kunden kaputt“ noch vor dem Livegang.

Welche Angaben braucht Ihr Entwickler?

„Die Website ist auf dem iPhone kaputt“ sagt einem Entwickler fast nichts. Kann er den Fehler nicht nachstellen, kann er ihn auch nicht beheben. Ergänzen Sie Ihre Meldung deshalb um diese Angaben:

• Die vollständige Adresse der Seite und den betroffenen Abschnitt.
• iPhone Modell und iOS Version, zu finden unter Allgemein in den Einstellungen.
• Den genutzten Browser und ob der Fehler auch im privaten Tab auftritt.
• Ob das Telefon im Hoch oder Querformat lag.
• Einen Screenshot oder eine kurze Bildschirmaufnahme.
• Wann Sie den Fehler zuerst bemerkt haben und ob kurz davor ein Update lief.

Nennen Sie zudem, auf welchen Seiten der Fehler wiederkehrt, denn ein Fehler auf einer Seite und ein Fehler auf der ganzen Website haben verschiedene Quellen. Beispielszenario: Zoomt die Seite nur auf der Kontaktseite, prüft der Entwickler direkt die Formularstile statt des ganzen Themes.

Schaden Safari Fehler dem SEO und der Conversion?

Google bewertet Seiten bei der Mobile First Indexierung meist mit einem Android basierten Crawler. Daher taucht ein reiner Safari Fehler nicht unbedingt als direktes Rankingsignal auf. Harmlos ist er trotzdem nicht.

Sehen iPhone Nutzer den Button nicht, kämpfen sie mit einem zoomenden Formular oder einem leeren Produktbild, verlassen sie die Seite. Das senkt die Conversion und verschwendet Werbebudget. Zudem kommt ein großer Teil des Traffics aus Google Ads und Meta Kampagnen über Smartphones, also wirkt sich das iPhone Erlebnis direkt auf die Kampagneneffizienz aus.

Kurz gesagt: Behandeln Sie Safari Kompatibilität als Punkt Ihrer Conversion Checkliste, nicht nur der SEO Liste. Für die Abnahme empfehlen wir, eine Zeile für iPhone Safari in die Liste aus unserem Beitrag zum Testen der Website vor dem Livegang aufzunehmen.

Fazit: Wie schließen Sie einen iPhone Safari Fehler ab?

Ein Problem auf iPhone Safari ist selten ein einzelner großer Fehler. Meist summieren sich mehrere kleine Unterschiede. Zunächst bestätigen Sie, dass wirklich WebKit die Ursache ist. Danach ordnen Sie das Symptom mithilfe der Tabelle zu. Dann beheben Sie die Fehler nach ihrer Wirkung auf die Conversion. Schließlich testen Sie erneut am echten Gerät, im privaten Tab und mit geleertem Cache.

Wünschen Sie eine Website, die auf jedem Gerät gleich funktioniert, mit Tests vor der Übergabe und dauerhaften Korrekturen, dann finden Sie bei unserem Webdesign die passende Unterstützung. Bei Talha Aslan und Team arbeiten wir mit derselben Checkliste auf echten iPhones und Android Geräten und übernehmen die strukturellen Teile, die Sie allein nicht lösen können.