Verwandeln Sie HTML in
bearbeitbare Elementor-Seiten

Das Problem der beiden üblichen Ansätze

Wenn Sie bereits eine fertige HTML-Seite haben und sie in WordPress brauchen, gibt es normalerweise zwei Möglichkeiten — und keine ist gut. Die erste: das Markup in ein einzelnes HTML-Widget einfügen. Es wird korrekt gerendert, aber Elementor behandelt es als einen undurchsichtigen Block: Sie können keine Überschrift anklicken, um ihre Größe zu ändern, kein Icon austauschen, und ein Kunde kann keinen Satz korrigieren, ohne Code zu öffnen. Die Seite sitzt in Elementor, ohne Teil davon zu sein.

Die zweite Möglichkeit ist, jede Sektion von Hand nachzubauen. Das Ergebnis ist idiomatisch und voll bearbeitbar, aber bei einer langen Marketingseite bedeutet das Stunden an Arbeit — und Abstände und Typografie exakt zu treffen ist mühsam und fehleranfällig.

Die Konvertierung ist der dritte Weg. Statt das Markup zu bewahren oder es manuell nachzubauen, wird die Seite so gelesen, wie ein Browser sie liest — mit echten berechneten Stilen — und jeder Teil wird auf das Elementor-Widget abgebildet, das am besten passt.

Warum berechnete Stile statt des Stylesheets

Die Konvertierung versucht nicht, Ihr CSS zu parsen. Ihre Seite wird in einem isolierten Frame gerendert, und dann wird jedes Element so gemessen, wie der Browser es tatsächlich aufgelöst hat. Dieser Unterschied ist wichtiger, als er klingt.

Das bedeutet: klassenbasiertes CSS, Kaskade, Vererbung, Custom Properties und Kurzschreibweisen funktionieren einfach — denn der gelesene Wert ist der endgültige. Eine als CSS-Variable geschriebene Farbe kommt als die Farbe an, zu der sie aufgelöst wird. Eine mit clamp geschriebene Schriftgröße kommt als die tatsächliche Größe an. Es gibt keinen CSS-Parser, der Ihrem Browser widerspricht.

Es entsteht aber auch ein Problem, das man verstehen sollte, denn es erklärt die meisten der unten beschriebenen Sorgfaltsschritte: Der Browser löst relative Werte in absolute Pixel auf. Eine Breite von hundert Prozent wird als Pixelzahl gemeldet. Auto-Seitenränder werden als die Pixel gemeldet, die das Element in diesem Moment zentrierten. Als Bruchteile geschriebene Grid-Spalten werden als Pixelbreiten gemeldet. Diese Zahlen direkt zu übernehmen würde Ihr Layout auf der Breite einfrieren, bei der die Konvertierung zufällig lief.

Die relative Absicht wird deshalb rekonstruiert statt kopiert. Bilder werden als Prozentsatz ihres Containers ausgedrückt, und Bilder in voller Breite bekommen gar keine feste Breite. Ein Block mit Maximalbreite und symmetrischen Auto-Rändern wird als zentriert erkannt und zu einem Boxed-Container, der bei jeder Bildschirmgröße nativ zentriert. Gleiche Grid-Spuren werden numerisch verglichen — mit Toleranz für Subpixel-Rundung — und als Bruchteileinheiten zurückgeschrieben, damit das Grid weiterhin umbricht.

Struktur: Container — und wissen, wann man keinen anlegt

Jeder blockartige Wrapper in Ihrem Markup wird zu einem Elementor-Container — mit seinem Padding, Hintergrund, Rahmen, Radius, Schatten und seinen Flex- oder Grid-Einstellungen. Das ist eine treue Abbildung, aber wörtlich genommen erzeugt sie tiefe Bäume: eine Section in einem Wrapper in einer Row in einer Column sind vier Container, bevor man eine Überschrift erreicht.

Zwei Dinge reduzieren das. Ein Wrapper ohne jede visuelle oder Layout-Wirkung — kein Hintergrund, Rahmen, Padding, Schatten, keine Maximalbreite, Mindesthöhe, kein Flex- oder Grid-Display — wird eingeklappt, denn ihn zu entfernen ändert nichts. Und eine Karte, die eigentlich nur ein gestalteter Rahmen um ein einzelnes Inhaltselement ist, wird vollständig abgeflacht: Der Rahmen wandert auf das Widget selbst.

Diese zweite Regel ist der Grund, warum eine Reihe aus fünf Bildkarten zu einem Grid mit fünf Image-Box-Widgets wird — und nicht zu einem Grid mit fünf Containern, die je ein Widget halten. Es ist die Struktur, die ein erfahrener Elementor-Nutzer von Hand bauen würde, und sie lässt sich später viel leichter umgestalten.

Muster erkennen, nicht nur Tags

