SEO [Search Engine Optimization]

Search engine optimization is the discipline of making a site useful to readers and legible to search systems at the same time. A good SEO page can be fetched, rendered, indexed, understood, cited, shared, and revisited without the crawler or the reader having to guess what the page is about. It connects semantics, information architecture, web standards, publishing operations, source quality, and knowledge graphs.

The useful version of SEO is not a bag of ranking tricks. It is a system for reducing ambiguity. Search engines need stable URLs, descriptive titles, readable text, internal links, canonical signals, crawlable markup, trustworthy references, and metadata that agrees with the visible article. Readers need a page that answers the question they brought, loads quickly, works on mobile, and gives them a path to keep learning.

For this compendium, SEO is also an editorial quality gate. A page should identify its entity, expose aliases and sameAs identifiers, link to neighboring concepts, cite primary references, and keep its visible prose strong enough that the graph does not become a costume over thin content. The graph makes discovery better only when the article underneath deserves to be discovered.

SEO is the practice of increasing qualified organic search visibility by improving the page, the site, and the surrounding evidence that a search system can inspect. The unit of work is not the keyword. The unit of work is a page that satisfies an intent and a site that can prove the page belongs in a coherent topic network.

This makes SEO partly technical and partly editorial:

• Technical SEO makes the page fetchable, renderable, indexable, canonical, fast, mobile-readable, and machine-readable.
• Content SEO makes the page useful, specific, original, well structured, and linked to credible references.
• Entity SEO makes the page clear about people, organizations, concepts, places, products, works, standards, and datasets.
• Measurement makes sure search visibility is not confused with quality, revenue, or trust.

The best SEO work improves the web page even if no ranking metric changes immediately. If an edit only helps an automated score while making the page less useful, the edit is not aligned with durable search quality.

Google's Search Central guidance repeatedly emphasizes helpful, reliable, people-first content. In practice, that means an article should be written for the reader before it is tuned for a crawler. A page about data sources, for example, should explain source provenance and evaluation before adding schema markup. A page about photography should help the reader understand images, captions, rights, and visual evidence before chasing image-search snippets.

People-first does not mean machine-hostile. It means the machine-readable layer should faithfully describe the visible work. Titles, descriptions, headings, JSON-LD, canonical tags, and internal links should be different views of the same page, not competing stories. When the metadata overpromises, the page becomes less trustworthy for both the reader and the index.

Good compendium SEO therefore starts with a reader promise:

• What question does this page answer?
• What entity, process, or concept is the page primarily about?
• What neighboring pages should a reader visit next?
• What external sources would let a skeptical reader verify the claims?
• What structured facts can safely be represented in the knowledge graph?

Only after those answers exist should the page be tuned for search presentation.

A simple search-system model has five stages: discovery, crawl, render, index, and presentation. Discovery finds URLs through links, sitemaps, feeds, submissions, and prior crawl history. Crawling fetches the URL and checks whether the server, robots rules, redirects, headers, and page body permit access. Rendering evaluates enough of the page to see content that depends on JavaScript or client-side UI. Indexing stores the page, canonicalizes duplicates, and attaches signals. Presentation turns the indexed page into a search result, title link, snippet, rich result, AI summary source, local result, image result, or other surface.

Each stage can fail independently. A page can be beautifully written but undiscovered. It can be discovered but blocked. It can be crawled but canonicalized away. It can be indexed but shown with a poor title. It can rank for irrelevant intent because the page title and body disagree. SEO work is the habit of inspecting those stages without collapsing them into one vague ranking score.

For a content-heavy site, this model suggests a practical order:

1. Make the content good enough to deserve discovery.
2. Make the URL stable and linked from relevant pages.
3. Make the document crawlable and renderable.
4. Make the metadata accurate.
5. Make the surrounding graph and references meaningful.
6. Measure what actually happened.

The order matters. Performance work cannot redeem thin content. Structured data cannot make a false claim true. A sitemap cannot make an orphaned page conceptually important. Search quality is cumulative.

