DEV Community: René

Die unsichtbare Empfehlung

René — Wed, 10 Jun 2026 13:46:43 +0000

Eine Kundin erzählte uns kürzlich, wie sie ihren neuen Steuerberater gefunden hat. Nicht über Google, nicht über eine Empfehlung aus dem Bekanntenkreis. Sie hat ChatGPT gefragt: "Welcher Steuerberater in Münster kennt sich mit E-Commerce aus?" Drei Namen kamen zurück. Einen davon hat sie angerufen.

Zwei Dinge sind an dieser Geschichte bemerkenswert. Erstens: Die Kundin fand den Vorgang völlig normal. Zweitens: Die anderen Steuerberater in Münster werden nie erfahren, dass sie an diesem Tag nicht in Frage kamen. Es gab keine Suchergebnisseite, auf der sie weiter unten standen. Sie kamen schlicht nicht vor.

Eine neue Art, gefunden zu werden

Über zwei Jahrzehnte lang war die Frage klar: Wer bei Google auf Seite eins steht, bekommt die Anfragen. Diese Frage gilt weiterhin — aber sie hat Gesellschaft bekommen. ChatGPT, Perplexity, Googles KI-Übersichten: Immer häufiger spricht ein Assistent eine Empfehlung aus, statt zehn blaue Links anzuzeigen.

Der Unterschied ist größer, als er zunächst wirkt. Eine Suchergebnisseite zeigt Optionen, und der Mensch wählt. Ein Assistent wählt vor — und nennt drei Namen, manchmal nur einen. Wer nicht genannt wird, existiert für diesen Kunden nicht. Es gibt kein "weiter unten" mehr, in dem man wenigstens noch sichtbar wäre.

Warum viele Websites für KI unsichtbar sind

Die gute Nachricht zuerst: KI-Assistenten erfinden ihre Empfehlungen nicht. Sie lesen das Netz — Websites, Verzeichnisse, Bewertungen, Fachartikel. Wer dort klar und maschinenlesbar auftritt, wird gefunden. Wer nicht, bleibt stumm.

Und genau hier scheitern viele Unternehmensseiten. Die typischen Gründe kennen wir aus unseren Audits:

Die Seite sagt nicht, was sie ist. Ein Friseursalon, dessen Startseite nur "Willkommen" und ein Stimmungsbild zeigt, mag Menschen gefallen. Eine Maschine, die in Sekundenbruchteilen entscheidet, ob diese Seite die Frage "guter Friseur für Locken in Köln" beantwortet, findet darin: nichts. Was Sie anbieten, für wen, und wo — das gehört in Text, nicht nur ins Gefühl.

Es fehlen strukturierte Daten. Schema.org-Auszeichnungen (LocalBusiness, Öffnungszeiten, Leistungen, Bewertungen) sind das Vokabular, in dem Maschinen Unternehmen verstehen. Sie kosten nichts, sind unsichtbar für Besucher — und werden von den meisten Baukasten-Seiten schlicht weggelassen. Warum Vorlagen-Websites auch darüber hinaus an ihre Grenzen stoßen, haben wir im Beitrag Tausend Betriebe, eine Vorlage beschrieben.

Die Seite ist technisch schwer lesbar. Was sich nur per JavaScript zusammensetzt, in Sekunden lädt statt in Millisekunden, oder hinter Pop-ups versteckt, wird von Crawlern ungern und unvollständig gelesen. Schnelle, statisch ausgelieferte Seiten haben hier denselben Vorteil, den sie bei Google schon immer hatten — nur dass er jetzt doppelt zählt.

Das Unternehmen existiert nur auf der eigenen Website. KI-Modelle gewichten, was an mehreren Stellen übereinstimmend steht. Ein gepflegtes Google-Unternehmensprofil, Einträge in seriösen Branchenverzeichnissen, echte Bewertungen, vielleicht eine Erwähnung in der Lokalpresse — jedes dieser Signale bestätigt: Dieses Unternehmen gibt es wirklich, und es ist das, was es behauptet.

Was sich für Sie nicht ändert

Man könnte nun in Hektik verfallen und nach "KI-Optimierung" suchen wie 2005 nach Meta-Keywords. Unnötig. Denn das Bemerkenswerte ist: Fast alles, was eine Website für KI-Assistenten sichtbar macht, ist seit Jahren guter Handwerksstandard. Klare Inhalte, die Fragen Ihrer Kunden beantworten. Saubere Technik. Strukturierte Daten. Konsistente Einträge. Schnelle Ladezeiten — genau die Punkte, auf die wir bei Tinte&Pixel bei jedem Projekt von Beginn an achten.

Wer seine Website in den letzten Jahren ordentlich gebaut hat, ist bereits gut aufgestellt. Wer sie als digitale Visitenkarte ohne Substanz betreibt, war schon bei Google im Nachteil — jetzt wird aus dem Nachteil Unsichtbarkeit.

Unsere Schwesteragentur Webgaudi in Wien hat schon vor Jahren beschrieben, was sich an der Suchmaschinenoptimierung durch KI verändert hat — die Kernaussage gilt unverändert: Es gewinnt nicht, wer trickst, sondern wer verständlich ist. Für Menschen wie für Maschinen.

