Was sind Micro Frontends? Skalierbare Architektur für große Unternehmenswebsites

Wenn fünf Teams Code in dasselbe Frontend liefern, fühlt sich jedes Release irgendwann wie eine Verhandlung an. Micro Frontend Architektur ist eine mögliche Antwort auf diesen Engpass. Ich arbeite seit 2012 an Unternehmenswebsites und an SEO. In diesem Beitrag betrachte ich Micro Frontends deshalb aus Sicht der Entscheider: mit echtem Nutzen, echten Kosten und den SEO Fallen dazwischen.

Was ist ein Micro Frontend?

Ein Micro Frontend ist ein unabhängig entwickelter, getesteter und ausgelieferter Teil der Benutzeroberfläche einer Website, der meist einem Team und einer Fachdomäne gehört. Mehrere solcher Teile ergeben zusammen eine Seite. Besucher sehen also eine einheitliche Website, während jedes Team in seinem eigenen Takt veröffentlicht.

Eine der klarsten Quellen ist der Artikel von Cam Jackson auf martinfowler.com. Er beschreibt Micro Frontends als Architekturstil, der unabhängig lieferbare Frontend Anwendungen zu einem größeren Ganzen zusammensetzt. Das heißt: Es geht nicht um eine Bibliothek oder ein Produkt. Es geht um die Frage, wie Teams den Code aufteilen und wie die Seite wieder zusammenfindet.

Ein Beispiel: In einem großen Onlineshop können Suche, Produktdetail, Warenkorb und Kundenkonto jeweils eigene Anwendungen sein. Wer eine Produktseite öffnet, sieht dann womöglich Code von drei Teams auf einem Bildschirm. Die eigentliche Schwierigkeit liegt also nicht im Schreiben der Teile. Sie liegt darin, die Teile schnell und stimmig zu verbinden.

Welches Problem sollen Micro Frontends lösen?

Als Microservices im Backend üblich wurden, stießen viele Unternehmen auf ein seltsames Missverhältnis. Die Services liefen unabhängig, das Frontend blieb allerdings ein großer Block. Folglich wartete das Team für den Checkout oft auf die Tests des Katalogteams, bevor es eine kleine Korrektur veröffentlichen durfte.

Genau diesen Engpass nimmt die Architektur ins Visier. Das Versprechen klingt einfach: Jedes Team entscheidet in seiner Domäne, veröffentlicht in seinem Tempo und muss nicht fürchten, den Code anderer Teams zu beschädigen. Kurz gesagt ist das Problem eher organisatorisch als technisch.

• Dutzende Entwickler kollidieren in einem Repository, Merges dauern lange.
• Ein einziger Fehler blockiert das Release der gesamten Website.
• Um ein altes Framework loszuwerden, müsste man die ganze Website auf einmal neu schreiben.
• Zuständigkeiten sind im Code nicht sichtbar, Verantwortung verteilt sich diffus.

Das bekannte Gesetz von Conway weist in dieselbe Richtung: Organisationen entwerfen Systeme, die ihre eigene Kommunikationsstruktur abbilden. Sind Ihre Teams nach Fachdomänen organisiert, Ihr Code aber ein Block, entsteht also zwangsläufig Reibung. Sind die Teams dagegen noch nicht klar getrennt, hilft eine vorgezogene Aufteilung des Codes nicht. Sie verlagert das Warten nur an eine andere Stelle.

Wenn Ihnen keines dieser Probleme bekannt vorkommt, bringt Ihnen die Architektur vermutlich eher ein neues Problem. Auf diesen Punkt komme ich später noch zurück.

Worin unterscheidet sich ein Micro Frontend von einem monolithischen Frontend?

In einem monolithischen Frontend leben alle Seiten in einer Anwendung: ein Repository, ein Build, eine Deployment Pipeline. Bei einem aufgeteilten Frontend kann dagegen jeder Teil ein eigenes Repository, einen eigenen Buildprozess und einen eigenen Releasekalender haben. Zwischen beiden Polen liegt allerdings eine breite Grauzone.