An entity page should make one thing unmistakable: what the page is about. For compendium articles, that contract includes title, description, aliases, tags, related pages, Wikidata ID when available, sameAs links, a clear introduction, section headings, internal links, and reference sources.

The visible page should answer the entity question before it branches into tools or workflow. A reader arriving at /compendium/seo should understand SEO as a discipline before seeing a tool list. A reader arriving at Semantic Web should understand linked data before seeing RDF terms. A reader arriving at Domains should understand canonical identity, redirects, and namespace trust before seeing registrar details.

The graph layer should then make the entity reusable:

• Aliases catch alternate names and search phrasing.
• sameAs links connect the local node to public identifiers.
• Related pages expose conceptual bridges instead of arbitrary recommendations.
• Sections become claim and topic anchors.
• External resources preserve provenance and auditability.

This is where SEO and the semantic web meet. Both are concerned with making meaning machine-readable without losing the human context that gives the meaning value.

Search systems cannot reward a page they cannot access or interpret. The crawl and index contract includes a reachable URL, stable server responses, valid HTML, non-conflicting robots rules, useful internal links, canonical tags that point to the intended page, and content that is present after rendering.

Important crawl and index checks include:

• The page returns a successful status code and does not depend on a fragile redirect chain.
• robots.txt does not block resources needed for rendering.
• The page is linked from relevant internal pages, not only from a sitemap.
• The canonical URL matches the intended public URL.
• The title, description, H1, visible body, and structured data describe the same entity.
• The page appears in the sitemap when it is meant to be discoverable.
• The page is not accidentally marked noindex.

Sitemaps are discovery hints, not proof of quality. Canonical tags are consolidation hints, not magic shields against duplication. Robots rules control access, not trust. These tools are strongest when the site architecture already makes sense.

Information architecture shapes how search systems and readers understand a site. A strong architecture groups related pages, gives important pages multiple meaningful paths, avoids dead-end pages, and keeps navigational labels aligned with the actual content.

In the compendium, internal links are not decorative. They are semantic claims. Linking SEO to Blogs says publishing cadence and article structure matter. Linking it to Standards says protocols, schema, sitemaps, robots, accessibility, and metadata conventions matter. Linking it to GitHub says repositories, release notes, and source-linked project pages can become public trust surfaces.

Useful internal linking has several properties:

• It links from explanatory context, not just from a footer.
• It uses natural anchor text that names the destination concept.
• It connects near neighbors and useful contrasts.
• It avoids orphan pages and circular filler.
• It exposes enough paths for readers to continue the task.

An underlinked article may still be indexed, but it will be harder to understand as part of a site. A dense but meaningless link graph is not better. The graph should describe a real conceptual map.

On-page SEO begins with a readable document. The page should have one H1, descriptive H2 sections, paragraphs that explain the topic rather than only listing terms, and links that help a reader verify or continue. Headings should be useful when scanned out of context because search systems, assistive technology, readers, and local semantic indexing all use heading structure as a map.

For durable compendium pages:

• Start with a plain-language definition.
• Add a working model that organizes the concept.
• Explain interfaces, workflows, or failure modes.
• Link to related compendium pages where the bridge is real.
• Cite external references for drift-prone or standards-based claims.
• Avoid keyword stuffing, artificial FAQ padding, and duplicated boilerplate.

The goal is a page that reads like a compact reference essay and also behaves like a structured node in the site. The title should be natural. The description should summarize the article. The body should deliver more value than the metadata promises.

The title tag is not just a ranking input. It is a promise shown in search results, browser tabs, social previews, and command palettes. A good title names the entity and, when needed, disambiguates it. A bad title crams in synonyms, pipes, years, and marketing adjectives until the page feels less trustworthy.

Descriptions should be specific and accurate. They do not need to include every phrase a page might rank for. Their job is to help the reader decide whether the page matches the task. Search systems may rewrite snippets, but a clear description still helps local site search, social previews, and semantic indexing.

Metadata should be checked against the rendered page:

• Does the title match the H1 and article scope?
• Does the description describe the actual content, not the desired ranking?
• Does the Open Graph image match the page promise?
• Does the canonical URL match the public route?
• Does the sitemap include the page only when it should be public?
• Does JSON-LD avoid claims that are not visible on the page?

When metadata and content diverge, trust leaks out of the system.

Structured data helps search systems understand the type of page, the entities on it, and the relationship between visible content and machine-readable claims. Schema.org vocabulary can describe articles, people, organizations, breadcrumbs, images, software applications, datasets, products, and many other things, but it should not be treated as a loophole around weak content.

The important rule is agreement. Structured data should describe content that is visible or directly represented on the page. An article should not claim reviews, authorship, ratings, dates, or images that the reader cannot inspect. A local knowledge graph should not turn every related link into a fact of equivalence. sameAs should be reserved for identity or very close external identifiers, not for any useful reference.

For this site, structured data and graph indexing should preserve:

• page type and canonical route;
• title, description, date, and article body where appropriate;
• tags, aliases, and content world;
• internal relationships to related pages;
• external references and their source URLs;
• backed claims extracted from sections.

That makes SEO useful beyond public search. It also improves local search, graph navigation, AI retrieval, and future audit workflows.

Modern search engines can render JavaScript, but rendering is still a separate stage with its own cost and failure modes. Important content should not depend on a brittle client-only path when a server-rendered or statically rendered page can expose it directly. For a Next.js app, the safest pattern is to make public content visible in the server-rendered HTML and use client components for interaction, filtering, animation, graph exploration, and progressive enhancement.

JavaScript-heavy pages need extra care:

• The primary content should be present without waiting for user interaction.
• Links should be real anchors when navigation matters.
• Metadata should be generated on the server.
• Client-rendered graph UI should not be the only representation of article relationships.
• Loading states should not permanently hide content from crawlers or readers.

The compendium graph is valuable because it adds exploration on top of article pages. It should not replace the article pages as the canonical reading surface.

Performance matters because slow pages frustrate readers, reduce crawl efficiency, and make interaction less reliable. Core Web Vitals and Lighthouse-style checks are useful because they expose practical problems: slow rendering, layout shift, heavy JavaScript, inaccessible controls, large images, and unnecessary blocking resources.

Performance should be interpreted alongside content quality. A fast empty page is not a good result. A rich article that takes too long to become readable still has a quality problem. The target is a page that answers the reader quickly, remains stable while loading, and does not make the browser do needless work.

For compendium pages, useful performance constraints include:

• keep article text server-rendered and readable early;
• avoid loading heavyweight graph code on pages that do not need it;
• keep images sized, captioned, and compressed;
• make mobile typography readable without horizontal scrolling;
• verify the article page and graph page separately.

Performance is part of editorial respect. The reader's time is one of the page's inputs.

Search visibility is not only text search. Images, diagrams, screenshots, figures, and media assets can become entry points into a site. They should have descriptive alt text when meaningful, captions when context matters, stable file paths, correct dimensions, and surrounding text that explains why the media exists.

Accessibility and SEO overlap because both reward clarity. Semantic HTML, meaningful headings, descriptive links, readable contrast, keyboard navigation, and stable layout all help humans and machines. An image gallery that cannot be navigated, a graph that hides its meaning behind an unlabeled canvas, or a button that says only "click here" weakens both accessibility and search understanding.

For media-rich pages like Photography, Maps, and Data Visualization, the page should explain the visual object in text, not rely on the asset alone. That gives readers, assistive technology, search systems, and graph extraction a shared anchor.

AI-assisted search surfaces do not require a separate secret markup strategy. The durable guidance is still to make pages crawlable, indexable, helpful, well cited, and clear about the entities they discuss. Google documents AI Search features as drawing from eligible web content according to the same broad requirement that pages be accessible and indexable.

