Website-SEO mit Codex automatisieren: Leitfaden fuer Einsteiger

Du musst nicht wissen, was ein Canonical-Tag macht, bevor du Codex nutzt, um eine Seite zu verbessern. Du brauchst eine wichtige URL, Zugriff auf das Projekt deiner Website, wenn eine Aenderung ansteht, und eine klare Regel: Codex prueft zuerst; du gibst Aenderungen danach frei.

Dieser Leitfaden zeigt Einsteigern eine sichere Methode, wiederkehrende SEO-Arbeit mit Codex und der Skill seo-auto-optimizer zu automatisieren. Du nutzt Codex, um eine Seite zu untersuchen, Befunde in klarer Sprache zu erklaeren, freigegebene Aktualisierungen in den Dateien deiner Website vorzubereiten und das Ergebnis vor der Veroeffentlichung zu testen.

Codex ist besonders nuetzlich, wenn deine Website in einem Git-Repository liegt. Es kann eine Seite untersuchen, die Vorlage oder Inhaltsdatei dahinter finden, eine kleine freigegebene Aenderung vornehmen und dir im Git-Diff genau zeigen, was sich veraendert hat. Das ist deutlich sicherer, als Code in einen Live-Editor einzufuegen und auf das Beste zu hoffen.

Dieses Tutorial beginnt beim Repository. Die SEO-Skill uebernimmt die Seitenpruefung. Codex arbeitet im selben Repository wie deine Website, befolgt vorhandene Hinweise in AGENTS.md und hinterlaesst einen pruefbaren Diff. Du solltest es nie bitten muessen, den Code "irgendwo auf meinem Computer" zu suchen.

SEO zu automatisieren bedeutet nicht, einem Agenten deine gesamte Website zu geben und ihn aufzufordern, "alles zu reparieren". Es bedeutet, die langsamen und wiederholbaren Teile an ihn zu uebergeben, waehrend du bei Entscheidungen die Kontrolle behaeltst, die Seiten aus der Suche entfernen oder Besucher verwirren koennten.

Was du am Ende in der Hand hast

Nach diesem ersten Ablauf hast du:

• eine wichtige URL auf sichtbare SEO-Probleme geprueft;
• eine kurze, priorisierte Liste von Aenderungen, bei denen Codex helfen kann;
• eine verstaendliche Erklaerung zu jeder Empfehlung;
• ein geprueftes Aenderungspaket im lokalen Website-Projekt, falls du es umsetzen moechtest; und
• eine Checkliste fuer Tests vor dem Deployment.

Plane fuer den ersten Durchlauf 30 bis 60 Minuten ein. Waehle eine Seite, die fuer dein Geschaeft wichtig ist: die Startseite, eine Produkt- oder Leistungsseite oder einen Beitrag, der bereits Traffic erhaelt. Beginne nicht mit der ganzen Website.

"Fertig" bedeutet hier: Du kannst auf die Seite zeigen, erklaeren, was und warum geaendert wurde, und bestaetigen, dass die Seite nach dem Update noch funktioniert. Es bedeutet keine garantierte Verbesserung im Ranking. Suchmaschinen brauchen Zeit, um eine Seite erneut zu crawlen und zu bewerten.

Bevor du beginnst: vier Dinge, die bereitliegen sollten

Du kannst ohne Google Search Console und ohne technischen Hintergrund anfangen. Die erste Pruefung verwendet oeffentlich sichtbare Seitensignale. Halte diese Dinge bereit:

Google Search Console, Bing Webmaster Tools und ein Crawler-Export sind spaeter hilfreich. Sie beantworten Fragen, die eine einzelne Seite nicht klaeren kann: etwa ob eine URL Klicks verliert, mit einer anderen URL konkurriert oder im grossen Umfang von der Indexierung ausgeschlossen wird.

Erstelle die Skill SEO Auto Optimizer in deinem Codex-Arbeitsbereich