Ein modularer Monolith zum Beispiel ordnet den Code nach Fachdomänen in Pakete, geht aber weiterhin in einem Release live. Für viele Unternehmen liefert dieser Mittelweg einen großen Teil des Nutzens zu deutlich geringeren Kosten. Die folgende Tabelle fasst die Abwägung in der Sprache der Geschäftsleitung zusammen.

Diese Einschätzungen beruhen auf meiner Praxiserfahrung. Lesen Sie sie als Richtungsangabe, nicht als gemessenen Benchmark.

Warum sollten Sie Informationsarchitektur und Codearchitektur trennen?

In Meetings höre ich oft: „Unsere Website ist riesig geworden, lassen Sie uns auf Micro Frontends umsteigen.“ Größe hat allerdings zwei Achsen. Die erste ist das, was Besucher und Google sehen: Kategorien, URLs und Menüs. Die zweite ist das, was Entwickler sehen: Repositories, Pakete und Pipelines.

Den Blick der Besucher behandle ich im Beitrag zur Kategoriestruktur für große Websites. Hier geht es dagegen ausschließlich um Code, also um die Technik dahinter. Beides hängt zusammen, ersetzt sich aber nicht, denn beides beantwortet unterschiedliche Fragen. Ist Ihre Kategoriestruktur unordentlich, repariert eine neue Codearchitektur sie nicht. Stattdessen verteilt sie das Durcheinander nur auf mehr Repositories.

Daher lautet meine erste Frage immer gleich: Finden Besucher ihren Weg nicht, oder warten Teams ständig aufeinander? Das Erste ist eine Aufgabe der Informationsarchitektur. Das Zweite betrifft die Codearchitektur. Eine falsche Diagnose führt daher zu einem falschen Budget.

Wie setzen sich Micro Frontends auf einer Seite zusammen?

Das Herz dieser Architektur ist die Komposition, also der Moment, in dem getrennte Teile zu einer Seite verschmelzen. Das passiert an einem von drei Orten: beim Build, auf dem Server oder am Rand des CDN, und im Browser. Der gewählte Ort prägt die Autonomie der Teams und zudem SEO und Performance.

1. Integration zur Build Time: Jedes Team veröffentlicht ein Paket, die Hauptanwendung baut alles gemeinsam.
2. Integration zur Laufzeit per JavaScript: Eine Shell Anwendung lädt die Teile im Browser bei Bedarf nach.
3. Module Federation: Getrennte Builds tauschen zur Laufzeit Code aus und teilen gemeinsame Bibliotheken.
4. Iframes: Jeder Teil läuft als eigenes Dokument innerhalb der Seite.
5. Komposition auf Server oder Edge: Server oder CDN Edge fügen HTML Fragmente zusammen und liefern eine fertige Seite.

Zunächst gilt: Keine Option gewinnt überall. In der Praxis sehen Sie bei großen Websites oft ein Mischmodell: Seiten mit hoher SEO Bedeutung entstehen auf dem Server, Bereiche nach dem Login dagegen im Browser. Schauen wir uns die Optionen nacheinander an.

Was ist Integration zur Build Time, und warum reicht sie oft nicht?

Bei der Integration zur Build Time veröffentlicht jedes Team seinen Teil als Paket. Die Hauptanwendung nimmt diese Pakete als Abhängigkeiten auf und erzeugt eine gemeinsame Ausgabe. Außerdem ist die Einrichtung einfach, die Performance berechenbar, und serverseitiges Rendering funktioniert reibungslos.

Der Haken ist allerdings erheblich. Jacksons Artikel warnt, dass dieser Ansatz einen Releaseprozess im Gleichschritt erzeugt. Eine Änderung in einem Teil bedeutet, dass Sie die gesamte Anwendung neu bauen und neu ausliefern. Somit geht das zentrale Versprechen der Architektur, unabhängige Releases, weitgehend verloren.