That does not make AI search irrelevant. It changes the value of evidence and structure. Pages that define terms cleanly, cite primary sources, expose entity relationships, and avoid vague marketing prose are easier to quote, summarize, retrieve, and verify. Pages with thin summaries, broken references, and ambiguous authorship are easier to ignore or misinterpret.

For this compendium, AI search readiness means:

• concise definitions near the top of each article;
• enough body text to support a useful summary;
• internal links that represent real conceptual bridges;
• primary references for claims that can drift;
• stable metadata and canonical URLs;
• knowledge graph nodes and claims that match visible prose.

The same work that helps public search also helps local AI retrieval. That is the useful overlap.

SEO measurement should distinguish indexing, visibility, engagement, and outcomes. Google Search Console (opens in new tab) and Bing Webmaster Tools (opens in new tab) can show indexing, query, click, impression, and crawl signals. PageSpeed Insights (opens in new tab) can expose performance and accessibility problems. Server logs and analytics show what readers and crawlers actually request.

Useful leading indicators include:

• no broken internal compendium links;
• page-specific external links audited or triaged;
• clear title, description, and canonical route;
• sitemap inclusion for public pages;
• primary content visible in server-rendered HTML;
• enough internal links to avoid orphaned concepts;
• graph index current after content changes;
• browser verification on desktop and mobile.

Rank tracking can be useful, but it is a lagging and noisy indicator. For a personal site with a compendium, stronger evidence is whether each page is readable, source-backed, linked, indexed locally, and connected to the rest of the knowledge system.

A healthy SEO workflow is cyclical:

1. Identify the page's primary entity and reader question.
2. Check whether the current title, description, and article body still match.
3. Expand the article until it answers the question with useful context.
4. Add internal links to genuine neighboring concepts.
5. Add primary external references for standards, tools, or drift-prone claims.
6. Verify internal links and outbound URLs.
7. Check metadata, canonical URL, sitemap inclusion, and structured data.
8. Rebuild the search index and knowledge graph.
9. Browser-check the article and graph views on desktop and mobile.
10. Revisit search and analytics data later for missing reader intents.

The workflow can use rules of thumb as triage thresholds: no incoming links means the page is probably under-integrated, duplicate descriptions mean the entity is not distinct enough, and a broken external reference should trigger repair, archival capture, replacement, or removal. A heuristic is useful only when it points to an editorial action.

Each mature compendium page should pass this checklist:

• The title names the entity in ordinary reader language.
• The description is specific, accurate, and roughly snippet-sized.
• The introduction defines the concept before discussing tools.
• The article has enough prose to support search snippets and local retrieval.
• H2 headings describe real sections.
• Internal links connect to neighboring pages with clear anchor text.
• External links point to canonical, current, useful sources.
• aliases, sameAs, wikidata, tags, and related pages improve graph utility.
• References are visible and not hidden only in frontmatter.
• The page has no broken internal links or missing anchors.
• The page renders without mobile overflow.
• The graph page can select the article node and expose useful neighbors.

This checklist is not meant to produce sameness. It is a guardrail against hollow pages.

Broken links are SEO, UX, and provenance failures at once. An outbound link can die, redirect to unrelated content, block crawlers, require JavaScript, or become less authoritative than a replacement source. Internal links can break when slugs change, headings are renamed, or public assets move.

For this repo, link auditing should be easy enough to run during normal content work:

• mise exec -- bun run links:audit:urls -- <slug> lists outbound URL candidates and source references without spending Firecrawl credits.
• mise exec -- bun run links:audit:internal checks compendium pages, anchors, and public assets locally.
• mise exec -- bun run links:audit:smoke -- <slug> runs a bounded Firecrawl audit when credits are available and writes a .firecrawl/ report.

When Firecrawl credits are unavailable, the partial report should still preserve the requested URLs and source references. A fallback direct check can help triage obvious 200, 404, 410, and redirect cases, but it should not be confused with a full crawler-backed audit. The point is to keep evidence near the editorial decision.

wget remains useful for archival evidence. It can preserve status codes, redirect chains, headers, and page bodies around a changed reference so a future maintainer can understand why a source was replaced.

