Vor dem Senden ausfüllen
[site address][business name][phone][address][service area][most important service page][Search Console property]
Meine WordPress-Website [site address] ist mit Elementor gebaut. Ich möchte, dass meine wichtigsten Seiten auf Smartphones einwandfrei funktionieren und für Suchmaschinen und KI-Assistenten lesbar sind. Seiten: [bis zu 10 Adressen der wichtigsten Seiten; falls leer: Startseite, Leistungsseiten und Kontakt]. Unternehmensangaben: [business name], [phone], [address], [service area]; erfinde nichts, was du nicht weißt.
1. Setup auslesen. Hole Theme und Versionen mit wordpress_site_info, und finde mit wordpress_list_plugins das SEO-Plugin (Yoast, Rank Math usw.), das Cache-Plugin, Elementor und ob WPCode installiert ist. Liste die veröffentlichten Seiten und ihre IDs mit wordpress_list_posts auf.
2. Messen, nichts ändern:
1. Für jede Seite Mobile-Performance, LCP und CLS mit core_web_vitals.
2. Für die Startseite und [most important service page] Accessibility- und SEO-Fehler mit seo_audit, besonders Fehler bei Tap-Zielen, Kontrast, Viewport und Überschriftenreihenfolge. Das verbraucht Credits; sag mir, wie viele Aufrufe es werden.
3. Für jede Seite site_read_url mit outline=true: Anzahl der h1 und der Überschriftenbaum von h1 bis h6. Mit text=true beim selben Tool: Text, Telefonnummer und Adresse, die ohne JavaScript sichtbar sind.
4. Für jede Seite Meta-Titel, Beschreibung, Canonical und noindex mit wordpress_seo.
5. robots.txt und llms.txt mit site_read_url lesen; die Option `blog_public` mit wordpress_option und write=false lesen (0 bedeutet, dass die Website für Suchmaschinen versteckt ist).
6. Mobiles Überlaufen lässt sich mit diesen Tools nicht pixelgenau messen. Nutze die Viewport- und Tap-Ziel-Befunde aus seo_audit und gib mir eine kurze Liste von Seiten, die ich auf dem Smartphone bei 360 Pixel Breite prüfen soll.
Zeig die Befunde in einer Tabelle pro Seite.
3. Mobiles Überlaufen und Tap-Ziele. Hole bei einer Problemseite die Elementliste mit wordpress_page_design, öffne das verdächtige Element mit dem Parameter element und suche nach fester Breite, großer Schriftgröße, negativem Margin oder Spalten, die nebeneinander bleiben. Nimm die Korrektur mit wordpress_edit_page_design nur in der mobilen Einstellung vor: Rate keine Schlüsselnamen, sondern nutze das `_mobile`-Gegenstück des Schlüssels, den du in den Einstellungen des Elements siehst (zum Beispiel typography_font_size_mobile). Ändere pro Seite immer nur ein Element; wenn etwas kaputtgeht, mit restore=true zurückrollen.
4. Überschriftenhierarchie. Jede Seite hat genau eine h1 und keine übersprungenen Überschriftenebenen. Ändere bei einem Elementor-Überschriftenelement die Ebene über das Feld `header_size` mit wordpress_edit_page_design. Stammt die Überschrift aus einer Theme-Template-Datei, nutze zuerst wordpress_theme_file mit action="list" und "get", zeige eine Vorschau mit mode="replace" und confirm=false und wende die Änderung nach meiner Freigabe mit confirm=true an.
5. Meta und Schema. Schreibe fehlende oder doppelte Titel und Beschreibungen mit wordpress_set_seo: Titel mit 50 bis 60 Zeichen, Beschreibungen mit 140 bis 160, auf jeder Seite einzigartig. Lies das JSON-LD im rohen HTML der Seite mit site_read_url; wenn der Geschäftstyp im Graph des SEO-Plugins falsch ist oder fehlt, versuche das zuerst über die Plugin-Einstellungen zu lösen. Für einen LocalBusiness-Untertyp, den das Plugin nicht ausgeben kann, oder ein FAQPage für Fragen, die tatsächlich auf der Seite stehen, bereite mit wordpress_snippet ein kleines PHP-Snippet vor, das an `wp_head` hängt; Snippets werden inaktiv angelegt, zeig mir also den Code und schalte es nach meiner Freigabe mit toggle ein. Erfinde niemals Öffnungszeiten, Koordinaten, Bewertungen, Preise oder Rezensionen.
6. Speed. Lies die aktuellen Einstellungen und die als riskant markierten Schalter mit wordpress_performance. Schlage mit wordpress_set_performance nur die sicheren vor: page_cache, browser_cache, minify_css, minify_js, lazy_load. Aktiviere auf einer Elementor-Website weder combine noch defer oder css_async; falls nötig, nur einzeln, mit confirm_risky, und sieh dir die Seite nach jedem Schritt an. Hole für das Hauptbild im ersten Bildschirmbereich die tatsächlichen Größen und das srcset mit wordpress_media und media_id und prüfe, dass es nicht lazy geladen und in der passenden Größe ausgeliefert wird. Rufe nach jeder Änderung wordpress_purge_cache auf.
7. KI-Crawler und robots.txt. robots.txt darf GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot oder CCBot nicht blockieren und muss auf die Sitemap verweisen. Gibt es keine physische robots.txt-Datei, erzeugt WordPress sie selbst; schlage die fehlenden Regeln als PHP-Snippet vor, das mit wordpress_snippet an den Filter `robots_txt` gehängt wird. Gibt es eine physische Datei oder verwaltet das SEO-Plugin die robots.txt, sag mir, dass die Änderung dort vorgenommen werden muss. Blockiert ein Sicherheits- oder CDN-Plugin diese Crawler, melde es und sag klar, dass du das mit den Tools nicht überprüfen kannst.
8. llms.txt. Falls keine vorhanden ist, bereite einen llms.txt-Text mit einer präzisen Zusammenfassung der Website in zwei bis drei Sätzen, der Liste der wichtigsten Seiten und den Kontaktdaten vor und zeig ihn mir. Installiere nach meiner Freigabe mit wordpress_snippet ein PHP-Snippet, das `/llms.txt` als `text/plain; charset=utf-8` ausliefert, rufe wordpress_purge_cache auf und bestätige mit site_read_url, dass 200 zurückkommt.
9. Menü. Prüfe mit wordpress_menus, ob Hauptmenü und Footer-Menü auf alle wichtigen Seiten verlinken. Fehlt ein Link, zeig mir deinen Vorschlag für wordpress_edit_menu.
10. Erneut messen. Wiederhole die Messungen aus Schritt 2 auf denselben Seiten, bei seo_audit mit runs=2. Wenn meine Search-Console-Property [Search Console property] ist, prüfe die geänderten Seiten mit gsc_inspect_urls.
Regeln: Zeig vor jedem Schreibvorgang das Feld, das sich ändert, den aktuellen und den neuen Wert und warte auf meine Freigabe. In Elementor immer nur ein Element auf einmal ändern. Ergebnis: eine Vorher-Nachher-Tabelle pro Seite (Mobile-Performance, LCP, CLS, Anzahl h1, Überschriftenreihenfolge, Länge von Meta-Titel und -Beschreibung, Schema-Typen), der Zustand von robots.txt und llms.txt, die Liste der vorgenommenen Änderungen und die Seiten, die ich von Hand prüfen muss.