Die Skill-Datei musst du selbst erstellen. Du musst aus diesem Artikel nichts herunterladen.

Die schnellste Option: sende diesen Artikel an Codex

Sobald dieser Artikel veroeffentlicht ist, kannst du Codex seine URL geben und ihn bitten, die Skill einzurichten. Kopiere diesen Prompt, ersetze [ARTIKEL-URL] durch die Live-URL dieses Artikels und sende ihn an Codex:

Lies diesen Artikel und installiere die Skill seo-auto-optimizer genau wie dort beschrieben:
[ARTIKEL-URL]

Ich bin Einsteiger. Finde im Artikel den vollstaendigen SKILL.md-Codeblock. Pruefe zuerst die Codex-Konfiguration oder Hinweise dieses Repositorys, um das konfigurierte Skills-Verzeichnis des Projekts zu bestimmen. Erstelle dann dort die erforderliche Datei seo-auto-optimizer/SKILL.md und kopiere den Block exakt hinein.

Bevor du die Datei erstellst, nenne mir den vollstaendigen Pfad, den du verwenden wirst. Zeige mir nach dem Erstellen die ersten 10 Zeilen und bestaetige, dass die Skill seo-auto-optimizer heisst.

Untersuche meine Website nicht, bearbeite keine Website-Dateien, aendere keine Einstellungen, fuehre kein Deployment aus und starte noch kein SEO-Audit. Installiere und pruefe nur diese Skill.

Wenn Codex die Artikel-URL nicht oeffnen kann, nutze die manuelle Methode. Bei Bedarf kannst du den vollstaendigen Codeblock unten in den Chat einfuegen. Lege eine projektspezifische Skill nicht in einem beliebigen globalen Ordner ab: Nutze den im Repository konfigurierten Ort oder bitte Codex, zuerst die verfuegbaren Skills-Orte zu zeigen.

Erstelle im Stammordner des Codex-Arbeitsbereichs, den du fuer SEO verwendest, diese Ordner und Datei:

dein-codex-arbeitsbereich/
skills/
seo-auto-optimizer/
SKILL.md

Codex kann Skills aus einem persoenlichen oder projektspezifisch konfigurierten Verzeichnis laden. Bitte Codex zuerst, die AGENTS.md-Datei und die .codex-Konfiguration des Repositorys zu pruefen. Nutze exakt den Skills-Ort, den es meldet. Sowohl der Ordnername als auch der Wert name in der Datei muessen seo-auto-optimizer sein, damit Codex sie mit $seo-auto-optimizer aufrufen kann.

Oeffne eine neue Klartextdatei mit dem Namen SKILL.md und fuege den vollstaendigen Inhalt unten ein. Fuege ihn nicht in den Code deiner Website ein: Er gehoert in den Ordner skills/seo-auto-optimizer/.

---
name: seo-auto-optimizer
description: Audit one public URL or a group of website URLs with evidence, then create an SEO optimization plan ranked by impact and effort. Use when a user asks to check, diagnose, optimize, or create an SEO task list, especially for indexing, technical SEO, metadata, structured data, content quality, internal links, search intent, keyword cannibalization, Core Web Vitals, mobile experience, CTR, Google Search Console, Bing Webmaster Tools, sitemaps, robots.txt, or E-E-A-T. By default, audit and provide code or copy recommendations only. Do not change the website, CMS, search-engine consoles, or third-party platforms.
---

# SEO Auto Optimizer

Turn a supplied URL into a verifiable SEO optimization plan that a developer, content team, or growth team can act on. Never present an item as checked or fixed when public evidence cannot confirm it.

## Working boundaries

