CMS Entwicklung

Vor der Systemfrage steht die Inhaltsfrage. Wir sehen uns an, welche Arten von Inhalten es gibt, wie sie zusammenhängen und wer sie pflegt. Aus Standorten, Produkten, Personen, Downloads und Beiträgen wird ein Modell mit eigenen Inhaltstypen, Feldern und Taxonomien. Dieses Modell entscheidet später darüber, ob sich ein Inhalt an mehreren Stellen ausspielen lässt oder ob jede neue Seite Handarbeit bleibt.

Erst danach fällt die Wahl des Systems. WordPress ist gesetzt, wenn Redaktion, Erweiterbarkeit und ein großes Ökosystem im Vordergrund stehen. Strapi oder ein vergleichbares Headless-System passt, wenn Inhalte an mehrere Ausgabekanäle gehen, etwa an eine Website und zusätzlich an eine App oder ein Display im Ladengeschäft. Eine eigene Lösung bauen wir dann, wenn das Datenmodell so speziell ist, dass jedes fertige System dagegen arbeitet.

Zur Umsetzung gehören Rollen und Rechte, eine Vorschau, Medienverwaltung, Suche und die Schnittstellen zu vorhandenen Systemen wie PIM, CRM oder Warenwirtschaft. Wo Daten aus einem anderen System kommen, klären wir früh, welche Seite die führende ist.

Ein CMS lohnt sich, sobald Inhalte mehr als gelegentlich wechseln und mehr als eine Person daran arbeitet. Typische Anlässe sind eine Website, die stetig um Standorte, Produkte oder Stellenanzeigen wächst, ein Blog mit fester Taktung, ein Presse- oder Newsbereich oder eine zweite Sprachversion. Auch die Ablösung einer statischen Seite, an der bisher nur die Agentur Hand anlegen konnte, gehört dazu.

Nicht jedes Projekt braucht ein CMS. Eine einzelne Landingpage, deren Text sich im Jahr zweimal ändert, ist ohne Redaktionssystem schneller gebaut und einfacher im Betrieb. Auch bei Anwendungen, deren Inhalte vollständig aus einem anderen System stammen, etwa aus einem PIM oder einer Warenwirtschaft, ist eine zweite Redaktionsebene eher Ballast als Hilfe.

Der Nutzen zeigt sich im Alltag. Wenn ein Ansprechpartner, ein Öffnungszeitenhinweis oder ein Datenblatt in wenigen Minuten aktualisiert ist, ohne dass jemand ein Ticket schreiben muss, hat sich das System bereits gerechnet. Umgekehrt bleibt ein CMS wirkungslos, wenn im Unternehmen niemand die Verantwortung für Inhalte übernimmt.

Ein CMS wird nicht dadurch gut, dass es viel kann, sondern dadurch, dass die Redaktion damit zurechtkommt. Wir vergeben Rollen entlang der tatsächlichen Zuständigkeiten, richten eine Vorschau ein, die dem späteren Frontend entspricht, und halten die Eingabemasken knapp. Felder, die niemand ausfüllt, gehören nicht ins Backend. Wo eine Freigabe nötig ist, bilden wir sie als Status ab und nicht als Absprache per Mail.

Mehrsprachigkeit fällt früh an. Es macht einen Unterschied, ob Sprachversionen identisch aufgebaut sind und übersetzt werden oder ob jedes Land eigene Seiten, eigene Navigation und eigene Inhalte bekommt. Der zweite Fall braucht getrennte Sprachbäume, sonst arbeitet die Redaktion dauerhaft gegen die Struktur. Dazu gehören der URL-Aufbau, ein Sprachwechsler, der auf die passende Übersetzung zeigt, und korrekte hreflang-Angaben.

Ein häufiger Fehler ist es, Layout im Text zu speichern. Sobald Inhalte Formatierung mitschleppen, lassen sie sich weder zuverlässig übersetzen noch in einem anderen Kanal wiederverwenden.