Ein einfacher Selbsttest

Fragen Sie heute Abend ChatGPT, was es über Ihr Unternehmen weiß. Fragen Sie es, wen es für Ihre Leistung in Ihrer Stadt empfehlen würde. Die Antwort ist ein ehrlicher Spiegel Ihrer digitalen Präsenz — ehrlicher als jedes Ranking, weil es kein "Platz 8" gibt, mit dem man sich trösten könnte.

Wenn Ihr Name fällt: gut gemacht. Wenn nicht, wissen Sie jetzt, woran es liegt. Und dass es sich beheben lässt. Erzählen Sie uns einfach kurz von Ihrem Vorhaben — wir geben Ihnen eine ehrliche Einschätzung.

How We Ship 100/100 PageSpeed Sites for Small-Business Clients (Without a CMS)

René — Wed, 10 Jun 2026 13:41:07 +0000

Most small-business websites are slow. Not because the businesses don't care, but because the default stack they get sold — a heavyweight CMS, a page builder, twelve plugins — fights against performance from day one.

At webgaudi.at, our small web studio in Vienna, we build sites for therapists, lawyers, electricians and restaurants. Tiny budgets, no dev team on the client side, and one hard promise we make: 100/100 on PageSpeed Insights, mobile and desktop. Here's the actual playbook — no secrets, just decisions that compound.

1. Static-first with Astro: ship zero JS by default

The single biggest lever is architectural. A brochure site for a psychotherapist has maybe one interactive element (a contact form, an FAQ accordion). It does not need a client-side framework, and it definitely doesn't need a database rendering pages on every request.

We use Astro because its islands architecture makes "zero JavaScript" the default instead of an optimization:

---
// FaqSection.astro — pure HTML/CSS, no JS shipped
const faqs = await getCollection('faq');
---
{faqs.map((faq) => (
  <details>
    <summary>{faq.data.question}</summary>
    <div set:html={faq.rendered.html} />
  </details>
))}

Native <details>/<summary> gives you an accessible accordion for free. The temptation to reach for a React component here is real — resist it. Every island you don't ship is hydration cost you never pay.

When we do need interactivity, we scope it:

<ContactForm client:visible />

client:visible means the form's JS only loads when it scrolls into view. On a typical landing page, that's the difference between 0 KB and 40 KB of JS on initial load.

2. Images: the 80% problem

Almost every failing Lighthouse audit we inherit comes down to images. Our rules:

Author in highest quality, let the build optimize. Astro's <Image /> component generates AVIF/WebP, correct srcset, and explicit dimensions (no layout shift):

import { Image } from 'astro:assets';
import hero from '../assets/hero.jpg';

<Image src={hero} alt="..." widths={[400, 800, 1200]} format="avif" />

The LCP image gets loading="eager" and fetchpriority="high". Everything below the fold gets lazy-loaded. Getting this one attribute right is often worth 0.5–1s of LCP.
No icon libraries. Inline the 6 SVGs you actually use. A 200 KB icon font for a hamburger menu is how good scores die.

3. Fonts without the FOIT (and without the GDPR headache)

We self-host fonts as subsetted WOFF2 with font-display: swap and preload only the body font:

<link rel="preload" href="/fonts/inter-latin.woff2" as="font" type="font/woff2" crossorigin>

Side note for anyone building for EU clients: loading fonts from Google's CDN has been a legal problem since a 2022 German court ruling (LG München) — a visitor's IP gets transmitted to Google without consent. Self-hosting fixes performance and compliance in one move. Two birds.

4. Edge delivery instead of a single origin server

Static output means the whole site can live on a CDN. We deploy to an edge network so a site for a Viennese client loads just as fast for someone visiting from a hotel WiFi in Lisbon. TTFB consistently lands under 100ms — something a shared-hosting PHP origin can't match no matter how much you cache.

5. The boring checklist that protects the score

Performance regresses through a thousand small additions. Before every go-live:

Lighthouse CI run on throttled mobile (the real-world case), not desktop
No third-party scripts above the fold; analytics loads deferred and only after consent
One critical CSS file under ~50 KB, no unused framework CSS (we purge aggressively)
viewport meta, explicit width/height on all media, no render-blocking resources
Accessibility pass: semantic landmarks, contrast, focus states — Lighthouse's a11y score is part of the 100/100 promise, not an afterthought

What this means for clients (the part nobody measures)

The interesting outcome isn't the green circle — it's behavior. Average load time across our portfolio is ~0.8s, and the bounce-rate difference compared to the WordPress sites we replace is dramatic. Studies keep showing mobile users abandon pages after roughly 4 seconds; for a small business where the website is the sales funnel, that's lost revenue, not a vanity metric.

If you're a freelancer or studio serving small businesses, my honest pitch: static-first isn't a constraint, it's a feature you can sell. Faster sites, lower hosting costs, smaller attack surface, no plugin update treadmill.

I run webgaudi.at, a small web studio in Vienna building fast, GDPR-compliant sites for SMBs in Austria, Germany and Switzerland. Happy to answer questions about the stack in the comments — especially if you're fighting your own PageSpeed battles.