Trotzdem würde ich den Ansatz nicht abtun. Haben Sie wenige Teams und brauchen vor allem sauberen Code, ist diese Integration eigentlich nur ein höflicher Name für einen modularen Monolithen. Für viele Unternehmen ist genau das der richtige Startpunkt.

Wie funktioniert die Integration zur Laufzeit per JavaScript?

Hier baut eine Shell Anwendung, oft Container genannt, das Grundgerüst der Seite. Danach entscheidet sie, welche Route welchen Teil braucht, und lädt dessen JavaScript zur Laufzeit. Jedes Team kann sein Paket jederzeit aktualisieren, ohne dass die Shell einen neuen Build braucht.

Für unabhängige Releases gehört dieses Modell zu den flexibelsten Optionen. In der Open Source Welt haben Orchestrierungsframeworks das Modell populär gemacht. Web Components bieten zudem einen standardisierten Weg, Teile als eigene HTML Elemente zu verpacken, unabhängig von einem bestimmten Framework.

Andererseits zahlt der Browser die Rechnung. Wartet die Seite erst auf die Shell, dann auf den Teil und dann auf dessen Daten, verlangsamt sich der erste Aufruf spürbar. Entsteht der Inhalt zudem nur durch JavaScript, hängen Suchmaschinen vom Rendering ab, um die Seite zu verstehen. Beide Risiken greife ich im Abschnitt zu SEO erneut auf.

Was ist Module Federation, und was bringt es für Micro Frontends?

Module Federation ist eine Funktion, die mit webpack 5 kam. Laut die webpack Dokumentation zu Module Federation besteht das Ziel darin, dass mehrere getrennte Builds eine einzige Anwendung bilden. Konkret verhält sich jeder Build wie ein Container. Er kann Code für andere freigeben und Code von anderen beziehen.

• Host: die Hauptanwendung, die Module aus anderen Builds nutzt.
• Remote: ein getrennter Build, der Module freigibt, meist über eine Einstiegsdatei.
• Shared: eine Einstellung, mit der gemeinsame Bibliotheken wie React nur einmal laden statt einmal pro Teil.
• Singleton: eine Regel, die nur eine Kopie einer Bibliothek auf der Seite zulässt; wichtig für Bibliotheken mit Zustand.

Aus Sicht der Entscheider liegt der eigentliche Wert im Teilen. Richtig eingerichtet, lädt der Browser eine gemeinsame Bibliothek einmal statt fünfmal. Allerdings liegt die Versionskompatibilität nun in Ihrer Verantwortung. Hebt ein Team eine gemeinsame Bibliothek auf eine neue Hauptversion, brauchen Sie einen Plan, wie die anderen Teams nachziehen.

Sind iframes für Micro Frontends noch sinnvoll?

Iframes sind der älteste und stärkste Weg, Teile voneinander zu isolieren. Jeder Teil läuft in einem eigenen Dokument, daher dringen weder CSS Regeln noch JavaScript Fehler in andere Teile. Deshalb funktionieren iframes weiterhin gut für Zahlungsformulare von Drittanbietern oder für Verwaltungsmasken aus einem Altsystem.

Für öffentliche Seiten, die Suchtraffic gewinnen sollen, empfehle ich sie dagegen selten. Responsive Höhe, Deep Links, die Zurück Taste und Barrierefreiheit verursachen Zusatzaufwand. Auch bei SEO bleibt Unsicherheit. Googles Ankündigung des Tags indexifembedded erklärt, dass Google versucht, Inhalte in iframes der übergeordneten Seite zuzuordnen, dies aber nicht garantiert.

Kurz gesagt: Denken Sie an iframes für Bereiche hinter dem Login, die ohnehin nicht im Index landen sollen. Für Produkt, Kategorie und Contentseiten wählen Sie besser einen anderen Integrationsweg.

Wie funktioniert die Komposition auf Server oder Edge?

