SEO Geo

Technical SEO / GEO Checklist

This file is the technical rulebook for search and AI-engine readability on eunomia.dev pages. It is an implementation and QA checklist only — see Scope below for what it does and does not cover.

Scope

• Use this checklist for concrete eunomia.dev pages, docs, tutorials, blog drafts, content artifacts, and static-site SEO/GEO implementation changes.
• Do not use this checklist to choose article titles, judge whether a title is compelling, rewrite H1 hooks, decide the article angle, shape a story opening, or police prose style. Title quality and reader contract live in blog-writing-style; use this file only after the title direction is chosen to check technical metadata constraints such as length, primary keyword visibility, duplicate phrase risk, and crawlable phrasing.
• Do not use this skill to answer long-term media strategy, topic selection, channel mix, brand positioning, campaign cadence, or platform growth questions. Keep those decisions in draft/, especially draft/content-platform-strategy.zh.md and draft/seo-geo-plan.zh.md.
• Use this skill only after a user problem, reader promise, source artifact, and brand-pillar fit have already been chosen by the appropriate planning or writing workflow.
• Platform publishing execution belongs to the platform-specific publisher skills (zhihu-publisher, juejin-publisher, x-publisher, linkedin-publisher, reddit-publisher, hackernews-publisher, lobsters-publisher, medium-publisher, devto-publisher).
• When changing this checklist or making claims about current search/AI-engine behavior, verify against current primary sources such as Google Search Central, schema.org, OpenAI crawler documentation, or the platform's official help/browser-visible UI. Treat third-party skill repositories and growth advice as patterns, not authority.

Metadata (check first on every page)

• description frontmatter is required and must be 150-160 characters (ZH: roughly 75-85 CJK-width characters): one sentence with a compact background opening, value proposition, and primary keyword phrase. The first clause should name the domain problem or reader situation before the page-specific finding, tool, benchmark, or practical consequence. Longer descriptions get truncated in search results.
• Title (H1) technical check only: roughly within 60 characters when possible, no duplicate primary phrase collision, and enough keyword visibility for search snippets. Do not shorten, flatten, or remove high-value title signals such as An Empirical Study, Inside SchedCP, sched_ext, or Semantic Flamegraphs merely to satisfy an SEO heuristic. If title appeal, article promise, or professional framing is in question, defer to blog-writing-style.
• date frontmatter required. New posts also need a slug (short, kebab-case, keyword-bearing); never add or change a slug on an already-published post, and never change published filenames or URLs.
• Headings carry search phrasing. Prefer H2s a reader would type ("What Generic eBPF Enforcement Misses") over generic labels ("Discussion", "Overview").
• Images need descriptive alt text containing the relevant term, not "image" or "figure 1". Important claims must exist in crawlable HTML text, never only inside images.
• First paragraph before <!-- more --> must stand alone as the excerpt: one compact background sentence or clause, hook plus the primary keyword phrase, no dangling references.

Keyword strategy

• One primary keyword phrase per page. Before writing, check whether a sibling post already owns that phrase; if so, link to it instead of competing with it (keyword cannibalization is how our own syndicated copies and near-duplicate surveys outrank originals).
• Internal links: every post links 2-3 related eunomia.dev posts or docs in context, and the project GitHub repo at least once. Use canonical absolute HTTPS URLs for non-image internal links, such as https://eunomia.dev/blog/YYYY/MM/DD/slug/, https://eunomia.dev/zh/blog/YYYY/MM/DD/slug/, https://eunomia.dev/tutorials/.../, or https://eunomia.dev/bpftime/.../; do not use source-relative Markdown paths such as other-post.md, ../docs/page.md, or root-only paths such as /blog/.../ in Markdown intended for syndication. Hub posts (project announcements) should be linked from every related post.
• Image links: post-local images may stay relative to the Markdown file, usually imgs/name.png, because the article and media move together. Do not convert image links to filesystem absolute paths.
• Contested or rising industry terms (for example, stack-layer names) are targeted as ride-along definitional pieces: define the term honestly, concede the mainstream reading, then state our angle and where our projects sit relative to it. Never claim to be a category we do not ship.