timrutte.de: aus vielen Themen eine Positionierung

Zur Einordnung: timrutte.de ist deutlich umfangreicher als eine typische Unternehmenswebsite aus dem Standardpaket und war kein Projekt zum Festpreis. Die zugrunde liegende Methode ist dieselbe: Positionierung, Struktur, Inhalte, Design, Umsetzung, in dieser Reihenfolge. Diese Case Study zeigt die Methode, nicht den Lieferumfang des Standardpakets.

Die Ausgangslage

Tim arbeitet seit über 20 Jahren mit Software. In dieser Zeit sind Themen zusammengekommen: Programmiersprachen, Plattformen, Branchen, Projektarten, Rollen. Jedes davon ließe sich zu einem Angebot ausbauen, und jedes war irgendwann einmal der Schwerpunkt.

Genau das war das Problem. Eine Website kann nicht alles gleich stark verkaufen. Wer sieben Themen gleichwertig nebeneinanderstellt, zwingt jeden Besucher, sich selbst herauszusuchen, ob er richtig ist. Und die meisten tun das nicht, sondern gehen wieder.

Dazu kam die Wirkung nach hinten: Ohne Priorisierung konkurrieren die eigenen Seiten in der Suche gegeneinander. Zwei Seiten zum selben Thema teilen sich die Sichtbarkeit, statt sie zu bündeln.

Das Problem war nicht das Design

Die naheliegende Aufgabe wäre gewesen, die Seite neu zu gestalten. Die eigentliche Aufgabe war eine andere. Zu klären war:

• Was soll ein Besucher nach fünf Sekunden verstanden haben?
• Welche Leistungen gehören zusammen, welche stehen für sich?
• Welche Themen sind Kern, welche sind Kompetenz?
• Welche Inhalte tragen die Startseite, welche brauchen eine eigene Seite?
• Welche Suchintention gehört welcher Seite, und zwar exklusiv?

Solange diese Fragen offen sind, ist jede Gestaltungsentscheidung geraten. Man kann eine Seite hübsch machen, ohne zu wissen, was sie sagen soll. Man kann sie nicht wirksam machen.

Erst Klarheit. Dann Design.

Die Positionierung wurde auf zwei Säulen reduziert: Software- und Legacy-Modernisierung sowie AWS und Cloud. Der Kern in einem Satz: Es geht um Architekturprobleme in Systemen, die bereits laufen und Geld verdienen, nicht um Neubau auf der grünen Wiese und nicht um Beratung ohne Umsetzung.

Die Entscheidung, die am meisten verändert hat

KI und agentisches Arbeiten wurden nicht als gleichwertige dritte Säule positioniert.

Das war keine Geringschätzung des Themas, sondern eine Konsequenz aus der Prüfung: Die Website erzählte drei gleichberechtigte Säulen, obwohl das Angebot auf zweien steht. Der Startseitentitel hieß „Architekt für geschäftskritische AWS- & KI-Systeme”, die Kurzform überall „Cloud & AI Architect”. Damit stand auf der Domain, ein Drittel des Geschäfts sei KI-Architektur. Und das stimmte nicht.

Seitdem sind KI und agentisches Arbeiten das, was sie tatsächlich sind: Kompetenz und Arbeitsweise, beauftragbar, prägend für die Art zu liefern. Die Leistungsseite sagt das heute wörtlich: zwei Arten von Problemen, dazu ein Spezialgebiet, „ohne dass es ein Drittel meines Geschäfts wäre”.

Eine Säule wegzunehmen fühlt sich nach Verlust an. Für den Besucher ist es das Gegenteil: Er versteht schneller, worum es geht.

Weitere Entscheidungen und ihre Gründe

Legacy steht nicht mehr unter AWS. Im Hero waren die Altlasten zunächst der Cloud untergeordnet. Beide Themen bringen aber eigene Anfragen, und die Unterordnung machte eine davon unsichtbar. Heute nennt der Hero beide nebeneinander.

Rollenbezeichnungen sind verschwunden. „Solutions Architect” und „Staff Software Engineer” beschreiben eine Position in einer fremden Organisation, kein Angebot. Wer ein Problem hat, sucht nicht nach einer Rolle.

Der Markenzusatz ist aus den Titeln geflogen. Alle Seitentitel trugen den Suffix „| Tim Rutte”. Das kostete zwölf der rund sechzig verfügbaren Zeichen und wiederholte, was Google ohnehin als Site-Namen über dem Titel anzeigt.

Jede Seite braucht eine Aufgabe

Aus der Positionierung folgte die Struktur. Leitprinzip: Für jede Suchintention gibt es genau eine zuständige Seite.