Bei diesem Ansatz findet die Komposition statt, bevor etwas beim Browser ankommt. Server oder CDN Edge rufen HTML Fragmente verschiedener Teams ab und fügen sie zu einer Seite zusammen. Der Browser erhält dann von Anfang an vollständiges HTML. Server Side Includes und Edge Side Includes waren frühe Varianten dieser Idee. Heute gelingt Ähnliches mit Edge Functions moderner CDNs.

Für SEO und den ersten Seitenaufruf ist dieses Modell meist die gesündeste Option, denn Suchmaschinen und Nutzer sehen den Inhalt, bevor JavaScript läuft. Interaktive Teile erwachen danach im Browser durch Hydration zum Leben.

Die Kosten liegen im Betrieb. Wird ein Fragmentserver langsam, bremst er womöglich die ganze Seite. Daher brauchen Sie für jedes Fragment ein Timeout, eine Cacheregel und einen Ersatzinhalt. Antwortet zum Beispiel das Fragment mit Empfehlungen nicht innerhalb weniger hundert Millisekunden, sollte die Seite einfach ohne es öffnen.

Welche Integration für Micro Frontends passt zu welcher Situation?

Die bisherigen Optionen können Sie der folgenden Liste zuordnen. Sie ist allerdings kein Rezept. Vielmehr ist sie der Rahmen, mit dem ich Architekturgespräche mit Kundenteams beginne.

• Wenige Teams, Bedarf an Ordnung: Integration zur Build Time oder modularer Monolith.
• Shopseiten mit hoher SEO Bedeutung: Komposition auf Server oder Edge, danach selektive Hydration.
• Dashboards und Anwendungen nach dem Login: Integration per JavaScript zur Laufzeit oder Module Federation.
• Teile von Drittanbietern oder Altsysteme mit Isolationsbedarf: iframes.
• Wechsel des Frameworks: Shell Anwendung mit Integration pro Route, sodass alter und neuer Code eine Zeit lang nebeneinander leben.

Ein Unternehmen kann also mehrere Zeilen dieser Liste gleichzeitig nutzen. Fragen Sie deshalb nicht, welche Methode insgesamt die beste ist, sondern welche zu welchem Seitentyp passt.

Wann sind Micro Frontends unnötige Komplexität?

Ehrlich gesagt brauchen die meisten Unternehmenswebsites, die ich prüfe, keine Micro Frontends. Bei einer Website mit einigen hundert Seiten und einem einzigen Team vervielfacht die Architektur Pipelines, Monitoring und Versionsdebatten. Im Gegenzug liefert sie allerdings kaum etwas.

Jacksons Artikel nennt die Nachteile offen. Erstens wächst die Downloadgröße durch doppelte Abhängigkeiten. Zweitens können lokale Entwicklungsumgebungen von der Produktion abweichen. Schließlich steigt der Betriebsaufwand, weil Sie mehr Repositories, Pipelines und Server verwalten. Das sind also keine theoretischen Risiken. Sie tauchen jeden Monat auf der Wartungsrechnung auf.

• Am Frontend arbeitet nur ein Team oder zwei bis drei Entwickler.
• Sie veröffentlichen ein paar Mal im Monat, und niemand wartet auf jemanden.
• Die eigentliche Beschwerde betrifft Tempo, Design oder Inhalte.
• Es gibt kein Plattformteam, das die gemeinsame Infrastruktur verantwortet.

Trifft schon die Hälfte davon zu, sollten Sie zunächst den Code in Module aufteilen und die Pipeline beschleunigen. Meist liegt die Lösung genau dort.

Welche Signale zeigen, dass Sie Micro Frontends wirklich brauchen?

Von der anderen Seite betrachtet wird das Bild klarer. Ernsthaft auf den Tisch bringe ich diese Architektur vor allem bei großen E-Commerce Anbietern, Banken, Versicherungen, Medienhäusern und Konzernen mit mehreren Marken. Gemeinsam ist ihnen vor allem die hohe Zahl an Teams, die am Frontend arbeiten.

