SEO in 2026 has not been replaced by AI search. Pages still need to be crawlable, indexable, focused on a clear intent, genuinely useful, and stable to use, with consistent URLs and semantic signals that describe the real page. AEO and GEO extend this discovery system into answer and generative interfaces; they do not bypass it.
This guide uses the current ToolGarden codebase as a working example of how a bilingual utility site can make SEO part of the product architecture. Tool metadata, translations, pages, blog records, and build scripts feed metadata, sitemaps, JSON-LD, robots directives, and optional AI discovery files from shared sources. It also separates implemented practices from measurements that still require production data and from tactics that became obsolete or overstated in 2026.
How SEO, AEO, and GEO fit together in 2026
Google’s 2026 guide to generative search states that AI Overviews and AI Mode still depend on the core Search index, ranking and quality systems, retrieval-augmented generation, and related query fan-out. A page must first be eligible for indexing before a generative feature can retrieve and cite it. Technical SEO, content quality, internal linking, and page experience therefore remain foundational.
AEO emphasizes whether a page gives a direct, accurate answer. GEO emphasizes whether generative systems can understand, retrieve, and cite the page. They change how visibility is presented and measured, not the requirement to earn discovery and trust.
| Discipline | Primary goal | Still depends on |
|---|---|---|
| SEO | Earn visible, clickable organic results | Crawling, indexing, relevance, quality, and experience |
| AEO | Provide a clear direct answer | Indexable content, accurate language, entities, and context |
| GEO | Be cited or recommended in generated answers | Search indexes, original evidence, trustworthy sources, and freshness |
| Agent SEO | Help browser agents understand and complete tasks | Accessible DOM, explicit controls, stable state, and safe boundaries |
Make SEO part of the product architecture
ToolGarden drives tool discovery from a registry. A tool’s id, route, category, and base description live in toolRegistry; English and Chinese names come from messages; pages, hubs, breadcrumbs, sitemap entries, JSON-LD, and generated llms indexes derive from those sources. Adding a tool does not require copying its name and URL into a separate stack of SEO files.
A single source of truth is not merely a developer convenience. It prevents long-lived defects such as a renamed page with a stale sitemap entry, an English title in Chinese structured data, or a related article pointing at a route that no longer exists.
| Source of truth | Derived discovery surfaces | Main failure prevented |
|---|---|---|
| Tool registry | Home cards, hubs, navigation, sitemap, tool JSON-LD | Missing pages, inconsistent routes, duplicate metadata |
| Localized messages | Titles, descriptions, FAQs, Open Graph, visible copy | Mixed languages and mismatched translation structures |
| Blog article registry | Blog index, static routes, Article JSON-LD, llms article index | Orphan articles and stale dates |
| Topic cluster config | Pillar/cluster navigation, related content, about/hasPart links | Random internal links and diluted topics |
| Shared SEO helpers | Canonical, hreflang, title, description, and Open Graph | Different rules on different page types |
- Register a capability before exposing it through search and AI discovery surfaces.
- Make SEO copy describe the real technical boundary; browser-local processing does not mean the page never makes a network request.
- Generate discovery artifacts during the build so reviews and production output use the same source data.
Match search intent before choosing a page type
Keywords are not instructions to repeat one phrase in the title and body. They represent the task a visitor is trying to complete. Utility-site intent usually falls into immediate action, comparison, troubleshooting, and conceptual learning. Each intent deserves a suitable page instead of forcing one tool page to carry every explanation.
ToolGarden treats tool pages as task destinations, hubs as category and choice pages, and articles as explanations of concepts, workflows, and failure modes. Articles link into executable tools, while tools point back to relevant guides, creating a usable loop rather than a collection of isolated landing pages.
| Search intent | Best page type | Required content |
|---|---|---|
| Action: format JSON online | Tool page | Fast input, clear action, example, and error feedback |
| Comparison: WebP or AVIF | Comparison article | Definitions, data table, compatibility, and recommendation |
| Troubleshooting: JSON Unexpected token | Problem guide | Symptoms, causes, repair steps, and verification |
| Learning: complete JSON tools guide | Pillar page | Concept map, subtopics, tools, and article navigation |
- Give each indexable URL one primary intent so near-duplicate pages do not compete.
- Let the title state what the page is, the excerpt state what it solves, and the body prove why it is trustworthy.
- Use descriptive internal-link anchors to connect prerequisite knowledge, the current explanation, and the next tool action.
Localized URLs, canonical, and hreflang must agree
The site uses explicit /en and /zh prefixes. Every localized page has a self-referencing canonical, reciprocal hreflang annotations, and an x-default pointing to the default locale. Canonical identifies the preferred URL within a language; hreflang connects corresponding language versions. One cannot replace the other.
Google describes redirects as a strong canonical signal, rel=canonical as a strong signal, and sitemap inclusion as a weaker signal. All three should agree. Do not submit one URL in a sitemap while a page canonicalizes elsewhere, and do not use robots.txt for canonicalization.
The meta keywords field is not a Google ranking lever. Article tags and tool keywords can still organize content, score related articles, and serve other consumers, but titles, visible copy, links, and consistent entities do the real explanatory work.
alternates: {
canonical: `/${locale}${path}`,
languages: {
en: `/en${path}`,
zh: `/zh${path}`,
'x-default': `/en${path}`,
},
}Crawling and indexing: give every mechanism one job
A sitemap is a discovery inventory, not an indexing guarantee. Robots.txt controls crawling, not deletion or canonicalization. Noindex controls index eligibility. A 404 or 410 says a resource is gone. A 301 or 308 performs a permanent move. Mixing these controls creates URLs that remain visible without content or old pages that never consolidate.
The current sitemap merges hubs, site pages, blog records, and tool registry routes, emitting absolute English and Chinese URLs, language alternates, and article modification dates. Robots.txt permits public pages, excludes API paths, and advertises the sitemap. The custom not-found page returns a real 404 with noindex,follow while still helping visitors continue to registry-derived tools.
| Mechanism | Correct responsibility | Does not replace |
|---|---|---|
| sitemap.xml | List canonical URLs and meaningful modification dates | Indexing or ranking guarantees |
| robots.txt | Control crawler requests to path groups | Removal or canonicalization |
| noindex | Request exclusion after a crawler reads the page | Consolidating duplicate signals |
| 404/410 | Declare that a resource is missing or removed | A migration with a relevant replacement |
| 301/308 | Permanently move an old URL to its closest replacement | Redirecting every dead page to the home page |
- Include only accessible, indexable, 200-status preferred URLs in the sitemap.
- After release, compare status, canonical, hreflang, internal links, and sitemap URLs exactly.
- When removing a page, choose redirect, 410, or 503 based on whether a replacement exists and whether the condition is permanent.
Structured data must describe visible content
ToolGarden uses Organization, WebSite, and WebApplication at the site level; ItemList on hubs; WebApplication and BreadcrumbList on tools; and BlogPosting plus BreadcrumbList on articles. Visible FAQs can also produce FAQPage data. Names, URLs, descriptions, and dates come from the same records used to render the page.
Structured data reduces ambiguity and may establish eligibility for an applicable search presentation. It is not a universal ranking button or special generative-search markup. Every field must match the primary visible content; invented ratings, prices, authors, or features do not become true because they appear in JSON-LD.
Google stopped showing FAQ rich results in May 2026. Visible FAQs can still help visitors, site search, and other consumers, but they should no longer be created for a Google FAQ presentation or mass-produced on every page.
| Page type | Suitable schema | Fields that must agree |
|---|---|---|
| Site home | Organization, WebSite, WebApplication | Brand, URL, logo, languages, and real product |
| Tool hub | CollectionPage or ItemList | Visible card order, names, and links |
| Individual tool | WebApplication, BreadcrumbList | Features, price, operating system, and breadcrumbs |
| Blog article | BlogPosting, BreadcrumbList | Headline, author, publication date, and modification date |
| Visible Q&A | FAQPage for other consumers | Questions and answers shown on the page |
Content SEO: publish evidence competitors cannot cheaply copy
The most defensible content in 2026 is not a paraphrase of public documentation. It contributes evidence that is difficult to reproduce without doing the work: implementation code, browser compatibility, performance boundaries, failed fixtures, test files, conversion losses, and security constraints.
Existing ToolGarden articles start with real features: FFmpeg.wasm virtual file handling, browser Whisper inference, Open XML document merging, and PDF text-layer recovery. These subjects combine real demand, product relevance, and first-hand engineering knowledge more effectively than mass-produced lists of the ten best tools.
- Use a pillar to map the subject, clusters to answer one deep question, and tools to complete the task.
- Give every new article an original example, benchmark, comparison, failure analysis, or reproducible verification.
- Review similar pages for consolidation before publishing another title with nearly the same answer.
- Keep the real publication date and change updatedAt only after a substantial revision.
- Use author, About, privacy, and security pages to explain who maintains the content and how user data is handled.
AEO and GEO: make answers citable without chasing hacks
Answer-friendly and generative-search-friendly pages tend to make their conclusion easy to find. State the core answer early, then support it with definitions, conditions, data, examples, and sources. Do not bury the useful answer after hundreds of words of generic scene-setting.
Entity names, capabilities, localized routes, visible copy, metadata, structured data, and internal links should agree. Helpful headings, tables, and steps improve readability, but Google says there is no need to split content into tiny AI chunks or publish a page for every long-tail query variation.
The project generates llms.txt and llms-full.txt from its registries for other systems that choose to consume them and as a build-time consistency artifact. Google’s 2026 guidance explicitly says Google Search does not use llms.txt; it neither helps nor harms Google visibility and should never be reported as a GEO ranking win.
- Put a self-contained direct answer near the beginning.
- State scope, limitations, and exceptions instead of giving an absolute claim without conditions.
- Cite primary standards and first-party evidence, separating fact, experience, and inference.
- Use FAQs to answer real user problems, not to manufacture schema at scale.
- Measure real citations, entrances, and completed tasks rather than opaque AI visibility scores.
Performance and ads: optimize real experience
The current Core Web Vitals are LCP, INP, and CLS. Recommended targets at the 75th percentile, separately for mobile and desktop, remain LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Lab tests prevent regressions; field data represents the experience people actually receive.
ToolGarden uses static export to reduce document startup cost, long-lived caching for hashed assets, and on-demand loading for models, workers, editors, and media runtimes. Analytics and AdSense scripts load asynchronously, but async third-party code still consumes network and main-thread resources and must be measured.
Reserve stable dimensions for ad placements so late ad rendering does not push the article down and create CLS. Ads must not cover the primary input or action, especially when a mobile viewport already has limited space.
| Metric | 2026 target | Typical utility-site optimization |
|---|---|---|
| LCP | ≤ 2.5 s | Static HTML, critical styles, delayed editors and models |
| INP | ≤ 200 ms | Workers, cancellation, and less JSON/media work on the main thread |
| CLS | ≤ 0.1 | Reserved image and ad space, stable fonts and panels |
| Resource cost | Bounded per task | Cached WASM/worker/model assets and released Blob URLs |
Close the measurement loop from indexing to citations
SEO does not end when the build passes. Google Search Console covers indexing, sitemaps, queries, page experience, and generative search reporting. Bing Webmaster Tools introduced AI Performance in 2026 to expose citations across Copilot, Bing AI summaries, and selected partner experiences. Baidu Webmaster tools remain relevant for proactive submission and crawl diagnosis of Chinese URLs.
The project already contains Google Analytics configuration, Baidu verification, and a Baidu URL submission script. Depending on production traffic, the next step is to connect Search Console, Bing Webmaster Tools, and IndexNow to publish, update, and delete events instead of blindly resubmitting every URL on a schedule.
| Cadence | Review | Question to answer |
|---|---|---|
| Every release | Status, canonical, hreflang, JSON-LD, sitemap | Can the new page be discovered and interpreted correctly? |
| Weekly | Coverage, crawl errors, queries, and 404s | Is a technical defect blocking growth? |
| Monthly | CTR, landing pages, CWV, citations, and conversions | Which content produces useful completed tasks? |
| Quarterly | Overlap, stale content, internal links, and topic gaps | Should a page be updated, merged, removed, or expanded? |
2026 SEO release checklist
This checklist belongs in CI, a pull request template, or the publishing workflow. It tests observable output instead of an opaque SEO score.
- Return the correct 200, 3xx, 404, or 410 status and avoid soft 404s.
- Make title, description, H1, and visible copy describe one primary intent.
- Use a self-referencing canonical that exactly matches sitemap and internal-link URLs.
- Emit reciprocal English and Chinese hreflang plus an intentional x-default.
- Keep robots rules from blocking indexable pages and rendering resources.
- Match structured data to visible content and validate its syntax.
- Give every new page at least one crawlable link from a hub, related article, or navigation surface.
- Add an original example, test, comparison, or primary source instead of only summarizing public material.
- Set explicit image dimensions and reserve ad space.
- Load models, WASM, editors, and media libraries only when the task needs them.
- Complete one real mobile workflow, including input, action, download, and error states.
- After building, inspect sitemap, robots, llms files, and static HTML.
- After release, check indexing and crawling in webmaster tools and record a performance baseline.
Key takeaways
Effective SEO in 2026 is not a larger pile of tags. It is agreement between the product, content, and every discovery signal. ToolGarden’s central method is to treat registries and localized messages as facts, derive metadata, canonical, hreflang, sitemaps, structured data, and article relationships from them, and protect the user experience with static output, on-demand code, and production measurement. AEO and GEO may change where an answer appears, but they cannot replace crawlable pages, original evidence, clear intent, and sustained maintenance.