- Default to read-only work. Inspect public pages, resources, and public site files. Do not change live pages, submit a sitemap, publish content, buy links, or operate any account.
- For a single-URL request, audit that URL and only the same-domain public files needed to verify it, such as `robots.txt`, a sitemap, or page links. Do not turn a single-page observation into a site-wide conclusion.
- Mark work that needs a login, search-performance data, a full crawl, server logs, or business facts as `Needs data`. State what data is needed and how to check it.
- Do not recommend black-hat, manipulative, or fabricated SEO: no purchased links, fake reviews/authors/comments, doorway pages, keyword stuffing, or bulk low-value AI pages.
- Follow the site's market, page language, URL conventions, and content standards. Proposed titles, meta descriptions, H1s, and body copy must use the target page's language.

## Inputs and clarification

A request needs at least one URL. If available, use the target market, language, business model, primary conversion, target keywords, Google Search Console or Bing exports, and local website project.

When those details are missing, do not block the work. Infer what you can from the page language, page type, and visible content, then state your assumptions at the beginning of the report. Ask one focused question only when the user requests keyword strategy, competitive content, or a site-wide change and the answer would materially depend on the target market or business.

## Audit process

### 1. Build an evidence baseline

1. Record the inspection date, final URL, HTTP status, redirect chain, `<html lang>`, visible robots instructions, and page-rendering limits.
2. Read the first screen, main content, and available source or DOM. Record the title, meta description, canonical, robots meta, viewport, H1-H6, visible publish or update date, author information, approximate body length, images, internal and external links, JSON-LD, and important JavaScript dependencies.
3. Check the same-domain `/robots.txt`. Check a sitemap only when one is discoverable; do not say a sitemap does not exist merely because its URL is not explicitly listed.
4. Keep locatable evidence for every conclusion: tag text, HTTP header, link URL, DOM observation, screenshot observation, or public-tool result. If the page is blocked by a WAF, login, geography, or another access limit, state the limitation immediately.

### 2. Classify every check

Use exactly one status for each item:

| Status | Meaning |
| --- | --- |
| `Pass` | Public evidence shows the item meets its purpose. |
| `Issue` | Public evidence shows an error, risk, or clear omission. |
| `Opportunity` | It may not be an error, but there is a reasonable opportunity to improve visibility, click-through rate, user experience, or conversion. |
| `Needs data` | Google Search Console, Bing, logs, a full crawl, field performance data, or keyword data is required. |
| `Not applicable` | The page type or business does not need this item; explain why. |

Do not turn `Needs data` into an `Issue` just to fill a checklist. Resolve the root causes that affect crawling, indexing, user experience, or the page's main intent before minor copy changes.

### 3. Create an action plan

Merge findings into non-duplicative tasks and rank them:

- `P0`: The page cannot be crawled or indexed; an incorrect canonical; accidental `noindex`; critical 4xx/5xx; site-wide robots blocking; severe mobile or rendering failure.
- `P1`: Main-page intent or content mismatch; duplicate or thin content; missing or conflicting title and H1; unacceptable structured data; missing key internal links; obvious performance bottleneck.
- `P2`: CTR improvements; images and alt text; FAQs; author and update information; content expansion; topic or comparison pages; local link and URL improvements.
- `P3`: Growth experiments, link earning, business profiles, and monitoring that require performance data or external coordination.

For every task, state the problem, evidence, recommended action, owner (developer, content, SEO, or growth), acceptance criteria, and risk or prerequisite. Give specific code or copy only when current information supports it. Where brand facts are missing, use clear placeholders instead of inventing facts.

## What to check

### A. Crawling, indexing, and URLs

Check and report:

- HTTP status, whether redirects are single-hop and appropriate, loops, and HTTP/HTTPS or www/non-www confusion.
- `robots.txt`, meta robots, `X-Robots-Tag`, and whether canonical URLs are reachable, absolute, single, self-referencing, or point to a sensible preferred URL.
- Whether canonical, `noindex`, pagination or filtering rules, and sitemap behavior agree. Mark uncertain cases as `Needs data`.
- Whether URLs are stable, readable, descriptive, free of meaningless parameters, case or trailing-slash duplication, and keyword stuffing. Do not recommend casual URL changes unless the plan includes 301 redirects, internal-link updates, canonical updates, sitemap updates, and rollback conditions.
- Whether main content appears in initial HTML or can render reliably. When important content depends only on client-side JavaScript, recommend verification with URL Inspection, rendering tests, and server-side rendering or prerendering options.
- Discoverable broken links, 404s, soft 404s, and incorrect internal destinations. A single URL cannot prove that a whole site has no broken links.