Das klingt selbstverständlich und ist es nicht. Bei gewachsenen Websites entstehen Seiten aus Anlässen, nicht aus Intentionen. Und dann gibt es drei Seiten, die alle ungefähr dasselbe beantworten.

Die Themen wurden deshalb in Cluster sortiert und darin je Begriff einer Seite zugeordnet. Unterschiedliche Fragen bekamen unterschiedliche Zielseiten: die Fragen nach einer Rolle etwas anderes als die Fragen nach einer konkreten Migration, und die wieder etwas anderes als die Fragen nach einem Kostenproblem.

Genauso wichtig war, was nicht entstand. Mehrfach wurden Seiten geplant, geprüft und wieder verworfen, weil sie keine eigene Intention besaßen, sondern eine bestehende nur anders formuliert hätten. Eine Seite, die schon gebaut war, wurde nach der Prüfung wieder entfernt.

Damit das nicht vom Gedächtnis abhängt, prüft der Build es mit: Er bricht ab, wenn eine Seite keinem Cluster zugeordnet ist, wenn ein Begriff zwei Besitzer hat oder wenn eine Seite aus ihrem Cluster nicht mehr erreichbar ist.

Was sich verändert hat

Es gibt keine belastbaren Aufnahmen des vorherigen Stands, deshalb hier kein Vorher-Nachher-Vergleich aus Bildern. Der Unterschied lässt sich ohnehin besser beschreiben als zeigen:

Das Ergebnis

Belegbar ist das Strukturelle:

• eine Positionierung, die in einem Satz sagbar ist
• zwei Kernthemen statt mehrerer gleichwertiger
• Suchintentionen, die je einer Seite gehören, geprüft bei jedem Build
• eine Seitenarchitektur, die der Argumentation folgt
• eine statische Basis ohne Wartungsaufwand
• eine Inhaltsstruktur, die mitwächst, ohne neu geschnitten zu werden

Zum Umfang: Die Website umfasst derzeit 311 indexierbare Adressen, davon 155 deutsche und 156 englische.

Was hier nicht steht, sind Rankings, Zugriffszahlen oder Anfragen. Nicht, weil es sie nicht gäbe, sondern weil dafür ein sauber ausgewerteter Zeitraum nötig ist. Sobald der vorliegt, kommt er an diese Stelle.

SEO war Teil der Architektur, nicht ein Schritt danach

SEO wurde nicht nachträglich aufgesetzt. Es war die Struktur selbst:

• sprechende URLs, eine kanonische Form, konsequent
• eigener Title und eigene Beschreibung je Seite, keine Duplikate
• Überschriften, die die Argumentation abbilden und nicht die Optik
• interne Verweise im Fließtext, entlang der Themencluster
• automatisch erzeugte Sitemap, deren Änderungsdatum aus dem Versionsverlauf kommt statt aus dem Build-Zeitpunkt
• strukturierte Daten dort, wo sie sichtbaren Inhalt beschreiben

Der letzte Punkt ist eine kleine Entscheidung mit großer Wirkung: Ein Build-Zeitstempel würde Google bei jedem Deploy melden, alle Seiten hätten sich geändert. Das Signal wäre nach dem dritten Mal wertlos.

Technik, die nicht im Weg steht

Die Website ist statisch. Es gibt kein Redaktionssystem, keine Datenbank und nichts, was im Hintergrund gepflegt werden müsste. Die Seiten werden gebaut und als fertige Dateien ausgeliefert.

Für den Betrieb heißt das: schnelle Auslieferung, wenig Wartung, kein Backend, das jemand aktuell halten muss. Änderungen laufen über den Versionsverlauf, das Deployment ist automatisiert. Umgesetzt ist die Seite mit Astro.

Mehr Technik braucht es an dieser Stelle nicht zu sagen. Sie ist Mittel, nicht Thema.

Warum das auch für kleine Unternehmen gilt

dein Unternehmen hat keine 311 Seiten, und es braucht sie auch nicht. Die Fragen sind trotzdem dieselben:

• Was bietest du an?
• Für wen?
• Was davon ist das Wichtigste?
• Warum du und nicht jemand anderes?
• Was soll der Besucher tun?
• Welche Seite beantwortet welche Frage?

Ein Elektrobetrieb beantwortet sie in einer Stunde, wo eine gewachsene Personenmarke Wochen braucht. Die Reihenfolge bleibt gleich: erst klären, was die Website sagen soll, dann bauen.

Genau das ist der Kern von Website erstellen lassen, nur in einem Umfang, der zu einem Unternehmen mit einem erklärbaren Angebot passt. Welche Inhalte das im Einzelnen sind, steht im Ratgeber Was gehört auf eine Firmenwebsite.