1. Mehrere unabhängige Produktteams ändern dasselbe Frontend mehrmals pro Woche.
2. Die Teams folgen klaren Fachdomänen, und jede Domäne hat einen bekannten Eigentümer.
3. Sie müssen von einem alten auf ein neues Framework wechseln, ohne die Website einzufrieren.
4. Nach einer Fusion oder Übernahme müssen Websites mit unterschiedlichen Technologien unter ein Dach.
5. Ein Plattformteam kann gemeinsame Infrastruktur, Designsystem und Performancebudget verantworten.

Den fünften Punkt vergessen allerdings viele. Ohne Plattformteam wird ein aufgeteiltes Frontend schnell zum Flickenteppich, in dem jedes Team eigene Regeln aufstellt. Planen Sie die Kosten dieses Teams daher von Anfang an ein.

Wie beeinflussen Micro Frontends die SEO?

An sich ist die Architektur für SEO weder gut noch schlecht. Stattdessen hängt die Wirkung vom Integrationsweg ab. Laut Google Search Central in den Grundlagen zu JavaScript SEO verarbeitet Google JavaScript Anwendungen in drei Phasen: Crawling, Rendering und Indexierung. Erscheint Inhalt nur im Browser, muss er also erst das Rendering abwarten, bevor er in den Index gelangt.

Dieselbe Seite betont außerdem, dass serverseitiges Rendering oder Vorabrendering weiterhin eine gute Idee ist, weil es Websites für Nutzer und Crawler schneller macht und nicht alle Bots JavaScript ausführen. Mit Blick auf KI Crawler wiegt dieser Hinweis noch schwerer. Mehr dazu lesen Sie in meinem Beitrag über technisches SEO nach der KI Wende.

• Links sollten echte <a> Elemente mit href sein. Laut Google kann die Suchmaschine nur solche Links sicher entdecken.
• Verwalten Sie Title, Meta Description, Canonical und strukturierte Daten an einer Stelle; zwei Teile dürfen nie dasselbe Tag schreiben.
• Routenwechsel sollten über die History API echte URLs erzeugen. Verzichten Sie auf Routing mit Hash.
• Jeder Teil sollte bei einem Fehler sinnvollen Ersatzinhalt liefern, keine leere Box.

Warum ist serverseitiges Rendering bei Micro Frontends so wichtig?

Serverseitiges Rendering, kurz SSR, bedeutet: Der Server erzeugt das HTML der Seite und liefert es vollständig aus. Bei einem aufgeteilten Frontend zählt SSR aus zwei Gründen. Erstens lesen Suchmaschinen und KI Bots den Inhalt, ohne auf JavaScript angewiesen zu sein. Zweitens erscheint das größte Inhaltselement früh, und Besucher starren nicht auf einen leeren Bildschirm.

Das Problem ist allerdings: Nicht jeder Integrationsweg unterstützt SSR gleich gut. Die Integration zur Build Time und die Komposition auf dem Server passen von Natur aus. Bei der Integration zur Laufzeit muss dagegen jeder Teil zusätzlich auf dem Server lauffähig sein. Das bedeutet zudem mehr Codepfade und mehr Tests.

Stellen Sie Ihrem Technikteam deshalb eine einfache Frage: „Steht der Hauptinhalt im Quelltext unserer Kategorie und Produktseiten?“ Lautet die Antwort nein, klären Sie zuerst die Renderingstrategie und erst dann die Architektur. Ich prüfe das über die Quelltextansicht und mit der URL Prüfung in der Google Search Console.

Welche Risiken für die Core Web Vitals bringen Micro Frontends mit sich?

Die Core Web Vitals sind die drei Kennzahlen, mit denen Google die Nutzererfahrung misst. der Leitfaden zu Web Vitals auf web.dev nennt diese guten Schwellenwerte: LCP innerhalb von 2,5 Sekunden, INP bei höchstens 200 Millisekunden und CLS bei höchstens 0,1. Google betrachtet dabei das 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. INP hat FID im Jahr 2024 als Core Web Vital abgelöst.