### B. Page structure and metadata

Check:

- A unique, accurate, intent-matched title. For Latin-script languages, a rough 50-60 characters can be useful, but accuracy matters more than reaching a count.
- A unique meta description that describes the page's real value without keyword lists or false promises. A meta description is not a ranking guarantee; prioritize relevance and likely click-through appeal.
- One H1 that describes the page's main question. Organize H2 and H3 headings by real topic hierarchy, without skipped levels or decorative text disguised as headings.
- `lang`, viewport, mobile usability, the ratio of main content to template noise, and breadcrumb visibility and semantics.
- Appropriate image formats, dimensions, lazy loading, and specific alt text. Decorative images should have empty alt text. Do not force keywords into alt text.

When recommending a rewrite, provide one adoptable title, meta description, H1, and heading outline. Label any information that needs a brand-owner confirmation.

### C. Structured data and trust signals

Check whether visible page content and JSON-LD, Microdata, or RDFa agree. Consider only schema appropriate to the page type: `BreadcrumbList`, `Article` or `BlogPosting`, `Product`, `SoftwareApplication`, `Organization`, `LocalBusiness`, `FAQPage`, and `WebPage`.

- Recommend schema only when it represents visible, real page information. Never add invented ratings, reviews, prices, authors, FAQs, or awards.
- Identify required fields such as URL, name, description, image, author, publish date, `dateModified`, breadcrumb positions, and entity identifiers.
- For content pages, check visible author information, author page or experience, editorial policy, sources, contact information, organization information, update date, and factual citations. E-E-A-T is not a tag that can be added; it comes from verifiable content and entity information.
- When schema exists, recommend the Google Rich Results Test and Schema Markup Validator as acceptance checks.

### D. Content, intent, and duplication

Identify the page's main query intent: informational, commercial research, transactional, local, navigational, or mixed. Check whether the main content answers the question early and adds value through original evidence, examples, steps, data, or product detail.

- Flag clear thin content, template repetition, unanswered core questions, intent mismatch, and stale content. Do not define thin content by word count alone.
- A single URL cannot prove site-wide duplicate content, keyword cannibalization, or orphan pages. Explain that these require a URL inventory, canonical and index status, GSC query-to-page data, an internal-link graph, and similarity analysis.
- For overlapping pages, first define the evidence and decision criteria for keep, merge, split, or redirect. Never recommend deleting a page based on a guess.
- When content creation is requested, provide a search-intent brief, unique value, information architecture, sources needed for claims, and internal-link targets. Original content means independent insight or verification, not a competitor rewrite.
- Suggest comparison, alternatives, list, or FAQ pages only when they have distinct intent, real comparison criteria, and maintainable facts. Do not create batches of low-value templates.

### E. Internal links, architecture, and topic coverage

Assess how the page can be found and understood:

- Check whether important pages have crawlable HTML links from relevant parent pages, topic hubs, navigation, or breadcrumbs. Anchor text should naturally describe the destination.
- Mark orphan pages as `Needs data` unless a sitemap and full link graph prove the finding.
- For a topic cluster, define one pillar or owner URL, a distinct intent for each support page, link direction, and a cannibalization rule. Multiple near-identical owner pages should not compete for one head topic.
- Before suggesting feature, use-case, integration, comparison, alternatives, or FAQ pages, define the user question, target query, unique content, owner URL, and link-back path.

### F. Performance, mobile use, and Core Web Vitals

