Kurzfassung für den rohesten Teig im Team: Hinter jedem einzelnen Keyword steht bei uns kein Textschnipsel und kein aufgeblasener Absatz — sondern ein vollständiger, recherchierter SEO-Artikel. In zwei Sprachen. Mit Bildern, Videos, interner Verlinkung und festen Qualitätsregeln. Diese Seite zeigt dir den kompletten Prozess vom Keyword bis zum Live-Deploy.
Das ist der Punkt, den man von außen leicht unterschätzt. Wenn in unserer Liste „nginx reverse proxy“ steht, dann ist das kein Stichwort, das irgendwo eingestreut wird. Es ist ein eigener Artikel jenseits der 3.000 Wörter, mit eigenem Bildsatz, zwei Videos und einer eigenständig geschriebenen zweiten Sprachfassung. Achtzehn Mal.
%%YEAR%% statt hartcodiertem Jahr. Wird beim Build ersetzt, damit Artikel nicht optisch veralten.Fünf Kategorien, Angabe je Keyword (jedes existiert doppelt, DE + EN):
Gesamtbestand an Bildmaterial: 97 WebP-Dateien. Der längste Artikel ist „wordpress suchmaschinenoptimierung plugin“ mit 3.612 Wörtern.
Elf Schritte, jedes Mal dieselben. Kein Schritt wird übersprungen, auch nicht bei Zeitdruck — genau das ist der Grund, warum das Ergebnis planbar ist.
Jedes Keyword wird vorher eingeordnet: Suchintention (informational, commercial, comparison), Wettbewerbsdichte und Priorität. Wir gehen bewusst nicht auf ultrakompetitive Head-Terms, sondern auf Begriffe mit realistischer Rankingchance — und auf solche, wo wir echte Erfahrung mitbringen statt nachgeplapperter Theorie.
Freigegebene Keywords wandern in eine geordnete Warteschlange und werden strikt von oben nach unten abgearbeitet — ein Artikel pro Tag. Zu jedem Eintrag stehen die zugehörigen Google-Folgefragen und Hinweise, worauf beim Schreiben zu achten ist. Erledigtes wird mit Datum abgehakt und bleibt als Historie stehen.
Vor dem ersten Satz: aktueller Stand des Themas, Vergleichswerte, was die Konkurrenz auslässt. Wo wir eigene Praxiserfahrung haben, wird die zur Grundlage — etwa der dokumentierte Sicherheitsvorfall auf unserem eigenen Server, der jetzt als Substanz in den Security-Artikel einfließt statt allgemeiner Ratschläge.
Zielspanne 2.000–3.500 Wörter, Ton ehrlich und direkt, persönliche Testerfahrung statt Marketingsprache. Focus-Keyword in Title, Description, mindestens einer H2 und in den ersten 100 Wörtern. Frontmatter komplett, Kategorie ist Pflichtfeld.
Ausdrücklich keine Wort-für-Wort-Übersetzung. Die englische Version wird eigenständig geschrieben: eigene Formulierungen, angepasste Beispiele, teils andere Schwerpunkte, weil englischsprachige Leser andere Vorkenntnisse und andere Suchbegriffe haben. Das kostet doppelte Arbeit — und ist genau der Grund, warum beide Fassungen ranken können.
Pro Artikel ein Hero-Bild (1200 × 630 px) plus vier bis fünf Inline-Bilder, alle als WebP, maximal 200 KB, im gleichen cleanen Tech-Blog-Stil. Jedes Bild bekommt beschreibenden Alt-Text — für Barrierefreiheit und für die Bildersuche. Insgesamt liegen aktuell 97 WebP-Dateien im Bestand.
Zwei eingebettete YouTube-Videos je Artikel, thematisch passend platziert — nach dem Intro oder direkt beim behandelten Tool. Ausgewählt werden offizielle Demos, Konferenzvorträge oder Reviews etablierter Tech-Kanäle. Eingebunden in einem responsiven 16:9-Container, damit auf dem Handy nichts überläuft.
Der neue Artikel wird mit thematisch passenden Bestandsartikeln und den passenden Tools verknüpft — und die Bestandsseiten bekommen umgekehrt einen Link auf den neuen. So wächst mit jedem Artikel nicht nur eine Seite, sondern die Struktur der gesamten Domain.
Eine Kette, drei Stufen: erst werden die Social-Vorschaubilder automatisch erzeugt, dann baut Astro die komplette Seite statisch, zum Schluss ersetzt ein Skript alle %%YEAR%%-Platzhalter durch das aktuelle Jahr.
node scripts/generate-og-images.mjs && astro build && node scripts/apply-year.mjsdist/.Das gebaute Verzeichnis wird per rsync auf den eigenen Server nach /var/www/getmind gespiegelt, ausgeliefert wird über Caddy mit automatischem HTTPS. Kein externer Hoster dazwischen, kein Vendor-Lock-in, keine Buildminuten-Rechnung.
npm run build
rsync -avz dist/ /var/www/getmind/Nach jedem Deploy werden die URLs tatsächlich abgerufen und geprüft — beide Sprachfassungen, Bilder, Sitemap. Grundregel: „Verify before reporting“. Erst wenn das Ergebnis nachgemessen ist, gilt der Artikel als fertig. Aktuell stehen 64 URLs in der Sitemap.
Der einfachste Weg, kurzfristig besser auszusehen, ist zu schummeln. Wir tun es an den folgenden fünf Stellen bewusst nicht — auch dann nicht, wenn es niemand merken würde.
Viele Seiten schreiben sich per JSON-LD goldene Sterne in die Google-Suchergebnisse, ohne dass je jemand bewertet hat. Das sieht in der Suche stark aus, verstößt aber gegen Googles Richtlinien und kann die ganze Domain kosten. Wir setzen keine aggregateRating-Auszeichnung ohne echte Bewertungen. Punkt.
Bilder komprimieren, QR-Codes bauen, Meta-Titel prüfen, Markdown schreiben: Das läuft alles clientseitig, die Daten verlassen das Gerät nicht. Eine Ausnahme gibt es — der Core-Web-Vitals-Test braucht zwangsläufig ein Backend, weil eine fremde Seite gemessen werden muss. Genau das steht auch so auf der Toolseite. Lieber eine ehrliche Ausnahme benennen als eine bequeme Halbwahrheit.
Performance-Messwerte aus einer synthetischen Messung sind nicht dasselbe wie Felddaten echter Nutzer. Wo wir Labormessungen zeigen, kennzeichnen wir sie als solche — statt sie als „echte Nutzerdaten“ zu verkaufen.
Im Text steht nie ein hartcodiertes Jahr, sondern %%YEAR%%. Beim Build wird ersetzt, zum Jahreswechsel läuft der Rebuild automatisch. Ausnahmen sind bewusst gesetzt: Veröffentlichungsdaten, URL-Slugs und historische Angaben bleiben fest — ein Vorfall aus 2026 wird nicht magisch zu 2027.
Nichts gilt als fertig, weil es fertig aussieht. Nach jedem Deploy werden die URLs wirklich aufgerufen und geprüft, bevor irgendwo „erledigt“ steht. Das klingt banal — es ist aber der Unterschied zwischen einem Statusbericht und einem belegten Ergebnis. Dieselbe Regel gilt übrigens auch für diese Seite hier: jede Zahl, die du oben liest, wurde vor dem Schreiben nachgezählt.
Zwei Sprachfassungen sind SEO-technisch ein Risiko, wenn man sie falsch verdrahtet: Google kann sie als Doppelinhalt werten oder die falsche Version im falschen Land ausspielen. Deshalb ist die Sprachlogik fest im Layout verankert und passiert nicht pro Artikel von Hand.
| Aspekt | Englisch | Deutsch |
|---|---|---|
| Pfad | Root, z. B. /blog/… | Unterverzeichnis /de/blog/… |
| Slug | englischsprachig | eigener deutscher Slug |
| hreflang | wechselseitig gesetzt — jede Fassung verweist auf die andere | |
| Canonical | jede Sprachfassung ist ihr eigenes Canonical, kein Verweis quer | |
| OG-Karte | eigene Social-Vorschau je Sprache, automatisch beim Build erzeugt | |
| Navigation | Sprachumschalter springt auf die entsprechende Seite, nicht auf die Startseite | |
| Inhalt | eigenständig verfasst — keine maschinelle Spiegelung | |
Ergebnis: 64 URLs in der Sitemap — Artikel beider Sprachen, Tools, Kategorie- und Systemseiten.
Ein Blog lebt davon, dass jemand eine Frage hat. Ein Tool lebt davon, dass jemand eine Aufgabe hat — und wiederkommt. Deshalb steht neben dem Content eine zweite Säule: kostenlose Werkzeuge, jedes davon in beiden Sprachen, ohne Anmeldung, ohne Limit.
JPEG, PNG, WebP und AVIF verkleinern — direkt im Browser, ohne Upload. Die Bilder verlassen das Gerät nicht.
Tool ansehen →URL, WLAN, vCard, E-Mail und SMS als QR-Code, mit Logo und Farben, Download als PNG und SVG. Statisch — läuft nie ab.
Tool ansehen →SEO-Titel und Description schreiben, Pixelbreite prüfen und in der Google-Vorschau sehen, was tatsächlich angezeigt wird.
Tool ansehen →LCP, CLS und INP messen, Performance-Score und konkrete Optimierungstipps. Das einzige Tool mit Backend — und genau so steht es auch dort.
Tool ansehen →Markdown mit Live-Vorschau, Text aus Word oder Google Docs in sauberes Markdown umwandeln, Tabellen-Baukasten, Export als .md, HTML oder PDF.
Tool ansehen →Ein Tool, das jemand nützlich findet, wird verlinkt und weiterempfohlen — ganz ohne dass wir darum bitten. Genau das zahlt wieder auf die Artikel ein. Deshalb verweisen Tools und Artikel gegenseitig aufeinander.
Bewusst schlicht gehalten. Je weniger bewegliche Teile, desto weniger kann nachts kaputtgehen.
Die Seite wird komplett vorgerendert. Es gibt zur Laufzeit keine Datenbank und kein CMS, das ausfallen oder gehackt werden könnte — ausgeliefert werden fertige HTML-Dateien.
Ausgeliefert über Caddy auf unserer eigenen Maschine, HTTPS-Zertifikate holt und erneuert Caddy selbstständig. Kein Plattform-Abo, keine Buildminuten, keine Preisänderung von außen.
Die Social-Vorschaukarten für Artikel entstehen im Build-Schritt automatisch — je Sprache eine. Niemand muss daran denken, und trotzdem sieht jeder geteilte Link ordentlich aus.
Zum Jahreswechsel läuft der Build automatisch erneut und ersetzt alle Jahres-Platzhalter. Artikel altern dadurch nicht sichtbar, ohne dass jemand 36 Dateien anfassen muss.
Beides wird beim Build erzeugt und an die Suchmaschinen gemeldet. Aktuell 64 URLs.
Bauen, spiegeln, prüfen. Kein Klickpfad durch fremde Dashboards, dadurch reproduzierbar und im Zweifel in Sekunden zurückrollbar.
Die Warteschlange wird von oben nach unten abgearbeitet, ein Keyword pro Tag, jedes wieder als vollständiger Artikel in beiden Sprachen. Diese acht stehen aktuell offen:
Jedes dieser Keywords bringt bei Fertigstellung wieder zwei Artikel, fünf bis sechs Bilder je Sprachfassung und zwei Videos mit. Deshalb wächst der Wortstand nicht linear, sondern in Sprüngen. Und wenn die Queue leer ist, wird nicht stillschweigend improvisiert — dann wird nachgefragt.
Du hast jetzt in ein paar Minuten gesehen, was sonst in 36 Artikeln steckt: hinter jedem einzelnen Keyword steckt ein vollständiger, zweisprachiger Artikel — recherchiert, bebildert, verlinkt und nachgeprüft. Kein Textschnipsel. Kein Füllmaterial.
Alles gut durchgebacken. Im Gegensatz zu dir. 🔥
getmind.io ansehen →