Physiotherapie Murgenthal (AG) — geprüft wurde die aktuelle Live-Website (WordPress). Rundum-Prüfung über acht Säulen: technisches SEO, Rechtssicherheit & Datenschutz, Barrierefreiheit, Conversion, lokale Auffindbarkeit, Trust & Sicherheit, Mobile-UX und KI-Sichtbarkeit (GEO) — belegt aus den real ausgelieferten HTML-, Header-, Sitemap-, DNS- und Google-Lighthouse-Daten.
Positiv fällt sofort auf: Die Seite lädt keinerlei externe Tracker, Google Fonts, Analytics oder Karten-Dienste — datenschutzseitig die sauberste denkbare Konstellation, und E-Mail-Spoofing-Schutz (SPF + DMARC) ist aktiv. Zwei Punkte drücken die Note aber deutlich: (1) eine fehlende, erreichbare Datenschutzerklärung (seit revDSG Pflicht) und (2) eine sehr langsame Mobil-Ladezeit (LCP 8,1 s). Dazu ein hausgemachtes Signalproblem — die ganze Seite deklariert sich als lang="en-US", obwohl der Inhalt deutsch ist — und ein fehlendes LocalBusiness-Schema für die lokale Auffindbarkeit. Alles gut behebbar; die ersten zwei Fixes heben die Note direkt Richtung B.
Grundlage jeder SEO: Kann Google die Seite finden, crawlen und korrekt in den Index aufnehmen? Die technische Basis ist hier sauber — es liegen aber Demo- und Fremdsprachen-Reste im Index.
robots.txt gibt bis auf /wp-admin/ alles frei und verweist korrekt auf sitemap_index.xml. Der Rank-Math-Index bündelt Post-, Page- und Category-Sitemap. Der Seiten-Index wurde zuletzt am 01.04.2026 aktualisiert.
HTTP → HTTPS (301) und www → non-www (301) greifen sauber auf die kanonische Variante https://physiomurgenthal.ch/. Es gibt genau eine kanonische Host-Variante — keine Duplicate-Host-Probleme. Eine nicht existierende URL liefert einen echten HTTP 404 (kein Soft-404).
Die Startseite setzt einen selbstreferenzierenden rel="canonical" und die Robots-Meta steht korrekt auf index, follow (mit max-image-preview:large). Der Lighthouse-SEO-Score liegt bei 100/100 (Mobil und Desktop).
Die Post-Sitemap enthält typische Setup-Überbleibsel und Fremdsprachen-Dünninhalte: /hello-world/, /intro/, /gym/, /home-slider/ sowie mehrere generische englische Beiträge (top-benefits-of-physiotherapy-for-physiotherapy, stretching-techniques-… u. a.). Solche Seiten verwässern das thematische Signal einer deutschsprachigen Praxis und liefern dünnen, teils duplizierten Content.
→ Fix: Demo-/Blindtext-Seiten löschen, englische Platzhalter-Beiträge entfernen oder auf noindex setzen — die Sitemap soll nur die echten Leistungs- und Praxisseiten führen.
Maschinenlesbare Auszeichnung des Inhalts — Grundlage für Rich Results. Der lokal entscheidende LocalBusiness-Aspekt wird gesondert in Sektion 09 (Lokale Sichtbarkeit) bewertet.
Rank Math liefert einen verknüpften JSON-LD-Graph mit WebSite, WebPage, SearchAction, Person, Article, ImageObject und PostalAddress. Die technische Basis, um weitere Schema-Typen (allen voran LocalBusiness) sauber einzuhängen, ist damit gegeben.
MedicalProcedure / FAQPageDie Therapie-Seiten (Lymphdrainage, MTT, Beckenboden, Indiba-Tecartherapie u. a.) nutzen kein leistungsspezifisches Markup. FAQ- und Service-Schema würden zusätzliche SERP-Fläche (Aufklapp-Fragen) erschließen und die Seite für KI-Antworten besser zitierbar machen (siehe Sektion 12).
→ Fix: Pro Leistung MedicalProcedure bzw. Service + eine kleine FAQPage mit den 3–4 häufigsten Patientenfragen ergänzen.
Titel, Meta-Beschreibungen, Überschriftenstruktur, Sprache und Social-Signale. Hier steckt der auffälligste, aber leicht behebbare Fehler der ganzen Seite.
lang="en-US" & og:locale=en_US — deutscher Inhalt, englisch deklariertDer komplette Seiteninhalt ist deutsch („Ihre Genesungsreise beginnt genau hier", „Willkommen bei Physio Murgenthal"), das <html>-Element deklariert die Seite aber als lang="en-US", und og:locale steht auf en_US. Das ist ein echter Signalfehler: Suchmaschinen und KI-Systeme bekommen die falsche Sprache/Region gemeldet, Social-Vorschauen die falsche Zielregion — und Screenreader lesen den deutschen Text mit englischer Aussprache vor (zugleich ein Barrierefreiheits-Problem, siehe Sektion 07).
→ Fix: In den WordPress-Spracheinstellungen (bzw. per Theme/Rank Math) lang="de-CH" setzen und og:locale auf de_CH — passend zur .ch-Domain. Ein Ein-Zeilen-Fix mit großer Signalwirkung.
Genau eine H1 („Ihre Genesungsreise beginnt genau hier"), darunter eine saubere H2/H3-Hierarchie. Der Title ist mit 55 Zeichen, die Meta-Description mit 152 Zeichen im optimalen SERP-Rahmen. viewport, twitter:card, apple-touch-icon und ein og:image sind gesetzt.
Auf der Startseite tragen 14 von 18 Bildern ein leeres alt="". Bei rein dekorativen Grafiken ist das korrekt — informative Bilder (Praxis, Team, Geräte, Leistungen) sollten aber beschreibende, keyword-nahe Alt-Texte erhalten (gut für Bildersuche und Barrierefreiheit).
Ein manifest.webmanifest fehlt — reine Politur (Homescreen-Icon / „zum Startbildschirm hinzufügen"). apple-touch-icon und Favicon sind hingegen vorhanden.
Gemessen mit Google Lighthouse (PageSpeed Insights) für Mobil und Desktop. Ring-Farbe = Score-Band, darunter die Lab-Core-Web-Vitals.
Am Desktop lädt die Seite blitzschnell (LCP 1,5 s, Performance 89). Mobil bricht sie ein: Der erste sichtbare Inhalt erscheint erst nach 6,0 s (FCP), das Hauptbild nach 8,1 s (LCP), Speed-Index 7,3 s — Performance-Score nur 59. Für eine Praxis, deren Besucher:innen überwiegend vom Smartphone kommen, ist das der teuerste Punkt: Jede Sekunde Ladezeit kostet Absprünge, und Google bewertet mobile-first.
→ Fix: Hero-/Above-the-fold-Bild als LCP-Element klein & in WebP ausliefern (+ fetchpriority="high", Preload), render-blocking CSS reduzieren, Full-Page-Cache aktivieren (siehe unten). Positiv: Layout-Shift (CLS 0,025) und Blocking-Time (30 ms) sind mobil bereits sehr gut.
Die referenzierten Bilder liegen ausschließlich als .jpg, .jpeg und .png vor — kein WebP/AVIF. Gesamt-Seitengewicht laut Lighthouse: 1.562 KiB. Moderne Formate bringen hier typisch 30–70 % Byte-Ersparnis und zahlen direkt auf den mobilen LCP ein. Immerhin: srcset und feste width/height sind gesetzt (kein Layout-Shift), Lazy-Loading ist aktiv.
→ Fix: WebP/AVIF-Konvertierung per Plugin (ShortPixel, Imagify) — bestehende srcset-Struktur bleibt erhalten.
Der <head> lädt 30 einzelne Stylesheets (typisch für WordPress + Elementor). Lighthouse meldet ~169 KiB ungenutztes CSS. Ohne Bündelung/Zusammenfassung erhöht das Render-Blocking und ist ein Mit-Verursacher des schwachen Mobil-Scores.
→ Fix: CSS zusammenfassen & minifizieren, ungenutzte Elementor-/Widget-Styles pro Seite abwählen (z. B. via LiteSpeed Cache / Perfmatters „Used CSS").
Die Startseite antwortet in wiederholten Messungen erst nach ~2,0–2,3 s Gesamtladezeit; der Origin liefert keine Cache-Control-Freigabe für Wiederkehrer. Für eine überwiegend statische Praxisseite deutet das auf fehlendes Full-Page-Caching hin (Google selbst wird über einen Edge-Cache mit ~0 ms bedient — echte Nutzer:innen nicht). Zielwert TTFB: <0,6 s.
→ Fix: Full-Page-Cache aktivieren (WP Rocket / LiteSpeed Cache) und Object-Cache prüfen. HTTP/2 ist bereits aktiv.
Serverbasis und eingebundene Fremd-Ressourcen. Die Sicherheits-Header und die Versionshygiene werden gesondert in Sektion 10 (Trust & Sicherheit) bewertet.
Bemerkenswert zurückhaltend: Die Seite bindet keine externen Fonts, keine Analytics/Tag-Manager, keine Google-Maps- oder Social-Media-Einbettung ein. Extern angesprochen werden praktisch nur die Online-Terminbuchung (onlinecalendar.medidoc.ch, ein Schweizer Dienst) und Gravatar. Alle eingebundenen Skripte sind First-Party — das ist selten und sowohl für Datenschutz als auch Performance ein echter Vorteil.
HTTP/2, aktive Kompression (Startseite gzip ~27 KB), gültiges HTTPS (TLS 1.3) sowie Favicon und Apple-Touch-Icon sind sauber ausgeliefert. Vor dem Origin sitzt zudem ein Bot-Schutz (openresty-Challenge), der automatisierte Zugriffe abfängt (siehe Sektion 10).
Für die Schweiz gilt das revidierte Datenschutzgesetz (revDSG, seit 01.09.2023); wer auch EU-Kund:innen anspricht, fällt zusätzlich unter die DSGVO. Geprüft aus real ausgelieferten Seiten und eingebundenen Ressourcen.
Weder unter den üblichen Pfaden (/datenschutz, /datenschutzerklaerung → jeweils HTTP 404) noch im Footer der Startseite ist eine Datenschutzerklärung verlinkt oder auffindbar. Seit dem revDSG ist eine Datenschutzerklärung mit Angaben zu Datenbearbeitung, Zweck und Kontakt Pflicht — auch für eine Praxis, die selbst kaum Daten erhebt (allein durch Server-Logs, Terminbuchung und Kontaktformular).
→ Fix: Eine revDSG-konforme Datenschutzerklärung als eigene Seite anlegen und im Footer sitewide verlinken (Generator z. B. von einem CH-Anwalt/Datenschutz-Tool). Die gute Nachricht: Da keine Tracker eingebunden sind, bleibt der Inhalt schlank.
Die Seite lädt keine Google Fonts, kein Analytics/GA4, keinen Tag-Manager, keine Google-Maps- oder Social-Media-Embeds — und setzt keine Cookies vor einer Interaktion. Damit werden vor dem Klick praktisch keine personenbezogenen Daten an Dritte übertragen. Das ist die datenschutzfreundlichste denkbare Konstellation und erklärt, warum trotz fehlender Datenschutzerklärung kein aktiver Datenabfluss stattfindet — es ist eine formale, keine „Abfluss"-Lücke.
HTTPS ist mit gültigem Zertifikat (TLS 1.3, gültig bis 27.09.2026) durchgängig erzwungen (HTTP → HTTPS per 301). Keine Mixed-Content-Ressourcen im HTML.
Eine eigene Impressums-/Anbieter-Seite ist nicht erreichbar (/impressum → 404). In der Schweiz besteht keine allgemeine Impressumspflicht wie in Deutschland, doch das UWG (Art. 3 Abs. 1 lit. s) verlangt bei Online-Angeboten klare Anbieter- und Kontaktangaben; für eine Gesundheitspraxis schafft das zudem Vertrauen.
→ Fix: Anbieterangaben (Praxisname, verantwortliche Person, Adresse, Telefon, E-Mail) als „Impressum"/„Kontakt & Rechtliches" ergänzen und im Footer verlinken.
In der Schweiz verpflichtet das BehiG vor allem öffentliche Stellen; für private Anbieter ist Barrierefreiheit freiwillig, aber gute Praxis (und wer EU-Kund:innen bedient, berührt den European Accessibility Act). Basis: Lighthouse-Accessibility-Score und statische HTML-Analyse.
Der Lighthouse-Accessibility-Score liegt bei soliden 92/100 — der einzige durchgefallene Kern-Check ist color-contrast: einzelne Text-/Hintergrund-Kombinationen erreichen das WCAG-Verhältnis von 4,5:1 nicht. Das betrifft Leser:innen mit eingeschränktem Sehvermögen und ist schnell behebbar.
→ Fix: Betroffene Grau-/Akzenttöne im Elementor-Farbschema minimal abdunkeln, bis 4,5:1 (kleiner Text) erreicht ist — per Lighthouse-A11y-Audit gegenprüfen.
Weil <html lang="en-US"> gesetzt ist (siehe Sektion 03), lesen Screenreader den deutschen Text mit englischer Aussprache vor — für blinde/sehbeeinträchtigte Nutzer:innen praktisch unverständlich. Der Fix in Sektion 03 (lang="de-CH") behebt zugleich dieses Barrierefreiheits-Problem.
Alle Bilder tragen ein alt-Attribut, die Überschriftenhierarchie ist sauber (eine H1, logische H2/H3-Folge), der Viewport ist gesetzt und die Navigation per Tastatur erreichbar. Bis auf Kontrast und Sprachattribut ist die A11y-Grundlage tragfähig.
Die entscheidende Frage für den Praxiserfolg: Macht die Seite aus Besucher:innen Kontakt? Geprüft werden Kontaktwege, Handlungsaufforderungen und Vertrauenssignale.
Solide Basis: Die Telefonnummer ist als tel:-Link (+41 62 926 02 30) hinterlegt — auf dem Smartphone mit einem Tap wählbar — dazu ein mailto:-Link und eine eingebundene Online-Terminbuchung (medidoc). Die Google-Bewertung 4,7 ist prominent oben ausgewiesen — ein starkes Vertrauenssignal.
Im Seitenquelltext steht neben der echten Praxis-Adresse noch eine Demo-Adresse hello@domainname.com (Theme-Überbleibsel) — sie sollte raus, damit niemand versehentlich ins Leere schreibt. Zudem ist die Praxis-Mail eine Gmail-Adresse (physiomurgenthal@gmail.com) statt einer Domain-Adresse (@physiomurgenthal.ch) — das wirkt weniger professionell und schwächt das Vertrauen.
→ Fix: Platzhalter-Adresse entfernen und eine domaineigene Mailadresse (kontakt@physiomurgenthal.ch) einrichten und überall verwenden.
Auf der Startseite gibt es oben keinen sichtbaren „Termin anfragen"-Button und kein direktes Kontaktformular — der Weg zur Terminbuchung führt erst über Scrollen/Navigation. Für eine terminbasierte Praxis ist der kürzeste Conversion-Pfad bares Geld.
→ Fix: Sichtbaren „Termin buchen"-Button (zur medidoc-Buchung) und den tel:-Link fest in den oberen Bereich / Sticky-Header aufnehmen.
Für einen ortsgebundenen Betrieb der wichtigste Kanal: Local Pack, Google Maps und die lokale Suche. Entscheidend ist das LocalBusiness-Schema samt vollständiger Standortdaten.
Im JSON-LD steht zwar eine PostalAddress und eine telephone-Angabe (im Kontext von Person/Article), aber kein LocalBusiness- bzw. Physiotherapy-Typ, keine openingHours und keine geo-Koordinaten. Für die lokale Auffindbarkeit (Local Pack, Google Maps) ist das der wichtigste fehlende Baustein — das strukturelle Grundgerüst (Sektion 02) ist vorhanden, es fehlt nur der lokale Typ.
→ Fix: Physiotherapy bzw. MedicalClinic (Subtyp von LocalBusiness) mit vollständiger NAP-Angabe, Geo-Koordinaten, Öffnungszeiten und sameAs zum Google-Business-Profil ergänzen — Rank Math bietet dafür ein „Local SEO"-Modul.
Es ist keine Google-Maps-Anfahrtskarte und keine sameAs-Verknüpfung zum Google-Business-Profil eingebunden; Öffnungszeiten sind im Fließtext nicht klar als solche ausgewiesen. Für Patient:innen, die „Physiotherapie Murgenthal Öffnungszeiten/Anfahrt" suchen, fehlt damit ein direkter Anker.
→ Fix: Öffnungszeiten sichtbar auf der Kontaktseite, eine (klick-to-load) Karte einbinden und das Google-Business-Profil verlinken/pflegen. Datenschutz-Hinweis: Karte erst nach Klick laden, um die aktuell saubere Tracking-Freiheit zu erhalten.
PLZ/Ort und Telefonnummer sind im Seitentext ausgewiesen — die Inhalte für ein sauberes lokales Schema liegen bereits vor und müssen nur maschinenlesbar hinterlegt werden.
Vertrauens- und Angriffsflächen-Perspektive: Transportsicherheit, Schutz-Header, E-Mail-Sicherheit und die Frage, wie viel die Seite über ihre Software preisgibt.
Die Domain ist gegen Spoofing/Phishing im Namen der Praxis geschützt: Ein SPF-Record ist vorhanden und DMARC steht auf p=quarantine mit strikter Ausrichtung (adkim=s; aspf=s). Das ist deutlich besser als bei den meisten KMU-Seiten und ein starkes, oft übersehenes Trust-Signal.
Vor der WordPress-Installation sitzt ein Reverse-Proxy mit Bot-Challenge (openresty, „Einen Moment bitte …"), der automatisierte Zugriffe abfängt. Der direkte Abruf sensibler Pfade (/.git, /.env, Backup-Dateien) wurde geblockt bzw. lieferte kein verwertbares Ergebnis — eine sinnvolle Härtung.
Es fehlen Strict-Transport-Security (HSTS), Content-Security-Policy, X-Frame-Options, X-Content-Type-Options und Referrer-Policy. Kein Ranking-Signal, aber Best Practice, Teil des Lighthouse-„Best-Practices"-Scores (aktuell 96) und ein sichtbares Sicherheitsmerkmal.
→ Fix: Header per Server-Config setzen; HSTS erst nach geprüftem Dauer-HTTPS aktivieren.
Der generator-Meta-Tag weist Versionen offen aus (WordPress 6.9.4, Elementor 3.30.3). Das erleichtert automatisierte Angriffe auf bekannte Versionslücken — der Bot-Schutz mildert das Risiko, ersetzt aber keine Versionshygiene.
→ Fix: Generator-Versionshinweise entfernen und CMS & Plugins konsequent aktuell halten.
Für die Domain ist kein DS-Record hinterlegt — DNSSEC (Schutz vor DNS-Manipulation) ist damit inaktiv. „Nice to have", nicht kritisch; viele Schweizer Registrare bieten die Aktivierung mit einem Klick.
Google indexiert mobile-first, und die meisten Besucher:innen kommen vom Smartphone. Maßgeblich ist der mobile Lighthouse-Datensatz (siehe Gauges in Sektion 04) samt Bedienbarkeit auf kleinen Displays.
Der Kontrast ist ungewöhnlich groß: Am Desktop erscheint der erste Inhalt nach 0,6 s, mobil erst nach 6,0 s (FCP); das LCP-Hauptelement liegt bei 1,5 s (Desktop) vs. 8,1 s (Mobil). Performance-Ampel 89 vs. 59. Da Google mobile-first bewertet und die meisten Praxis-Besucher:innen vom Smartphone kommen, ist das der wichtigste Handlungspunkt der ganzen Seite.
→ Fix: Deckungsgleich mit Sektion 04 — LCP-Bild klein & in WebP priorisiert ausliefern, CSS entschlacken (169 KiB ungenutzt), Full-Page-Cache aktivieren. Diese Maßnahmen zielen direkt auf den Mobil-Score.
Der viewport ist korrekt gesetzt, kein horizontales Scrollen, Inhalte skalieren. Der mobile Layout-Shift (CLS 0,025) und die Blocking-Time (30 ms) sind sehr gut — die Seite „springt" beim Laden nicht. Das eigentliche Problem ist ausschließlich die Ladegeschwindigkeit, nicht die Bedienbarkeit.
Immer mehr Menschen suchen über ChatGPT, Perplexity und Google-AI-Overviews. Generative Engine Optimization (GEO) prüft, wie gut die Seite von KI-Systemen gelesen, verstanden und zitiert werden kann — ein Zukunfts- und Chancenthema.
Mehrere Signale erschweren KI-Systemen das Lesen & Zitieren: Von den semantischen Landmarks ist nur <nav> vorhanden — kein <main>, <article>, <header> oder <footer> (Elementor rendert reine div-Strukturen). Es gibt nur einen JSON-LD-Block, kein FAQPage-Schema, keine llms.txt und ein niedriges Text-/HTML-Verhältnis (0,12). Zusätzlich meldet das falsche lang="en-US" die falsche Sprache.
→ Fix: Kernfragen als H2/H3 + knappe Antwortabsätze, FAQPage-Schema auf Leistungsseiten, semantische Landmarks aktivieren und (optional) eine llms.txt mit Kurzprofil und wichtigsten Seiten anlegen.
Die robots.txt blockiert keine KI-Crawler (GPTBot, PerplexityBot, Google-Extended u. a.) — die Seite darf grundsätzlich in generativen Antworten auftauchen. Gute Ausgangslage, um GEO gezielt auszubauen.
| Prüfpunkt | Status | Befund |
|---|---|---|
| HTTPS & Redirects | OK | 301 http→https, www→non-www |
| robots.txt | OK | Freigegeben, Sitemap verlinkt |
| XML-Sitemap | OK | Rank-Math-Index, page/post/category |
| Canonical & 404 | OK | Selbstreferenzierend, echter 404 |
| Demo-/EN-Inhalte im Index | Handlung | hello-world, gym, englische Posts |
| Title / Meta-Description | OK | 55 / 152 Zeichen, SEO-Score 100 |
| Sprachauszeichnung (lang/og:locale) | Kritisch | en-US bei deutschem Inhalt |
| Alt-Texte | Handlung | 14/18 leer auf Startseite |
| Mobile-Performance (LCP) | Kritisch | LCP mobil 8,1 s / FCP 6,0 s |
| Bildformate WebP/AVIF | Handlung | Nur JPG/PNG, 1.562 KiB |
| Browser-Caching / TTFB | Handlung | ~2 s, kein Full-Page-Cache |
| CSS-Menge / ungenutztes CSS | Handlung | 30 CSS, ~169 KiB ungenutzt |
| HTTP/2 & Kompression | OK | HTTP/2, gzip aktiv |
| Datenschutzerklärung | Fehlt | Nicht erreichbar (404, revDSG) |
| Tracking / Cookies vor Consent | OK | Keine Tracker, keine Cookies |
| Impressum / Anbieterangaben | Handlung | Keine eigene Seite (404) |
| Barrierefreiheit | Handlung | A11y 92, color-contrast fehlt |
| LocalBusiness-Schema | Fehlt | Kein Physiotherapy-/LocalBusiness-Typ |
| Karte / Google-Business | Handlung | Kein Maps-Embed, kein sameAs |
| Conversion (Kontaktwege) | OK | tel:, Buchung, Google 4,7 |
| Platzhalter-/Gmail-Adresse | Handlung | hello@domainname.com, Gmail |
| E-Mail-Sicherheit (SPF/DMARC) | OK | SPF + DMARC p=quarantine |
| Security-Header | Handlung | HSTS/CSP/X-Frame fehlen |
| Version offen / DNSSEC | Handlung | WP/Elementor sichtbar, kein DS |
| Bot-Schutz / Endpoints | OK | openresty-Challenge, .git/.env geschützt |
| Mobile-UX (Layout) | OK | Viewport ok, CLS 0,025 |
| KI-Sichtbarkeit (GEO) | Chance | Landmarks/FAQ-Schema ausbaubar |
Nach Wirkung × Aufwand über alle Säulen geordnet — die ersten drei Punkte bringen den größten Hebel bei geringem bis mittlerem Aufwand; der rechtliche Punkt zuerst.
revDSG-konforme Datenschutzerklärung als eigene Seite, sitewide im Footer verlinkt — schließt die einzige echte rechtliche Lücke. Da keine Tracker eingebunden sind, bleibt sie schlank.
lang="de-CH"<html lang> und og:locale auf Deutsch/Schweiz umstellen. Ein-Zeilen-Fix, der SEO-Signal, Social-Vorschau und Screenreader-Ausgabe gleichzeitig repariert.
LCP-Bild klein & in WebP priorisiert ausliefern, ungenutztes CSS (169 KiB) entschlacken, Full-Page-Cache aktivieren. Der größte spürbare Gewinn für echte (mobile) Besucher:innen.
NAP, Geo, Öffnungszeiten, sameAs zum Google-Business-Profil (Rank Math Local SEO). Direkter Hebel auf lokale Sichtbarkeit und Rich Results.
Platzhalter-Adresse hello@domainname.com entfernen, domaineigene E-Mail einrichten, „Termin buchen"-CTA above the fold platzieren.
Demo-/englische Beiträge löschen oder noindex, Farbkontraste auf 4,5:1 anheben, informative Alt-Texte ergänzen.
Security-Header setzen, Generator-Version verbergen, DNSSEC aktivieren, FAQ-/Service-Schema und semantische Landmarks für KI-Sichtbarkeit, optional llms.txt.
Brand & Webdesign für Gesundheit, Coaching & Speaking