Separate lab data from field data. Prefer real-user data from CrUX or PageSpeed Insights to validate LCP, INP, and CLS. Without it, inspect obvious risks: oversized hero media, images without dimensions, render-blocking CSS or JavaScript, third-party scripts, font loading, layout shifts, and heavy client-side rendering.

Every performance recommendation must explain its mechanism and test method. For example: responsive, compressed hero media may improve LCP; image width and height reduce CLS risk; splitting long tasks may improve INP. Do not promise a score or ranking improvement.

### G. Search performance, keywords, and external authority

Unless the user supplies data or access, mark these items as `Needs data`:

- Page-two rankings, traffic or ranking declines, and query-to-page keyword cannibalization.
- URLs or queries with high impressions and low CTR, plus title and meta tests.
- High-volume, low-difficulty keywords, SERP and People Also Ask opportunities, competitor gaps, and search intent.
- High-quality backlinks, broken-link opportunities, brand mentions, Google Business Profile, and local citations.
- GSC or Bing sitemap submission, URL Inspection, index coverage, and crawl errors.

Give an executable data-checking instruction. For example: in GSC, compare the last 28 days with the previous 28 days, filter to the target URL, export queries, impressions, clicks, CTR, and average position, then test a new title or meta description for high-impression, same-intent queries with weak CTR. Link strategies must use audience-relevant, editorially independent, verifiable channels and genuinely useful assets.

## Default deliverable format

Unless the user asks for a shorter response, return these sections in this order:

1. `Scope and limits`: target URL, check date, accessibility, what could not be verified, and key assumptions.
2. `Executive summary`: the three to seven most important findings and what to address first.
3. `Check matrix`: status, evidence, and short conclusion for items A-G. Cover the user's supplied checklist, and state `Needs data` where necessary.
4. `Prioritized action list`: P0-P3 tasks with owner, effort (S/M/L), acceptance criteria, and dependencies.
5. `Implementation-ready recommendations`: where appropriate, include metadata, heading structure, JSON-LD templates, internal-link locations, content briefs, or performance fixes.
6. `Data and human follow-up`: needed GSC, Bing, crawl, log, keyword, and business inputs, plus exact validation steps.

Use careful language. Say a change may improve relevance, discoverability, or CTR. Do not promise indexing, first place rankings, or that every SEO issue has been fixed.

## Completion standard

Before delivering the work, confirm:

- Every conclusion has public evidence or is explicitly labeled as an assumption or `Needs data`.
- Tasks are ordered by impact, dependency, and actual executability, not copied mechanically from a checklist.
- Recommendations do not risk breaking URLs, canonicals, index status, or content facts. Migration, deletion, and merge suggestions include redirect and rollback conditions.
- Schema and E-E-A-T recommendations come from visible facts or are clearly marked as information still needed.
- The report makes clear that no live changes, submissions, or publishing actions were performed.

Speichere die Datei. Starte oder lade Codex anschliessend neu, falls deine Einrichtung das verlangt, und frage: Liste die in diesem Arbeitsbereich verfuegbaren Skills auf. Ist seo-auto-optimizer verfuegbar? Fahre mit dem Tutorial erst fort, wenn Codex die Verfuegbarkeit der Skill bestaetigt.

Gib Codex vor der ersten Bearbeitung eine Repository-Regel

In Codex ist AGENTS.md der richtige Ort fuer dauerhafte Repository-Regeln: wie die Website gestartet wird, wo SEO-Dateien liegen, welche Checks erforderlich sind und welche Bereiche eine Freigabe brauchen. Falls dein Repository bereits eine AGENTS.md hat, bitte Codex, sie zu lesen. Ueberschreibe sie nicht mit einer allgemeinen Vorlage.

Falls das Repository keine Hinweisdatei hat, erstelle vor der ersten Umsetzung im Repository-Stammordner eine kleine AGENTS.md mit diesem Inhalt:

# Regeln fuer SEO-Automatisierung

