Event-Microsite oder Seite auf der bestehenden Website? Entscheidungshilfe

Die Optionen anhand des Betriebs abgrenzen

Eine Seite auf der bestehenden Website nutzt hier das aktuelle Veröffentlichungs- und Inhaltssystem der Organisation. Eine Microsite ist eine separat betriebene, auf das Event ausgerichtete Website; sie kann eine eigene Domain oder Subdomain verwenden. Ein auffälliges Design im bisherigen System bleibt betrieblich eine Seite. Halten Sie die tatsächliche URL und Systemgrenze fest, bevor Angebote verglichen werden.

Für einen Workshop mit Termin, Ort, Programmüberblick und einem Anmeldelink kann eine Seite genügen. Eine mehrtägige Konferenz braucht möglicherweise eigene Bereiche für Programm, Vortragende, Anreise und Sponsoren. Keines der Formate hält Fakten automatisch richtig. Planen Sie nur Inhalte, die jemand freigeben und aktualisieren kann.

Besucherweg und Inhaltsumfang prüfen

Gehen Sie den Weg vom Einladungs- oder Suchlink über die Eventdaten bis zur tatsächlichen Anmeldung oder Ticketseite. Notieren Sie jede Domain und das verantwortliche Team. Liegt die Kasse bei einem anderen Dienst, ändert eine Korrektur auf der Werbeseite nicht zwangsläufig dessen Angaben. Vergleichen Sie Ziel und Eintrittsbedingungen mit den bestätigten Eventdaten.

Brauchen Besucher eine eigenständige Eventmarke, mehrere Wege durch ein großes Programm, mehrere Sprachen oder eine dauerhafte Startseite für eine jährliche Reihe? Prüfen Sie danach, ob die bestehende Website dies bereits verständlich darstellen kann. Eine separate Website garantiert weder mehr Sichtbarkeit noch bessere Messung oder Verkäufe.

Für jede Daueraufgabe eine Zuständigkeit festlegen

Bearbeitbares Zuständigkeits- und Pflegeraster herunterladen (Markdown, Englisch)

Laden Sie das englische Zuständigkeits- und Pflegeraster herunter. Vergleichen Sie URL- und Domainkontrolle, Hosting und Zertifikate, Redaktionsrechte, Faktenquelle, Anmeldelinks, Analysedaten, Support und Archiv. Tragen Sie für jede Aufgabe eine verantwortliche und eine vertretende Person sowie die bestätigende Quelle für Datum, Ort und Tickets ein. Eine offene Zuständigkeit ist Aufwand, selbst bei einem günstigen Bauangebot.

Zählen Sie Einrichtung und laufende Pflege. Eine Microsite kann ein weiteres Konto, einen Veröffentlichungsprozess oder eine Verlängerung erfordern; eine bestehende Seite kann auf Freigaben des Webteams oder ein starres Layout angewiesen sein. Prüfen Sie diese Möglichkeiten im konkreten System. Baut eine Agentur die Seite, klären Sie die spätere Übergabe von Zugang und bearbeitbaren Inhalten.

Eine Änderung vor der Entscheidung erproben

Erproben Sie mit beiden Optionen dieselbe Aufgabe: Entwurf veröffentlichen, Sitzungszeit korrigieren, offiziellen Ticketlink ersetzen, veralteten Hinweis entfernen. Erfassen Sie Bearbeitung, Freigabe, Wartezeit und Kontrolle der veröffentlichten Fassung. Öffnen Sie Seite und Ticketziel am Smartphone; prüfen Sie Navigation und Bedienelemente mit Tastatur. Ein Test mit dem eigenen Team sagt mehr als eine fertige Demo.

Fällt die Hauptredaktion aus, muss die Vertretung Faktenquelle und Zugang finden, die Seite korrigieren und Besucher bei Ausfall des externen Ticketdienstes richtig informieren können. Nutzen Sie nur einen geprüften offiziellen Ersatzweg oder eine klare Supportmeldung. Eine zweite Webadresse ist kein zweites Ticketsystem.

Den Umgang mit der Seite nach dem Event festlegen

Legen Sie vor dem Start fest, was nach dem Event mit der URL geschieht. Bewahren Sie nützliche Informationen der jeweiligen Ausgabe auf oder verweisen Sie auf die passende aktuelle Ausgabe beziehungsweise die Reihenübersicht. Werden Inhalte auf neue URLs verschoben, ordnen Sie alte und neue Seiten einander zu und planen Weiterleitungen sowie Linkkorrekturen; Google Search Central beschreibt diesen Vorgang. Leiten Sie alte Eventseiten nicht ungeprüft alle auf eine allgemeine Startseite um.[1]

Bei einer Microsite braucht es eine Person für fortlaufende Domain-, Hosting- und Sicherheitsarbeit. Bei einer bestehenden Seite muss jemand die Ausgabe als vergangen kennzeichnen, veraltete Ticketaufrufe entfernen und die Navigation prüfen. Diese Nacharbeit gehört zur ersten Entscheidung.

Entscheidung und Bedingungen dokumentieren

Begründen Sie die Wahl mit einem überprüfbaren Satz: „Für den monatlichen Workshop nutzen wir die bestehende Seite, weil die Redaktion sie selbst korrigieren kann und der Ticketlink getestet ist.“ Oder: „Für die Jahreskonferenz nutzen wir eine Microsite, weil das bestätigte Programm mehrere Bereiche braucht und ein Team das separate System betreibt.“ Das sind Beispiele, keine allgemeinen Regeln.

Dokumentieren Sie geplante URL, verantwortliche Redaktion und Vertretung, offizielles Anmeldeziel, Startkontrolle, jährlichen oder abschließenden Prüftermin und offene Anbieterfragen. Überprüfen Sie die Entscheidung, wenn Umfang oder Personal sich ändern. Das Raster zeigt laufende Arbeit, bevor eine neue Domain registriert wird.