Homepage oder Portal? Woran Sie erkennen, dass Ihr Webauftritt die Grenze überschreitet
Vier Merkmale zeigen, ob Ihr Webauftritt ein Portal ist: Login, Rollen, personalisierte Daten, Systemanbindung. Dazu Portaltypen, Pflichten, Betriebsaufwand.

Die Frage nach einem Homepage Portal wird selten technisch gestellt. Sie entsteht im Alltag, wenn Kunden nach ihren Rechnungen fragen, wenn Mitarbeitende Dokumente suchen, die per E-Mail verteilt wurden, oder wenn eine Preisliste nur bestimmte Partner sehen sollen. Der Wunsch klingt anfangs nach einer weiteren Unterseite. Tatsächlich ist es der Punkt, an dem ein Webauftritt funktional die Seite wechselt: von einer Publikation, die für alle gleich aussieht, zu einem System, das weiß, wer davorsitzt.
Dieser Ratgeber zieht diese Grenze. Er beantwortet, ab wann ein Auftritt funktional ein Portal ist, welche Portaltypen es gibt, woran Sie die Entscheidung festmachen, welche Pflichten im geschützten Bereich zusätzlich gelten, womit Sie im Betrieb dauerhaft rechnen müssen und wie ein Weg von der bestehenden Homepage dorthin aussieht.
Vier Merkmale trennen Homepage und Portal
Eine Homepage ist eine öffentliche Veröffentlichung. Jeder Besucher bekommt dieselben Inhalte, der Server muss niemanden wiedererkennen, und der Inhalt ändert sich nur, wenn jemand ihn manuell ändert. Ein Portal unterscheidet sich in vier Punkten. Treffen alle vier zu, ist die Frage entschieden. Treffen nur ein oder zwei zu, gibt es fast immer eine schlankere Lösung.
1. Identität. Es gibt einen Login, also eine Anmeldung, die eine Person oder Organisation identifiziert. Damit entstehen Konten, Passwörter, Zurücksetzungswege, Sperrungen und ein Lebenszyklus vom Anlegen bis zum Löschen.
2. Rollen und Rechte. Angemeldete sehen nicht alle dasselbe. Ein Kunde sieht seine Vorgänge, ein Sachbearbeiter mehrere, eine Leitung alle. Jede Ansicht und jede Aktion braucht eine Regel, wer sie ausführen darf.
3. Personalisierte Inhalte. Die Seite zeigt Daten, die zu genau diesem Konto gehören: Verträge, Tickets, Termine, Verbräuche, Bestellhistorie. Diese Inhalte werden nicht redaktionell gepflegt, sie werden erzeugt.
4. Aggregation aus angebundenen Systemen. Die Daten stammen aus ERP, CRM, Warenwirtschaft, Ticketsystem oder DMS. Das Portal ist die Oberfläche, nicht die Quelle. Damit hängt seine Verfügbarkeit an Schnittstellen, die jemand betreiben muss.
| Merkmal | Homepage | Portal |
|---|---|---|
| Zugang | offen | Anmeldung erforderlich |
| Inhalt | für alle identisch | je Konto verschieden |
| Datenquelle | Redaktion, CMS | Fachsysteme über Schnittstellen |
| Änderungsauslöser | redaktionelle Entscheidung | Vorgang im Fachsystem |
| Ausfallfolge | Sichtbarkeit fehlt | Prozess steht |
Die letzte Zeile ist die wichtigste. Sie beschreibt, warum ein Portal eine andere Betriebsklasse ist als eine Website. Fällt eine Homepage aus, fehlt die Sichtbarkeit. Fällt ein Portal aus, steht ein aktiver Prozess für die Nutzer still.
Portaltypen und wozu sie gebaut werden
Kundenportal. Vertragsdaten, Rechnungen, Statusabfragen, Serviceanfragen. Ziel ist meist Entlastung: Auskünfte, die heute telefonisch erteilt werden, werden selbst abgerufen.
Mitarbeiter- oder Intranetportal. Interne Dokumente, Formulare, Urlaubsanträge, Schichtpläne. Ziel ist Auffindbarkeit und ein verbindlicher Stand statt verteilter Dateiversionen.
Partner- und Händlerportal. Konditionen, Schulungsmaterial, Bestellwege für einen definierten Kreis. Ziel ist Abstufung: Nicht jeder Partner sieht dieselben Bedingungen.
Lieferantenportal. Ausschreibungen, Bestellungen, Rückmeldungen, Belege. Ziel ist ein dokumentierter Austausch anstelle von E-Mail-Anhängen.
Mitglieder- oder Verbandsportal. Geschützter Wissensbereich, Veranstaltungen, Beitragsdaten. Ziel ist Mitgliederbindung an einen exklusiven Bestand.
Buchungs- und Serviceportal. Termine, Kapazitäten, Statusverfolgung. Ziel ist Selbstbedienung an einem Prozess mit Rückschreibung ins Fachsystem.
Die Typen unterscheiden sich weniger in der Technik als im Rechtemodell und in der Frage, wer die Konten anlegt und wieder entzieht. Ein Kundenportal erfordert oft eine self-service Registrierung, während ein Mitarbeiterportal Konten aus dem zentralen Verzeichnis bezieht.
Entscheidungskriterien: sechs Fragen vor der Entscheidung
Gibt es Inhalte, die wirklich nur bestimmte Personen sehen dürfen? Wenn die ehrliche Antwort lautet “eigentlich könnte es jeder sehen, es soll nur nicht gefunden werden”, ist ein Portal die falsche Antwort. Dann genügen eine nicht verlinkte Seite oder ein Downloadbereich mit Formular.
Existiert eine führende Datenquelle? Ein Portal, dessen Inhalte manuell nachgepflegt werden, erzeugt doppelte Pflege und veraltet innerhalb weniger Monate. Ohne anbindbares Fachsystem fehlt die funktionale Grundlage.
Wie viele Vorgänge pro Monat betrifft es? Der Aufwand für Konten, Rechte und Betrieb amortisiert sich über Wiederholung. Bei wenigen Vorgängen im Monat ist ein strukturierter E-Mail- oder Telefonweg günstiger und robuster.
Wer pflegt Konten und Rechte? Diese Rolle muss benannt sein, bevor gebaut wird. Sie ist dauerhaft, nicht projektbezogen, und sie ist der häufigste Grund, warum Portale nach zwei Jahren verwaisen.
Was passiert bei Ausfall? Wenn ein Ausfall nur die Website betrifft, ist die Lage entspannt. Wenn er einen Kundenprozess unterbricht, brauchen Sie Reaktionszeiten, Ansprechpartner und einen Ersatzweg.
Ist der Bedarf abgrenzbar? Portale wachsen. Ein klar umrissener erster Anwendungsfall, etwa nur Rechnungsabruf, ist besser als ein offener Funktionskatalog, der am Ende niemanden vollständig zufriedenstellt.
Pflichten, die erst im geschützten Bereich entstehen
Der öffentliche Teil eines Auftritts bringt bekannte Pflichten mit. Geschäftsmäßig angebotene digitale Dienste müssen eine leicht erkennbare, unmittelbar erreichbare und ständig verfügbare Anbieterkennzeichnung bereithalten. Diese Pflicht steht seit dem 14. Mai 2024 in § 5 DDG und löste den gleichlautenden § 5 TMG ab. Praktisch heißt “ständig verfügbar”, dass sie auch hinter dem Login erreichbar bleiben muss, nicht nur auf der öffentlichen Startseite.
Mit Konten und personenbezogenen Daten kommt Artikel 32 Absatz 1 DSGVO hinzu: Wer personenbezogene Daten verarbeitet, muss geeignete technische und organisatorische Maßnahmen treffen, die dem Risiko angemessen sind. Ausdrücklich genannt werden unter anderem Verschlüsselung sowie die Fähigkeit, Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme sicherzustellen. Ergänzend verpflichtet Artikel 25 DSGVO auf Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. Voreingestellt dürfen nur solche personenbezogenen Daten verarbeitet werden, die für den jeweiligen Verarbeitungszweck erforderlich sind. Für ein Portal bedeutet das eine unbequeme Frage schon im Entwurf: Welche Felder brauchen wir wirklich, und wie lange?
Für die Umsetzung existieren belastbare Referenzen, die eine Abnahme prüfbar machen. Der Baustein APP.3.1 “Webanwendungen” des BSI IT-Grundschutz-Kompendiums formuliert Basis-Anforderungen für Authentisierung, Session-Verwaltung und Zugriffskontrolle von Webanwendungen. Dass gerade die Zugriffskontrolle der kritische Punkt ist, zeigt die Risikoseite: In den OWASP Top 10 in der Ausgabe 2021 steht “Broken Access Control” auf Rang 1 der häufigsten Sicherheitsrisiken von Webanwendungen. Das ist genau die Kategorie, die durch Rollen- und Rechtelogik eines Portals überhaupt erst entsteht. Wer Rechte einführt, führt damit auch die häufigste Schwachstellenklasse ein.
Wenn Nutzer sich mit vorhandenen Konten anmelden sollen, etwa aus einem Unternehmensverzeichnis, führt der Weg über etablierte Standards statt über Eigenbau. OAuth 2.0 ist als Autorisierungs-Framework in RFC 6749 spezifiziert und bildet die Grundlage vieler Single-Sign-On-Anbindungen in Portalen.
Zuletzt die Barrierefreiheit. Das Barrierefreiheitsstärkungsgesetz gilt seit dem 28. Juni 2025 unter anderem für Dienstleistungen im elektronischen Geschäftsverkehr gegenüber Verbrauchern und kann damit auch verbraucherbezogene Portalbereiche erfassen. Ob Ihr konkreter Fall darunterfällt, hängt von Angebot, Adressatenkreis und Unternehmensgröße ab und gehört rechtlich geprüft, bevor der Funktionsumfang festgezurrt wird.
Betriebsaufwand: was nach dem Launch bleibt
Ein Portal ist kein Projekt mit Enddatum, sondern ein Dienst. Dauerhaft anfallen:
- Kontenpflege: anlegen, sperren, löschen, Passwörter zurücksetzen, Austritte nachvollziehen.
- Rechtepflege: neue Rollen, geänderte Zuständigkeiten, regelmäßige Kontrolle, wer was noch sehen darf.
- Aktualisierung: Updates für Anwendung und Abhängigkeiten, mit Testlauf statt Direkteinspielung.
- Schnittstellenbetrieb: Fachsysteme ändern Formate und Versionen. Jede Änderung dort ist eine Aufgabe hier.
- Sicherung und Wiederherstellung: eine Sicherung zählt erst, wenn ihre Wiederherstellung einmal geübt wurde.
- Protokollierung und Reaktion: fehlgeschlagene Anmeldungen, ungewöhnliche Zugriffe, ein benannter Ansprechpartner.
- Support: Menschen, die nicht hineinkommen, melden sich, und zwar an Werktagen morgens.
Diese Liste ist der eigentliche Preis der Entscheidung. Sie sollte vor der Beauftragung stehen, nicht danach.
Migrationspfad von der bestehenden Homepage
Der sinnvolle Weg ist stufenweise, weil jede Stufe für sich Nutzen bringt und abgebrochen werden kann.
Stufe 1: Bedarf belegen. Zählen Sie von 14 bis 28 Tagen lang, welche Auskünfte tatsächlich angefragt werden und wie oft. Ergebnis ist eine Liste von Vorgängen, sortiert nach Häufigkeit.
Stufe 2: Einen Vorgang auswählen. Der erste Anwendungsfall ist der häufigste mit der klarsten Datenquelle. Alles andere wird notiert und zurückgestellt.
Stufe 3: Rollenmodell festlegen. Wer sieht was, wer darf was, wer vergibt Rechte, wer entzieht sie. Dieses Modell wird schriftlich beschrieben, bevor Technik gewählt wird, und es überlebt jeden späteren Systemwechsel.
Stufe 4: Trennung von öffentlich und geschützt. Die bestehende Homepage bleibt, was sie ist. Der geschützte Bereich kommt als abgegrenzter Teil hinzu, technisch und redaktionell getrennt, damit Sichtbarkeit und Schutzbedarf sich nicht gegenseitig behindern. Geschützte Inhalte gehören nicht in Suchmaschinen, öffentliche Inhalte nicht hinter den Login.
Stufe 5: Pilot mit echten Nutzern. Eine kleine, benannte Gruppe, echte Daten, begleiteter Betrieb. Ziel ist nicht Begeisterung, sondern die Liste der Missverständnisse.
Stufe 6: Ausrollen und Altweg schließen. Erst wenn der Vorgang im Portal nachweislich funktioniert, wird der bisherige Weg beendet. Läuft beides dauerhaft parallel, entsteht Doppelarbeit statt Entlastung.
Fazit
Ein Homepage Portal beginnt nicht bei einer Funktion, sondern bei einer Verpflichtung: Sie betreiben ab diesem Moment ein System, das Personen kennt, Rechte durchsetzt und in Prozesse eingreift. Prüfen Sie die vier Merkmale, beantworten Sie die sechs Fragen ehrlich, kalkulieren Sie den Betrieb mit und gehen Sie stufenweise vor. Fällt die Antwort gegen das Portal aus, ist das kein Rückschritt, sondern eine der wirtschaftlichsten Entscheidungen, die Sie an dieser Stelle treffen können.