- Lies die vorhandene Website-Struktur, bevor du Dateien bearbeitest.
- Nutze die Skill seo-auto-optimizer fuer Seitenpruefungen und beleggestuetzte Empfehlungen.
- Nenne vor jeder Aenderung alle Dateien, die du aendern wirst, und warte auf Freigabe.
- Aendere URLs, Weiterleitungen, robots.txt, noindex, Canonical-Tags, Sitemap-Dateien oder Deployment-Einstellungen nur, wenn der Nutzer genau diese Aenderung ausdruecklich freigibt.
- Nimm fuer eine freigegebene Aufgabe die kleinstmoegliche Aenderung vor.
- Zeige nach der Bearbeitung den Git-Diff und fuehre die relevanten Repository-Checks aus, falls sie verfuegbar sind.
- Fuehre ohne ausdrueckliche Aufforderung kein Deployment, keinen Commit und keinen Push aus.

Das ist keine SEO-Konfigurationsdatei. Es ist eine dauerhafte Anweisung fuer Codex in diesem Repository. Ihr Nutzen ist einfach: Die Regeln gelten auch naechste Woche noch, wenn du den genauen Prompt von heute nicht mehr erinnerst.

Pruefe eine Seite, bevor du Codex um Aenderungen bittest

Oeffne Codex und fuege diesen Prompt ein. Ersetze die Beispiel-URL durch die URL deiner Seite.

Nutze $seo-auto-optimizer, um diese Seite zu untersuchen:
https://example.com/deine-seite

Ich bin neu im SEO. Erklaere jeden Befund in einfacher Sprache.
Aendere keine Dateien, veroeffentliche keine Seiten, reiche nichts ein und nimm keine Aenderungen an der Live-Website vor.

Zeige zu jeder Empfehlung:
1. Was Codex gefunden hat und wo es gefunden wurde.
2. Warum es fuer Besucher oder Suchmaschinen relevant sein kann.
3. Ob es ein bestaetigtes Problem, eine Verbesserungsmoeglichkeit oder ein Fall fuer weitere Daten ist.
4. Den sichersten naechsten Schritt.
5. Ob ich einen Entwickler oder Daten aus der Google Search Console brauche.

Ordne die Arbeit nach Prioritaet: P0, P1, P2 und dann P3.

Das erste Ergebnis sollte ein Bericht sein, keine veraenderte Website. Genau das ist richtig.

Codex kann normalerweise sichtbare Signale pruefen: Seitentitel, Meta-Beschreibung, Hauptueberschrift, Bild-Alt-Texte, interne Links, Canonical-Tag, Robots-Anweisungen, strukturierte Daten, mobilen Viewport und offensichtliche defekte Links. Auch klare inhaltliche Luecken auf Seitenebene kann es erkennen.

Es sollte nicht behaupten, alles zu wissen. Ein Bericht mit dem Hinweis "Needs data" ist oft vertrauenswuerdiger als einer, der aus einer einzigen URL mit grosser Sicherheit die gesamte Website diagnostiziert.

Lies den Bericht, ohne SEO-Experte werden zu muessen

Die Skill verwendet zwei einfache Kennzeichnungen: Status und Prioritaet. Lies beide, bevor du etwas freigibst.

Die Prioritaet zeigt dir, was du zuerst ansehen solltest:

Gib nicht jeden Punkt frei, nur weil er im Bericht steht. Deine erste Umsetzung sollte ein bis drei risikoarme Aenderungen enthalten. Ein kleiner erster Release ist leichter zu pruefen und leichter rueckgaengig zu machen.

Waehle sichere erste Aenderungen und verschiebe riskante Entscheidungen

Die meisten Einsteiger koennen mit klaren Verbesserungen auf einer einzelnen Seite beginnen. Diese Tabelle setzt eine sinnvolle Grenze:

Ein Canonical-Tag ist zum Beispiel eine kleine Anweisung an Suchmaschinen, welche Version aehnlicher Seiten als Hauptversion gelten soll. Eine Aenderung kann wichtig sein, kann Google aber auch versehentlich sagen, die relevante Seite zu ignorieren. Bitte Codex, die aktuelle und die vorgeschlagene Canonical-URL zu zeigen, und hole vor der Aenderung eine technische Pruefung ein.

