Montagmorgen öffne ich Google Search Console und sehe eine Seite, die für die Suchanfragen, auf die sie eigentlich abzielt, praktisch unsichtbar ist. Nicht wegen fehlender Inhalte — die waren da. Sondern weil die Seite strukturell nicht signalisiert hat, für wen sie ist und was sie kostet. Eine Woche SEO-Tiefenarbeit an theapparchitect.com später sieht das anders aus.
Die Seite kennt jetzt ihre Käufer
Der größte konzeptionelle Schritt dieser Woche war das Umdenken von “Inhalte über App-Entwicklung” zu “Seiten, die Kaufentscheidungen unterstützen”. Das ist ein Unterschied, der sich in fast jeder Datei niedergeschlagen hat.
Pricing-Seiten und buyer-intent Keywords
Bisher gab es keine dedizierte Seite, die direkt auf Suchanfragen wie “iOS App entwickeln lassen Kosten” oder “App Entwickler Preise” geantwortet hat. Ich habe zwei neue Landingpages eingebaut: /pricing auf Englisch und /preise auf Deutsch. Beide sind keine Preislisten — die gibt es nicht, weil jedes Projekt anders ist — sondern strukturierte Seiten, die erklären, wie Preise entstehen, welche Faktoren zählen und was ein realistisches Budget bedeutet. Dazu habe ich auf der Startseite und der Kontaktseite gezielt buyer-intent Keywords 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 Hochglanz-Beschreibung meiner Fähigkeiten. Er braucht Orientierung: Was kostet das ungefähr? Wer macht das? Wann ist das sinnvoll?
Schema-Tiefe: HowTo, MobileApplication, PriceSpecification
Die letzte SEO-Runde vor ein paar Wochen hatte JSON-LD-Blöcke für die wichtigsten Entitäten eingebaut. Diese Woche bin ich tiefer gegangen. Ich habe auf der Startseite ein FAQPage-Schema ergänzt — acht Fragen mit echten Antworten, direkt aus dem Seiteninhalt gezogen, nicht als versteckter Block. Auf den App-Seiten habe ich MobileApplication-Schema mit aggregateRating eingebaut, wo reale App-Store-Bewertungen vorliegen. Und für die Pricing-Seiten habe ich PriceSpecification angelegt, das Suchmaschinen und KI-Systemen signalisiert, in welchem Preisbereich sich die Dienstleistung bewegt.
Das HowTo-Schema auf den passenden Blogposts war eine Entscheidung, bei der ich zweimal angesetzt habe. Mein erster Versuch hat das Schema zu mechanisch aufgebaut — Step 1, Step 2, Step 3 — ohne echte Verbindung zum Text. Das hat sich falsch angefühlt. Im zweiten Durchgang habe ich die Steps direkt aus den H2-Abschnitten des Artikels abgeleitet, sodass Schema und Inhalt dieselbe Struktur teilen. Das hätte ich von Anfang an so machen sollen.
Breadcrumbs, Related Posts und ein stiller CSS-Bug
Auf jeder Inhaltsseite zeigt die Website jetzt strukturierte Breadcrumbs — sowohl sichtbar im UI als auch als BreadcrumbList in JSON-LD. Und am Ende jedes Blogposts erscheinen Related Posts, die thematisch verwandte Artikel verlinken. Beides klingt nach Kleinigkeiten; beide haben länger gedauert als erwartet, weil die Datenstruktur in Astro’s Content Collections dafür leicht umgebaut werden musste.
Den CSS-Bug erwähne ich, weil er mich kurz aus dem Konzept gebracht hat. Ich hatte einen Scroll-Progress-Balken eingebaut — der schmale Streifen am oberen Rand eines Artikels, der zeigt, wie weit man beim Lesen ist. Der hat nicht animiert. Die Ursache: Tailwinds scale-x-0 Utility und ein inline transform: scaleX() im JavaScript haben sich gegenseitig überschrieben. Tailwind hat gewonnen — also nie. Ich habe die Tailwind-Klasse rausgeworfen und das Scaling vollständig über CSS scale property gesteuert. Funktioniert jetzt. Solche Bugs sind harmlos, aber sie kosten Zeit, die man für etwas Sinnvolleres hätte brauchen können.
Nebenbaustelle: marcelrgberger.com
Parallel habe ich auf meiner persönlichen Portfolio-Seite zwei Dinge angepasst. Erstens: App-Karten, die bisher direkt auf den App Store verlinkt haben, zeigen jetzt auf eigene Landingpages auf der Domain — von dort geht es weiter zum App Store. Das gibt mir eine eigene Seite pro App, auf der ich mehr Kontext geben kann, als ein App-Store-Listing erlaubt. Zweitens habe ich das Entity-Signal für meinen Namen gestärkt: “Marcel R. G. Berger” steht jetzt in der H1, das Person-Schema ist angereichert, und ein echtes Foto ersetzt den Platzhalter. Das ist das Minimum, damit eine KI-Suche oder ein Knowledge Graph mich als identifizierbare Person behandelt, nicht als Textfragment.
Das klingt eitel. Ist es nicht ganz. 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 dich bedeutet, wenn du eine App bauen lässt
Eine Sache, die ich diese Woche mehrfach gedacht habe: Die Arbeit an meiner eigenen Website ist dieselbe Arbeit, die ich für Kundenprodukte mache. Schema richtig aufbauen, Inhalte auf Kaufentscheidungen ausrichten, technische Bugs finden und sauber fixen — das ist keine separate Disziplin vom App-Bauen. Es ist dieselbe Denkweise: Wer ist der Nutzer, was braucht er, warum funktioniert das noch nicht.
Wenn du überlegst, eine eigene App oder Web-Anwendung entwickeln zu lassen, und dir noch nicht sicher bist, was das kostet oder wie das abläuft, schau auf /preise — da habe ich diese Woche genau dafür Antworten geschrieben.
Die vollständige Leistungsübersicht liegt unter /services/.