Eine Überschrift auf ein Heading-Widget abzubilden ist offensichtlich. Die eigentliche Arbeit liegt im Erkennen von Formen. Ein Container mit einem Icon, einer Überschrift und einem kurzen Absatz ist eine Icon Box. Ein Container mit einem Bild, einer Überschrift und einem Absatz ist eine Image Box. Eine Liste wiederholter Zeilen mit je einem Icon und etwas Text ist eine Icon List — mit einem bearbeitbaren Eintrag pro Zeile.

Diese Erkennungen sind bewusst streng. Enthält eine Karte über Überschrift und Absatz hinaus weiteren Text — eine Schrittnummer, ein Badge, einen Preis — wird das Muster nicht angewendet und der Block bleibt ein einfacher Container, denn diesen Text zu verlieren wäre schlimmer als ein etwas tieferer Baum. Konservative Erkennung, der man vertrauen kann, ist wertvoller als aggressive Erkennung, die man prüfen muss.

Buttons funktionieren genauso. Die meisten echten Calls-to-Action sind Anker mit CSS, keine button-Elemente — ein Link wird deshalb nur dann als Button behandelt, wenn mehrere Signale übereinstimmen: kurzer Text, keine blockartigen Kinder, Hintergrund oder Rahmen, ein Eckenradius, echtes Padding und ein blockartiges Display. Jedes einzelne Kriterium allein würde Fehltreffer erzeugen.

Icons und Bilder: die zwei Dinge, die eine Entscheidung brauchen

Icons können echte Einträge in der Elementor-Icon-Bibliothek werden und sind danach über den Icon-Picker austauschbar. Das funktioniert, wenn die Quelle Icon-Font-Klassen verwendet. Bei einem handgezeichneten Inline-SVG kann die Grafik gar nicht in das Icon-Steuerelement gelangen, und ein SVG, das für Größe und Strich vom Seiten-CSS abhing, verliert dieses Styling, sobald es aus der Seite gelöst wird. Wo ein Icon nicht per Name zugeordnet werden kann, bleibt das Steuerelement absichtlich leer, statt mit einer falschen Vermutung gefüllt zu werden.

Bilder sind die andere Entscheidung. Ein Data-URL-Bild oder ein lokaler Dateipfad kann kein WordPress-Medienanhang werden — solche werden zu leeren Slots, von denen jeder seinen Alt-Text als Beschriftung behält, damit Sie wissen, welches Bild wohin gehört. Verweist die Quelle auf echte, hochgeladene Bild-URLs, werden sie ganz ohne manuellen Schritt importiert. Die Bilder zuerst hochzuladen ist die eine Änderung, die am meisten Nacharbeit erspart.

Was nicht konvertiert wird — ehrlich gesagt

Skripte werden entfernt — alles, was von eigenem JavaScript angetrieben wurde, kommt als statisches Markup an und sollte mit dem passenden nativen Widget neu gebaut werden. Formular-Submit-Aktionen werden entfernt, denn einen Endpunkt mitzunehmen würde die Daten Ihrer Besucher an ein Ziel senden, das Sie nicht gewählt haben. Navigationsmenüs müssen auf ein echtes WordPress-Menü zeigen. Hover- und Fokus-Zustände lassen sich aus einer ruhenden Seite nicht ablesen und werden danach gesetzt. Animationen, Übergänge und Sticky-Verhalten wendet man besser mit Elementors eigenen Steuerelementen neu an.

Pseudo-Elemente verdienen eine besondere Erwähnung, weil sie überraschen. Mit before und after gezeichnete Zierformen, Anführungszeichen und Unterstreichungsakzente sind gar keine DOM-Knoten und können daher keine Widgets werden. Fehlt nach der Konvertierung ein Designdetail, ist das der erste Prüfpunkt.

Das sauberste Ergebnis erzielen

Die Qualität einer Konvertierung wird vor allem vom Markup bestimmt, das man ihr gibt. Semantische Tags werden eindeutig abgebildet. Ein flaches DOM mit einem Wrapper pro Sektion hält den Baum bearbeitbar. CSS, das inline oder in einem einzigen Style-Block steht, lässt sich tatsächlich messen — ein Framework-Stylesheet, das nie lädt, hinterlässt dagegen eine ungestylte Seite. Mit gap gesetzte Abstände werden zu einem Steuerelement statt vielen.

Vor dem Export lohnen sich jedes Mal fünfzehn Sekunden für die Strukturkarte. Sie zeigt die Komponentenzahl, die maximale Verschachtelungstiefe und eine Vertrauensaufschlüsselung, mit einer an den Baum gekoppelten Live-Vorschau. Ist die Tiefe hoch oder blieben mehrere Zeilen als HTML erhalten, ist die Quelle zu korrigieren und neu zu konvertieren durchweg schneller, als das Ergebnis in Elementor zu reparieren.

Eine lange Seite bringt man am besten Sektion für Sektion hinüber. Setzen Sie eine Kopierwurzel auf den gewünschten Block, und nur dieser Teilbaum wird exportiert — äußere Wrapper, Header und Footer bleiben zurück. Kleinere Einheiten sind viel leichter zu prüfen, und alles, was Sie wiederverwenden, können Sie unterwegs in Ihrer Vorlagen-Bibliothek speichern.