SEO and knowledge graphs share a core question: what does this page mean, and how does it relate to other things? A page can rank for a phrase while still being a poor graph node. A graph node can have many edges while still being a weak page. The useful target is both: a readable article and a structured concept.

For each compendium page, the knowledge graph should expose:

• the article as a stable node;
• section nodes for meaningful headings;
• tag and content-world relationships;
• internal article relationships;
• external reference nodes;
• backed claims derived from visible content;
• alias and identifier links when available.

This makes the graph useful for navigation, search, retrieval, and provenance. It also keeps the SEO surface honest: a page that lacks prose cannot hide behind graph density, and a page with prose but no relationships remains under-integrated.

Useful SEO tools include Google Search Console (opens in new tab), Bing Webmaster Tools (opens in new tab), PageSpeed Insights (opens in new tab), Schema.org (opens in new tab), Rich Results Test (opens in new tab), and crawler tools such as Screaming Frog SEO Spider. Commercial suites such as Ahrefs, Moz, Semrush, and similar tools can help with competitive visibility, backlinks, and keyword research, but they should not replace primary evidence from the page, server, sitemap, search console, and browser.

The tool stack should answer concrete questions:

• Can the crawler fetch and render the page?
• What canonical URL did the page declare?
• Which queries and pages are visible in search tools?
• Which links are broken, redirected, or unverified?
• Which metadata fields are missing or duplicated?
• Which graph nodes and claims were indexed after the build?

Tools are instruments. They become strategy only when they lead to better pages.

SEO fails when the page is optimized for a metric while becoming less useful to a reader. Common failures include thin articles with inflated headings, duplicate descriptions, stale dates, keyword stuffing, orphaned pages, broken outgoing links, JavaScript-only content, structured data that overclaims, references that do not support the claim, and internal links that do not represent real conceptual relationships.

Another failure is treating SEO as a one-time launch task. Search surfaces drift, links rot, article scope changes, site architecture changes, and user questions evolve. Durable SEO is maintenance: refresh content, audit links, preserve evidence, keep metadata aligned, and rebuild the graph.

For this compendium, the most dangerous failure is a graph that looks sophisticated while the page bodies remain weak. The remedy is direct: write stronger articles, cite better sources, connect pages honestly, and verify the rendered experience.

• Semantic Web for linked data, identifiers, RDF, and machine-readable meaning.
• Semantics for reference, interpretation, and meaning.
• Graphs for network structure and knowledge graph utility.
• Data Sources for provenance, quality, and source evaluation.
• Standards for protocols, vocabularies, sitemaps, robots, and schema conventions.
• Blogs for publishing surfaces, freshness, article structure, and content discovery.
• Domains for canonical identity, redirects, and namespace trust.
• Design for typography, hierarchy, readability, and page experience.
• GitHub for repository metadata, release evidence, and public project surfaces.
• Data Visualization for readable measurement and search-console reporting.
• Language and Symbols for naming, labels, and meaning.
• WebAssembly for browser execution surfaces that still need crawlable explanations.
• wget for Web Archival for link audit evidence, mirrors, and crawl-preserved references.

• Google Search Central SEO Starter Guide (opens in new tab)
• Google Search Essentials (opens in new tab)
• Google guidance on helpful, reliable, people-first content (opens in new tab)
• Google guidance on title links (opens in new tab)
• Google structured data introduction (opens in new tab)
• Google JavaScript SEO basics (opens in new tab)
• Google sitemap overview (opens in new tab)
• Google canonical URL guidance (opens in new tab)
• Google AI Search features and website owners (opens in new tab)
• Schema.org documentation (opens in new tab)
• Schema.org Article type (opens in new tab)
• Sitemaps protocol (opens in new tab)
• Robots Exclusion Protocol RFC 9309 (opens in new tab)
• Google Search Console (opens in new tab)
• Bing Webmaster Tools (opens in new tab)
• PageSpeed Insights (opens in new tab)
• Rich Results Test (opens in new tab)