How T1000 Routes 230+ Tool Subdomains with Next.js SSG

T1000 is designed around single-purpose utilities that people open directly from search results, documentation, chat answers, newsletters, and bookmark bars. A tool such as word-counter.t1000.us or json-formatter.t1000.us is easier to remember and cite than a long multi-purpose application path.

The subdomain is the canonical tool URL. Root-domain pages still exist for categories, campaigns, alternatives, trust copy, and this engineering write-up, but individual utility intent resolves to the dedicated subdomain.

Tool routes are statically generated from the registry. The route for tools exports generateStaticParams so the production build knows every slug before deployment.

export function generateStaticParams() {
  return ALL_TOOLS.map((tool) => ({ slug: tool.slug }));
}

That pattern keeps the public surface predictable: if a tool exists in the registry, it can receive a generated route, metadata, structured data, and sitemap entry without a hand-authored page per tool.

The subdomain layer rewrites requests from a host such as json-formatter.t1000.us to the shared tool route for the matching slug. This keeps the implementation centralized while the user-facing URL stays focused on one tool.

T1000 still treats the canonical resource as the absolute tool subdomain. Internal code should use the toolUrl() helper for tool links instead of guessing hostnames inline.

The registry is the source of truth for slugs, names, descriptions, categories, keywords, implementation status, and visual accents. It lets the homepage, category pages, sitemap, structured data, and tool route agree on the same canonical facts.

This reduces drift. Adding or editing a tool is not just a UI task; it updates the data that powers search surfaces, AI answer context, and shareable subdomain links.

Every indexable page should answer three questions clearly: what is this page, what is its canonical URL, and how does it relate to the rest of the site? T1000 encodes those answers through page metadata, canonical links, Open Graph URLs, JSON-LD, and sitemap records.

For root-domain pages like this article, canonical resources use absolute root-domain URLs such as https://t1000.us/engineering/subdomain-tool-architecture. For tools, canonical resources use absolute subdomain URLs generated by toolUrl().

T1000 includes GA4 aggregate analytics so the site can understand high-level usage patterns, route performance, and useful-action events. The goal is product quality measurement: which tools people open, which flows produce useful actions, and where pages need clearer copy.

Analytics should not become a reason to overcollect. The privacy posture is intentionally scoped: T1000 does not store tool input on its servers, and the product copy should avoid blanket claims that every character of input always remains in the browser in every tool.

Most tools process input locally in the browser. That is the correct general framing for the product, but precision matters for user trust and technical SEO. Some workflows can involve browser requests to third-party services when a specific tool needs that capability.

The important known example is the QR Code Generator, which uses api.qrserver.com from the browser to render QR images. That caveat is why T1000 copy should say “most tools process input locally” and “T1000 does not store tool input on its servers,” not “100% private” or “all input never leaves the browser.”

Subdomain routing changes the cost of casual relative links. A root-relative link such as /privacy can resolve against the current tool subdomain if rendered from a tool page. That may send users and crawlers to a noncanonical host.

The safer rule is simple: shared surfaces that can appear from tool pages should use absolute BASE_URL links for root-domain resources and toolUrl() for tool resources.

• GA4 aggregate analytics is present in the root layout.
• The QR Code Generator uses api.qrserver.com from the browser.
• Not every tool should claim all input never leaves the browser.
• Next.js warns that the middleware convention is deprecated in favor of proxy naming, so future framework upgrades should revisit that file without changing routing behavior casually.