Wie diese Kennzahlen das Ranking beeinflussen, erkläre ich im Beitrag wie die Ladezeit SEO beeinflusst. Laborwerte behandelt meine Anleitung zum Lighthouse Test. Meine Regel für aufgeteilte Frontends ist einfach: Jeder Teil bekommt ein JavaScript Budget, und die Pipeline prüft dieses Budget automatisch.

Wie steuern Sie ein gemeinsames Designsystem über alle Micro Frontends?

Besucher wissen nicht, wie viele Teams an einer Seite gebaut haben, und das sollen sie auch nicht. Sehen Buttons, Formulare und Typografie in jedem Teil anders aus, wirkt die Website unordentlich und weniger vertrauenswürdig. Ein Designsystem ist hier also keine Option, sondern Pflicht.

• Design Tokens: Farben, Abstände und Schriftgrößen stammen aus einer Quelle.
• Komponentenbibliothek: Alle Teams nutzen dieselben Buttons, Formularfelder und Dialoge.
• CSS Isolation: CSS Module, Namenskonventionen oder Shadow DOM verhindern, dass Stile auslaufen.
• Versionsregeln: Brechende Änderungen erscheinen nach Plan und mit Vorankündigung.

Jacksons Artikel befürwortet gemeinsame Komponentenbibliotheken, zieht aber eine wichtige Grenze. Komponenten, die nur eine Domäne betreffen, bleiben beim zuständigen Team. Sonst wird die gemeinsame Bibliothek zu einem neuen Monolithen, der alle aneinanderkettet. Nach derselben Logik baue ich auch digitale Systeme für Markenidentität.

Wie teilen Sie Teams und Verantwortung bei Micro Frontends auf?

Ein Großteil des Erfolgs hängt davon ab, die Grenzen an der richtigen Stelle zu ziehen. Ziehen Sie sie entlang der Fachdomänen, nicht entlang technischer Schichten. Eine Aufteilung in ein Team für den Header und eines für den Footer holt dagegen bei jeder Änderung wieder alle an einen Tisch.

Gesünder ist eine Aufteilung entlang der Kundenreise: Entdeckung und Suche, Produktdetail, Warenkorb und Checkout, Kontoverwaltung. Jedes Team verantwortet das Frontend seiner Domäne und oft auch das Backend. Somit kann ein Team in seinem Bereich durchgängig entscheiden.

Benennen Sie außerdem klare Eigentümer für gemeinsame Bereiche. Gehören Header, Navigation, Analytics Tags und SEO Metadaten niemandem, fasst sie früher oder später jeder an. Geraten Analytics und Conversion Tags durcheinander, verlieren Berichte ihre Verlässlichkeit. Das schafft blinde Flecken für die SEO Beratung ebenso wie für die Anzeigenoptimierung.

Wie planen Sie den Wechsel vom Monolithen zu Micro Frontends?

Grundsätzlich rate ich davon ab, die Website in einem Zug neu zu schreiben. Stattdessen nutze ich den schrittweisen Ansatz, bekannt als Strangler Fig Pattern. Neue Teile wachsen um die alte Website herum, und Sie legen alten Code Route für Route still. So messen Sie jeden Schritt, und bei Problemen rollen Sie nur einen kleinen Bereich zurück.

1. Erfassen Sie alle Routen samt Traffic, Conversions und SEO Wert.
2. Beginnen Sie mit einem Bereich, der wenig Risiko trägt, aber am meisten von Teamautonomie profitiert.
3. Richten Sie Shell, gemeinsames Designsystem und Performancebudget gleich im ersten Schritt ein.
4. Vergleichen Sie vor und nach jedem Umzug Core Web Vitals, Indexierung und Conversions.
5. Ändern sich URLs, bereiten Sie eine Karte mit 301 Weiterleitungen vor und testen Sie diese vor dem Livegang.

Jeder Umzug mit neuen URLs ist somit im Kern eine Website Migration. Meine Checkliste zur Website Migration deckt diese Seite ab. Um Weiterleitungen auf der Live Website einzeln zu prüfen, eignet sich der Redirect Checker.

