How Toolso structures multilingual URLs, canonical tags, hreflang, sitemaps, and translation fallbacks, with checks for directory builders.
An AI tools directory has two related jobs: help people discover useful software, and give each listing a stable identity. Adding languages expands both jobs. A translated interface can look complete while its underlying pages still disagree about which URL represents an item, whether a translation exists, or which version a search engine should consider.
Toolso is a multilingual AI tools discovery and launch platform. This walkthrough explains how Toolso's language routes, canonical URLs, alternate-language annotations, and sitemap entries fit together, based on a source review and a small live-page check on October 26, 2026. It does not measure ranking improvements or assume that every listing has content in every configured language.
The useful starting point is a simple question: when the same tool appears in several languages, can every part of the application describe those versions consistently? That question connects content operations with technical SEO. A translation is more than another menu option; it needs content, a route, and metadata that agree.
Figure 1. The English homepage. Screenshot supplied on October 26, 2026.
The configuration currently defines ten locales: English, Simplified Chinese, Traditional Chinese, Korean, Japanese, French, German, Russian, Spanish, and Portuguese. English is the default. The routing configuration uses language prefixes as needed, so the default language does not require an /en prefix, while other locales use a prefix.
For a real example, the Raphael AI listing uses /tool/raphael in English and /zh/tool/raphael in Simplified Chinese. We checked both pages on October 26, 2026. Their rendered canonical URLs pointed to their respective language versions.
The internal routing keys are separate from the language identifiers exposed to search engines. In the current configuration, zh maps to zh-CN, tw to zh-TW, es to es-ES, and pt to pt-BR. A short internal key is convenient for routing, but it should not silently become a language annotation with a different meaning.
The router also disables automatic locale detection. That makes the language encoded in a requested path explicit. It does not establish that localization is finished: translated navigation, translated listing content, and correct metadata remain separate checks.
Figure 2. Raphael AI's Toolso listing. Screenshot supplied on October 26, 2026; it illustrates the interface, not the page's language annotations.
Small URL differences can spread when page metadata and sitemap generation construct addresses independently. One component might hide the default locale while another adds it. One might preserve a slash at the domain root while another removes it. Each component can appear reasonable in isolation while the combined output becomes inconsistent.
Toolso's canonical, hreflang, and sitemap helpers share an absolute URL constructor. It delegates localized path generation to the same routing logic and applies one root-path normalization rule. In this implementation, the default homepage URL is normalized without a trailing slash. That is our consistency convention, not a claim that every website must choose that spelling.
The metadata helper also supports a query value for paginated URLs. When that option is supplied, the same query is added to the canonical and language alternatives. This gives callers a way to keep page two associated with page two in other languages, rather than accidentally connecting it to page one. Each caller still needs inspection; a helper's capability does not prove every route uses it correctly.
Canonical annotations communicate a preferred URL. They do not guarantee the URL Google selects. That distinction is explained in Google's canonicalization guidance.
Supporting ten locales at the application level does not mean every tool has ten completed descriptions. Treating those facts as equivalent would create language annotations that promise more than the content delivers.
Our language-link helper accepts an available-locale set. When the caller supplies it, the helper only generates alternatives for those locales. It includes an x-default alternative pointing to the default-language version only when that version belongs to the available set. Omitting the set declares all configured locales, so passing accurate content availability is an important responsibility at the call site.
The routing configuration disables next-intl's automatic alternate-language HTTP Link output. The implementation instead generates mapped language annotations through page metadata and sitemap helpers. This avoids maintaining another automatically generated set based on raw routing keys alongside the explicit language mapping.
The result needs checking after deployment. In our Raphael sample, the English and Simplified Chinese pages each declared the same ten language alternatives plus x-default, including a link back to the other page. This verifies that sample's rendered annotations, not translation quality or search indexing. Google's localized-page documentation explains language codes, return links, and the fallback role of x-default.
A sitemap generator can easily produce every possible language URL. A more useful inventory reflects which content is actually eligible to appear.
The tool-data query in Toolso's sitemap generator selects published tools. It separately builds the set of available translations from records with a usable name and valid descriptive content. Those translation records are read in cursor-based batches, and the generator retains the locale information needed for URL assembly rather than accumulating every description in memory.
Tool detail entries are then generated only for the available locales. Blog detail entries are similarly filtered by each post's locale set. Both use the shared URL helpers for sitemap locations and language alternatives. A language slot in the database is therefore not, on its own, enough to create a detail-page entry.
Modification dates also deserve care. Tool detail entries use the content-oriented seoUpdatedAt field, and blog entries use the corresponding content update or publication date. The intent is to describe meaningful content changes rather than make every view-count update look like a new editorial revision.
This does not establish that every generated entry is currently healthy in production. Sitemap submission itself is only a hint; Google's sitemap guidance does not promise crawling or indexing.
Missing translations need a policy. Otherwise, the same original-language description can appear under many language URLs while the site presents them as completed translations.
The tool detail metadata contains an explicit translation-fallback branch. When it serves fallback content, it marks the page noindex, points the canonical to the English tool version, and disables the alternate-language cluster for that response. Translation data that is temporarily unavailable or missing has separate handling; it should not be described as a successfully translated page.
The blog detail implementation follows a related policy: a fallback points to the post's original language, disables language alternatives, and uses noindex. Archived blog content is also marked noindex. These are project-specific editorial and technical decisions, not a recommendation to apply one identical rule to every multilingual website.
The practical distinction is between a translated interface and translated content. A visitor may still need access to a fallback, but search metadata should not present that fallback as an independent, completed language edition. The sitemap's content-availability filter needs to remain aligned with the detail-page behavior.
Reading a helper is useful, but the final response is what visitors and crawlers receive. Middleware, caching, data availability, and the deployed version can change the outcome. A code review therefore cannot replace a response check.
The repository includes a sitemap audit script that can check response status, robots directives, canonical URLs, and, optionally, language relationships. We reviewed the script and inspected the rendered metadata of the two Raphael pages and their sitemap entries. Those entries used the same canonical URLs and language alternatives as the sampled pages. We did not run the full production audit or inspect Search Console.
The three screenshots show the homepage, the Raphael AI listing, and the submission entry screen. They document the interface at capture time. To repeat the technical check, compare a listing's rendered canonical and language links across two available languages, then compare those URLs with the sitemap. Record the URL and date. Test missing-translation behavior separately: a completed translation and a fallback need different assertions.
Search Console observations belong in a separate record: what Google crawled, which canonical it selected, and what is indexed. Analytics and conversion figures belong in another. Keeping these records separate prevents a local implementation check from being retold as a search or revenue result.
The most reusable idea is to let content availability drive URL declarations. Keep routing keys distinct from language codes, share URL construction across metadata and sitemap generation, and give missing translations an explicit state. Then compare those intentions with real responses before making claims about search performance.
For a small team, this is also an operational discipline. A new language should enter the editorial workflow with a known content state and a verification step. A small sample can reveal disagreements, but it cannot establish coverage across the entire directory. Recheck the URL cluster when routing rules or translation availability change.
Figure 3. The submission workflow after a tool URL import, with media assets filled in. Screenshot supplied on October 26, 2026; it does not show a completed submission. Prices and counters in these screenshots are dated interface details.
If you are building a multilingual directory, you can explore Toolso with these questions in mind: does each language page contain useful content, and do its URL signals describe that content accurately?
How to produce AI video in 2026: picking a model per shot, prompting for motion, keyframe workflows, real cost math, artifact fixes and Sora migration.
The 2026 automation guide: how Zapier, Make and n8n differ on pricing model, AI agents and self-hosting — plus when a workspace agent beats all three.
Prompt engineering for 2026: why leaner prompts score 10–15% higher, what reasoning modes made obsolete, the five patterns that survived, and agent specs.
The 2026 playbook for coding with Claude: lean CLAUDE.md, plan-first workflows, subagents, parallel worktrees, hooks, and verification loops that work.
A working guide to Copilot in 2026: Agent Mode setup, auto-approve policy, agentic review, cost discipline, and the habits that make agents net-positive.
The current Midjourney guide: prompt structure, every parameter that matters, personalization training, the 4× GPU trap, video mode, and a working loop.
The complete V7 tutorial — parameters, prompting patterns and workflows from Midjourney's 2025 generation — with a full migration map to today's V8.2.
A practical guide to Notion AI: setting up Custom Agents on schedules, writing Skills, managing credits, and the workspace hygiene that makes it work.
