Diese Woche öffne ich die Google Search Console und sehe eine Website, die für genau die Suchanfragen, auf die sie zielt, praktisch unsichtbar ist. Inhalte fehlten nicht, die waren da. Die Seite hat aber strukturell nicht erkennen lassen, für wen sie gedacht ist und was die Leistung kostet. Nach einer Woche gründlicher SEO-Arbeit an theapparchitect.com sieht das anders aus.
Die Seite kennt jetzt ihre Käufer
Der größte gedankliche Schritt dieser Woche war der Wechsel von “Inhalte über App-Entwicklung” zu “Seiten, die Kaufentscheidungen unterstützen”. Dieser Unterschied hat sich in fast jeder Datei niedergeschlagen.
Preisseiten und Suchbegriffe mit Kaufabsicht
Bisher gab es keine eigene Seite, die direkt auf Suchanfragen wie “iOS App entwickeln lassen Kosten” oder “App Entwickler Preise” antwortet. Ich habe zwei neue Landingpages eingebaut: /pricing auf Englisch und /preise auf Deutsch. Beide sind keine Preislisten, denn die gibt es nicht, weil jedes Projekt anders ist. Es sind strukturierte Seiten, die erklären, wie Preise entstehen, welche Faktoren zählen und was ein realistisches Budget bedeutet. Außerdem habe ich auf der Startseite und der Kontaktseite gezielt Suchbegriffe mit Kaufabsicht untergebracht, nicht als Keyword-Stuffing, sondern als Antworten auf Fragen, die jemand stellt, bevor er ein Kontaktformular ausfüllt.
Das fühlt sich richtig an. Wer auf meiner Seite landet und überlegt, eine App bauen zu lassen, braucht keine Hochglanzbeschreibung meiner Fähigkeiten. Er braucht Orientierung: Was kostet das ungefähr? Wer macht das? Wann lohnt es sich?
Mehr Tiefe im Schema: HowTo, MobileApplication, PriceSpecification
Die letzte SEO-Runde vor ein paar Wochen hatte JSON-LD-Blöcke für die wichtigsten Entitäten eingeführt. Diese Woche bin ich tiefer gegangen. Auf der Startseite habe ich ein FAQPage-Schema ergänzt: acht Fragen mit echten Antworten, direkt aus dem Seiteninhalt übernommen und nicht als versteckter Block. Auf den App-Seiten gibt es jetzt ein MobileApplication-Schema mit aggregateRating, wo echte Bewertungen aus dem App Store vorliegen. Für die Preisseiten habe ich PriceSpecification angelegt, das Suchmaschinen und KI-Systemen zeigt, in welchem Preisbereich sich die Leistung bewegt.
Beim HowTo-Schema für die passenden Blogbeiträge habe ich zweimal angesetzt. Im ersten Versuch war das Schema zu mechanisch aufgebaut, Schritt 1, Schritt 2, Schritt 3, ohne echten Bezug zum Text. Das fühlte sich falsch an. Im zweiten Durchgang habe ich die Schritte direkt aus den H2-Abschnitten des Artikels abgeleitet, sodass Schema und Inhalt dieselbe Struktur haben. So hätte ich es von Anfang an machen sollen.
Breadcrumbs, verwandte Beiträge und ein stiller CSS-Fehler
Jede Inhaltsseite zeigt jetzt strukturierte Breadcrumbs, sichtbar in der Oberfläche und zusätzlich als BreadcrumbList in JSON-LD. Am Ende jedes Blogbeitrags erscheinen außerdem verwandte Beiträge zum selben Thema. Beides klingt nach Kleinigkeiten, hat aber länger gedauert als erwartet, weil ich die Datenstruktur in den Content Collections von Astro dafür etwas umbauen musste.
Den CSS-Fehler erwähne ich, weil er mich kurz aus dem Konzept gebracht hat. Ich hatte einen Fortschrittsbalken eingebaut, den schmalen Streifen am oberen Rand eines Artikels, der anzeigt, wie weit man gelesen hat. Er hat sich nicht bewegt. Die Ursache: Die Tailwind-Utility scale-x-0 und ein inline gesetztes transform: scaleX() im JavaScript haben sich gegenseitig überschrieben. Tailwind hat gewonnen, der Balken blieb also immer leer. Ich habe die Tailwind-Klasse entfernt und die Skalierung vollständig über die CSS-Eigenschaft scale gesteuert. Jetzt funktioniert es. Solche Fehler sind harmlos, kosten aber Zeit, die man sinnvoller hätte nutzen können.
Nebenbaustelle: marcelrgberger.com
Parallel habe ich auf meiner persönlichen Portfolio-Seite zwei Dinge angepasst. Erstens zeigen die App-Karten, die bisher direkt in den App Store führten, jetzt auf eigene Landingpages unter meiner Domain, von denen es weiter in den App Store geht. So habe ich für jede App eine eigene Seite mit mehr Kontext, als ein Eintrag im App Store zulässt. Zweitens habe ich meinen Namen als Entität klarer kenntlich gemacht: “Marcel R. G. Berger” steht jetzt in der H1, das Person-Schema ist erweitert, und ein echtes Foto ersetzt den Platzhalter. Das ist das Mindeste, damit eine KI-Suche oder ein Knowledge Graph mich als erkennbare Person behandelt und nicht als Textfragment.
Das klingt eitel, ist es aber nur bedingt. Wenn jemand meinen Namen sucht, bevor er mich kontaktiert, und das tun die meisten, dann sollte die Seite eindeutig und vollständig antworten.
Was das für Sie bedeutet, wenn Sie eine App bauen lassen
Ein Gedanke kam mir diese Woche mehrmals: Die Arbeit an meiner eigenen Website ist dieselbe Arbeit, die ich für Kundenprodukte leiste. Schema richtig aufbauen, Inhalte auf Kaufentscheidungen ausrichten, technische Fehler finden und sauber beheben: Das ist keine eigene Disziplin neben dem App-Bau, sondern dieselbe Denkweise. Wer ist der Nutzer, was braucht er, und warum funktioniert es noch nicht?
Wenn Sie überlegen, eine eigene App oder Webanwendung entwickeln zu lassen, und noch nicht wissen, was das kostet oder wie es abläuft, schauen Sie unter Preise nach. Genau dafür habe ich diese Woche die Antworten geschrieben.
Die vollständige Übersicht finden Sie unter Leistungen.