Dasselbe gilt fuer robots.txt und noindex. Diese Einstellungen koennen auf einer Danke-Seite, einer privaten Vorschau oder gefilterten Ergebnissen richtig sein. Sie sind nicht automatisch Fehler.

Bitte um einen Umsetzungsplan, nicht um eine Ueberraschungs-Aenderung

Kopiere die freigegebenen Punkte aus deinem Bericht und nutze diesen Prompt im Website-Projekt. Er sagt Codex, was es aendern darf - und ebenso wichtig, was es unangetastet lassen muss.

Ich gebe nur diese SEO-Aenderungen frei:
[FUEGE DIE FREIGEGEBENEN PUNKTE EIN]

Pruefe mein lokales Website-Projekt und erstelle einen Umsetzungsplan.
Zeige vor jeder Dateiaenderung:
1. Alle Dateien, die du voraussichtlich aendern wirst.
2. Die genaue Seite oder Komponente, die jede Datei betrifft.
3. Was Besucher und Suchmaschinen anders sehen werden.
4. Wie wir das Ergebnis testen.
5. Einen Weg zum Rueckgaengigmachen, falls die Aenderung falsch ist.

Aendere keine URLs, loesche keine Seiten, bearbeite nicht robots.txt, fuege keine noindex-Tags ein,
aendere keine Weiterleitungen, veroeffentliche keinen Inhalt, deploye die Website nicht und nimm keine
Aenderungen ausserhalb der freigegebenen Liste vor.

Warte nach dem angezeigten Plan auf meine Freigabe.

Pruefe die Dateiliste, bevor du antwortest. Wenn Codex Dateien anfassen will, die du nicht kennst, frage warum. Wenn der Plan nur "SEO optimieren" sagt, aber keine Datei und kein erwartetes Ergebnis nennt, bitte um mehr Details.

Wenn der Plan richtig aussieht, gib eine eng begrenzte Freigabe:

Freigegeben. Setze nur den obigen Plan um.

Nach den Aenderungen:
- zeige eine kurze Zusammenfassung Datei fuer Datei;
- zeige den relevanten Diff oder den Text vor und nach der Aenderung;
- erklaere, was ich manuell pruefen muss;
- fuehre vorhandene Projektpruefungen aus, falls sie verfuegbar sind;
- fuehre kein Deployment aus.

Dieser Teil macht Automatisierung nuetzlich. Codex kann die wiederholbaren Anpassungen erledigen, aber du entscheidest weiter, was sich aendert und wann etwas veroeffentlicht wird.

Pruefe das Ergebnis, bevor die Seite live geht

Ueberspringe die Vorschau nicht. Eine technisch gueltige Aenderung kann trotzdem unnatuerlich klingen, das Layout stoeren oder eine Seite weniger hilfreich machen.

Nutze diese Release-Checkliste:

Bei Schema-Aenderungen fuehre nach dem Deployment oder gegen eine erreichbare Staging-Seite den Google Rich Results Test oder den Schema Markup Validator aus. Ein gueltiges Schema-Format reicht nicht: Es muss auch dem entsprechen, was Nutzer auf der Seite sehen.

Falls eine Pruefung fehlschlaegt, bitte Codex nicht um zufaellige Folgeaenderungen. Gib den genauen Fehler an, nenne die freigegebene Aenderung, die ihn verursacht hat, und bitte um die kleinste moegliche Reparatur. Wenn du eine Aenderung nicht erklaeren oder pruefen kannst, mache sie vor dem Deployment rueckgaengig.

Was SEO-Automatisierung aus einer Seite nicht wissen kann

Hier werden Einsteiger oft von sehr selbstsicher wirkenden KI-Ergebnissen in die Irre gefuehrt. Manche SEO-Fragen brauchen Daten, die in einem Browser nicht sichtbar sind.