Welche Fragen sollten Sie vor der Freigabe eines Micro Frontend Projekts stellen?

Schlägt Ihr Technikteam diese Architektur vor, stellen Sie die folgenden Fragen. Achten Sie dann darauf, wie klar die Antworten ausfallen, denn das verrät viel über die Reife des Plans.

1. Welcher konkrete Engpass verzögert heute Releases, und wie beseitigt die neue Architektur ihn?
2. Welchen Integrationsweg haben Sie gewählt, und rendern Seiten mit hoher SEO Bedeutung auf dem Server?
3. Welches JavaScript Budget bekommt jeder Teil, und wer überwacht es?
4. Wer steuert die Versionskompatibilität gemeinsamer Bibliotheken?
5. Wem gehören Designsystem und gemeinsame Bereiche?
6. Wie verhält sich die Seite, wenn ein Teil ausfällt oder langsam antwortet?
7. Was kosten zusätzliche Infrastruktur, Monitoring und ein Plattformteam pro Jahr?

Erhalten Sie auf mindestens drei dieser Fragen keine klare Antwort, ist ein Aufschub oder ein kleines Pilotprojekt meist klüger. Zudem gewinnen Sie so wertvolle Zeit, um den bestehenden Code zu modularisieren.

Wie messen Sie den Erfolg eines Micro Frontend Projekts?

Eine Architekturänderung nur an der Zufriedenheit der Entwickler zu messen, führt in die Irre. Ich empfehle drei Gruppen von Kennzahlen. Die erste Gruppe ist das Liefertempo: Releasefrequenz, Zeit vom Commit bis zur Produktion und Rate der Rollbacks.

Danach folgt die Nutzererfahrung: Felddaten der Core Web Vitals, JavaScript Gewicht pro Seite und Fehlerrate. Schließlich zählen die Geschäftsergebnisse: organischer Traffic, Zahl der indexierten Seiten und Conversion Rate. Gerade während einer Migration ist ein gemeinsames Dashboard für alle drei Gruppen der verlässlichste Weg, Probleme früh zu erkennen.

Halten Sie die Ziele vor Projektbeginn schriftlich fest. Sonst beantwortet in sechs Monaten jeder die Frage „Sind wir schneller geworden?“ aus dem Bauch heraus. Meine Tipps zum technischen SEO eignen sich zudem als Ausgangsliste für diesen Messrahmen.

Wählen Sie den Pilotbereich klein, aber aussagekräftig. Ziehen Sie zum Beispiel nur die Kontoseiten oder eine Produktgruppe um und vergleichen Sie diese vier bis acht Wochen mit dem alten Aufbau. Dieser Zeitraum ist ein Startwert aus meiner Praxiserfahrung, keine Garantie. Bei wenig Traffic brauchen Sie deshalb länger. So entscheiden Sie mit echten Daten, bevor Sie das Budget auf die ganze Website verteilen.

Wie treffen Sie die Entscheidung für oder gegen Micro Frontends?

Zusammengefasst lösen Micro Frontends ein Problem der Teamkoordination, kein Größenproblem. In Organisationen mit vielen Teams, vielen Domänen und häufigen Releases bringen sie echtes Tempo. Bei Websites mit einem Team oder mittlerer Größe erhöhen sie dagegen meist den Wartungsaufwand und gefährden die Performance.

Prüfen Sie bei der Entscheidung zunächst drei Dinge. Ist das Problem wirklich organisatorisch? Rendern Seiten mit hoher SEO Bedeutung auf dem Server? Gibt es ein Team, das gemeinsame Infrastruktur verantwortet? Sind alle drei Antworten klar, starten Sie mit einem kleinen Pilot und wachsen messend weiter.

Möchten Sie Architektur, SEO und Performance einer großen Unternehmenswebsite gemeinsam prüfen lassen, unterstütze ich Sie über mein Webdesign und technisches SEO. Schildern Sie mir Ihre Situation gern über die Kontaktseite.