Die Sammlung und Organisation dieser Eingaben kannst du spaeter automatisieren. Fuer deine erste Seite reicht es, Codex diese Punkte als Needs data markieren zu lassen, statt eine Vermutung als Diagnose auszugeben.

Eine einfache woechentliche Routine, die machbar bleibt

Wenn die erste Seite live und geprueft ist, wiederhole den Ablauf jede Woche fuer eine wichtige Seite:

1. Waehle eine Seite mit geschaeftlichem Zweck, keine zufaellige URL.
2. Fuehre die Codex-Pruefung im Nur-Lese-Modus aus.
3. Gib nur wenige klare, risikoarme Updates frei.
4. Pruefe den Umsetzungsplan und den Datei-Diff.
5. Teste lokal oder auf Staging, bevor du ausrollst.
6. Halte Seite, Datum, Aenderungen und offene Fragen in einer einfachen Tabelle oder Markdown-Datei fest.

Fuege nach einigen Wochen mit Aenderungen GSC-Exporte hinzu. Dann kann Codex dir helfen, Seiten zu finden, deren naechste Verbesserung durch echte Impressionen, Klicks oder Suchanfragen gestuetzt wird. Fuer weitergehende Diagnosen kannst du ausserdem einen SEO-Score-Checker fuer Websites zusammen mit deiner Code-Pruefung verwenden.

Haeufige Fragen

Kann Codex das gesamte SEO meiner Website automatisieren?

Nein. Codex kann wiederholbare Arbeit automatisieren: sichtbare Seitensignale pruefen, eine Problemliste ordnen, Titel und Beschreibungen entwerfen, Code- oder Inhaltsaenderungen vorbereiten und eine freigegebene Aenderungsliste pruefen. Entscheidungen ueber das Loeschen von Seiten, Weiterleitungen, Indexierungssteuerung, Canonicals, Geschaeftsaussagen, Deployment oder Performance-Daten brauchen weiterhin menschliche Pruefung.

Muss ich SEO-Keywords kennen, bevor ich anfange?

Nein. Beginne mit einer wichtigen Seite und bitte Codex, ihre sichtbare SEO-Einrichtung in einfacher Sprache zu erklaeren. Keyword-Recherche wird sinnvoll, wenn du neue Seiten erstellen oder entscheiden moechtest, welche bestehenden Seiten mehr Arbeit verdienen. Sie braucht Recherche-Daten und ein Verstaendnis deiner Kunden - nicht nur eine von einem Agenten erzeugte Liste.

Kann Codex eine WordPress-, Webflow- oder Shopify-Seite fuer mich bearbeiten?

Nur wenn deine Codex-Umgebung autorisierten Zugriff auf dieses System oder auf die Website-Dateien hat. Bitte Codex im ersten Ablauf, den genauen Text, Code oder die Aenderung auf Dateiebene vorzubereiten. Nimm die CMS-Aktualisierung dann selbst vor oder hole die Freigabe des Website-Eigentumers ein. Gib keinen Veroeffentlichungszugriff, bevor du einen verlaesslichen Pruefprozess hast.

Bringen diese Aenderungen meine Seite auf Platz eins bei Google?

Nein. SEO-Aenderungen koennen Crawlbarkeit, Relevanz, Klarheit und Nutzererfahrung verbessern. Rankings haengen auch von Wettbewerb, Suchintention, Website-Qualitaet, Links und der Bewertung durch Suchmaschinen im Zeitverlauf ab. Nutze Codex, um bessere und sicherere Entscheidungen zu treffen, nicht als Ranking-Versprechen.

Autor: Julian Mercer, technischer SEO-Praktiker mit 14 Jahren Erfahrung bei Auspia. Julian schreibt ueber Crawlbarkeit, Schema, Rendering, Website-Architektur und technische Grundlagen fuer KI-lesbare Inhalte.