Cómo encajan las rutas de idioma, canonical, hreflang, sitemap y el contenido de respaldo de Toolso, a partir de una revisión del código y una pequeña muestra de páginas del 26 de octubre de 2026.
Un directorio de herramientas de IA tiene dos funciones relacionadas: ayudar a las personas a descubrir software útil y dar a cada ficha una identidad estable. Añadir idiomas amplía ambas funciones. Una interfaz traducida puede parecer completa mientras las páginas que hay detrás siguen discrepando sobre qué URL representa un elemento, si existe una traducción o qué versión debe tener en cuenta un buscador.
Toolso es una plataforma multilingüe para descubrir y lanzar herramientas de IA. Este recorrido explica cómo encajan las rutas de idioma, las URL canonical, las anotaciones de idiomas alternativos y las entradas del sitemap de Toolso, a partir de una revisión del código fuente y una pequeña comprobación de páginas publicadas realizada el 26 de octubre de 2026. No mide mejoras de posicionamiento ni da por hecho que cada ficha tenga contenido en todos los idiomas configurados.
Un buen punto de partida es una pregunta sencilla: cuando una misma herramienta aparece en varios idiomas, ¿pueden todas las partes de la aplicación describir esas versiones de forma coherente? Esa pregunta conecta la gestión del contenido con el SEO técnico. Una traducción es más que otra opción de menú: necesita un contenido, una ruta y unos metadatos que concuerden.
Figura 1. La página de inicio en inglés. Captura facilitada el 26 de octubre de 2026.
La configuración define actualmente diez locales: inglés, chino simplificado, chino tradicional, coreano, japonés, francés, alemán, ruso, español y portugués. El inglés es el idioma predeterminado. La configuración de enrutamiento utiliza prefijos de idioma cuando son necesarios, por lo que el idioma predeterminado no requiere un prefijo /en, mientras que los demás locales sí utilizan un prefijo.
Como ejemplo real, la ficha de Raphael AI utiliza /tool/raphael en inglés y /zh/tool/raphael en chino simplificado. Comprobamos ambas páginas el 26 de octubre de 2026. Sus URL canonical renderizadas apuntaban a sus respectivas versiones lingüísticas.
Las claves internas de enrutamiento están separadas de los identificadores de idioma que se comunican a los buscadores. En la configuración actual, zh se corresponde con zh-CN, tw con zh-TW, es con es-ES y pt con pt-BR. Una clave interna corta resulta práctica para el enrutamiento, pero no debería convertirse sin más en una anotación de idioma con un significado distinto.
El enrutador también desactiva la detección automática del locale. Así, el idioma codificado en la ruta solicitada queda explícito. Eso no demuestra que la localización esté terminada: la navegación traducida, el contenido traducido de las fichas y los metadatos correctos siguen siendo comprobaciones independientes.
Figura 2. La ficha de Raphael AI en Toolso. Captura facilitada el 26 de octubre de 2026; muestra la interfaz, pero no verifica las anotaciones de idioma de la página.
Las pequeñas diferencias entre URL pueden extenderse cuando los metadatos de las páginas y la generación del sitemap construyen las direcciones por separado. Un componente puede omitir el locale predeterminado mientras otro lo añade. Uno puede conservar una barra al final de la raíz del dominio mientras otro la elimina. Cada componente puede parecer razonable de forma aislada y, aun así, el resultado conjunto puede ser incoherente.
Los auxiliares de canonical, hreflang y sitemap de Toolso comparten un constructor de URL absolutas. Este delega la generación de las rutas localizadas en la misma lógica de enrutamiento y aplica una única regla de normalización de la ruta raíz. En esta implementación, la URL de la página de inicio predeterminada se normaliza sin barra final. Esa es nuestra convención de coherencia, no una afirmación de que todos los sitios web deban elegir esa forma.
El auxiliar de metadatos también admite un valor de consulta para las URL paginadas. Cuando se proporciona esa opción, se añade la misma consulta a la URL canonical y a las alternativas de idioma. Esto permite a quienes lo invocan mantener la página dos asociada a la página dos de otros idiomas, en lugar de conectarla por error con la página uno. Aun así, hay que inspeccionar cada punto de llamada: la capacidad de un auxiliar no demuestra que todas las rutas lo utilicen correctamente.
Las anotaciones canonical comunican una URL preferida. No garantizan que sea la URL que seleccione Google. Esta distinción se explica en la guía de Google sobre canonicalización.
Admitir diez locales en la aplicación no significa que todas las herramientas tengan diez descripciones terminadas. Tratar ambos hechos como equivalentes crearía anotaciones de idioma que prometen más de lo que ofrece el contenido.
Nuestro auxiliar de enlaces de idioma acepta un conjunto de locales disponibles. Cuando quien lo invoca lo proporciona, el auxiliar solo genera alternativas para esos locales. Incluye una alternativa x-default que apunta a la versión del idioma predeterminado únicamente cuando esa versión pertenece al conjunto disponible. Omitir el conjunto declara todos los locales configurados, por lo que transmitir con precisión la disponibilidad del contenido es una responsabilidad importante en cada punto de llamada.
La configuración de enrutamiento desactiva la salida automática de idiomas alternativos mediante HTTP Link de next-intl. En su lugar, la implementación genera anotaciones con los identificadores de idioma correspondientes mediante los metadatos de las páginas y los auxiliares del sitemap. Esto evita mantener otro conjunto generado automáticamente a partir de las claves de enrutamiento sin transformar, además de la correspondencia explícita de idiomas.
Es necesario comprobar el resultado después del despliegue. En nuestra muestra de Raphael, las páginas en inglés y chino simplificado declaraban las mismas diez alternativas de idioma más x-default, incluido un enlace de vuelta a la otra página. Esto verifica las anotaciones renderizadas de esa muestra, no la calidad de la traducción ni la indexación en buscadores. La documentación de Google sobre páginas localizadas explica los códigos de idioma, los enlaces recíprocos y la función de x-default como alternativa predeterminada.
Un generador de sitemap puede producir fácilmente todas las URL de idioma posibles. Un inventario más útil refleja qué contenido cumple realmente los requisitos para aparecer.
La consulta de datos de herramientas del generador de sitemap de Toolso selecciona las herramientas publicadas. Por separado, crea el conjunto de traducciones disponibles a partir de registros con un nombre utilizable y contenido descriptivo válido. Esos registros de traducción se leen en lotes mediante cursores, y el generador conserva la información de locale necesaria para construir las URL, en lugar de acumular todas las descripciones en memoria.
Después, las entradas de las páginas de detalle de herramientas se generan únicamente para los locales disponibles. Las entradas de detalle del blog se filtran de forma similar según el conjunto de locales de cada publicación. Ambas utilizan los auxiliares de URL compartidos para las ubicaciones del sitemap y las alternativas de idioma. Por tanto, un espacio para un idioma en la base de datos no basta, por sí solo, para crear una entrada de página de detalle.
Las fechas de modificación también requieren atención. Las entradas de detalle de herramientas utilizan el campo seoUpdatedAt, orientado al contenido, y las entradas del blog utilizan la fecha correspondiente de actualización del contenido o de publicación. La intención es reflejar cambios relevantes en el contenido, en lugar de hacer que cada actualización del contador de visitas parezca una nueva revisión editorial.
Esto no demuestra que todas las entradas generadas funcionen correctamente en producción en este momento. El propio envío del sitemap es solo una indicación; la guía de Google sobre sitemaps no promete el rastreo ni la indexación.
Las traducciones ausentes necesitan una política. De lo contrario, la misma descripción en el idioma original puede aparecer bajo muchas URL de idioma mientras el sitio las presenta como traducciones terminadas.
Los metadatos de detalle de las herramientas contienen una rama explícita para las traducciones de respaldo. Cuando se sirve contenido de respaldo, se marca la página con noindex, se dirige la URL canonical a la versión inglesa de la herramienta y se desactiva el grupo de idiomas alternativos para esa respuesta. Los datos de traducción que no están disponibles temporalmente o que faltan tienen un tratamiento independiente; no deben describirse como una página traducida correctamente.
La implementación del detalle del blog sigue una política relacionada: el contenido de respaldo apunta al idioma original de la publicación, desactiva las alternativas de idioma y utiliza noindex. El contenido archivado del blog también se marca con noindex. Son decisiones editoriales y técnicas específicas del proyecto, no una recomendación de aplicar una regla idéntica a todos los sitios web multilingües.
La distinción práctica está entre una interfaz traducida y un contenido traducido. Un visitante puede seguir necesitando acceso a una versión de respaldo, pero los metadatos para buscadores no deberían presentarla como una edición lingüística independiente y terminada. El filtro de disponibilidad de contenido del sitemap debe seguir alineado con el comportamiento de la página de detalle.
Leer un auxiliar resulta útil, pero lo que reciben los visitantes y los rastreadores es la respuesta final. El middleware, la caché, la disponibilidad de los datos y la versión desplegada pueden cambiar el resultado. Por eso, una revisión del código no puede sustituir la comprobación de la respuesta.
El repositorio incluye un script de auditoría del sitemap que permite comprobar el estado de las respuestas, las directivas robots, las URL canonical y, opcionalmente, las relaciones entre idiomas. Revisamos el script e inspeccionamos los metadatos renderizados de las dos páginas de Raphael y sus entradas en el sitemap. Esas entradas utilizaban las mismas URL canonical y alternativas de idioma que las páginas de la muestra. No ejecutamos la auditoría completa de producción ni consultamos Search Console.
Las tres capturas muestran la página de inicio, la ficha de Raphael AI y la pantalla de entrada para enviar una herramienta. Documentan la interfaz en el momento de la captura. Para repetir la comprobación técnica, compara la URL canonical y los enlaces de idioma renderizados de una ficha en dos idiomas disponibles y, después, contrasta esas URL con el sitemap. Registra la URL y la fecha. Prueba por separado el comportamiento cuando falta una traducción: una traducción terminada y un contenido de respaldo necesitan condiciones de comprobación distintas.
Las observaciones de Search Console deben ir en un registro aparte: qué rastreó Google, qué canonical seleccionó y qué está indexado. Las cifras de analítica y conversiones deben ir en otro. Mantener separados estos registros evita que una comprobación local de la implementación acabe contándose como un resultado de búsquedas o de ingresos.
La idea más reutilizable es dejar que la disponibilidad del contenido determine las declaraciones de URL. Mantén las claves de enrutamiento separadas de los códigos de idioma, comparte la construcción de URL entre los metadatos y la generación del sitemap, y da un estado explícito a las traducciones ausentes. Después, compara esas intenciones con las respuestas reales antes de hacer afirmaciones sobre el rendimiento en buscadores.
Para un equipo pequeño, esto también es una disciplina operativa. Un idioma nuevo debería incorporarse al flujo editorial con un estado de contenido conocido y un paso de verificación. Una muestra pequeña puede revelar discrepancias, pero no permite demostrar la cobertura de todo el directorio. Vuelve a comprobar el grupo de URL cuando cambien las reglas de enrutamiento o la disponibilidad de las traducciones.
Figura 3. El flujo de envío después de importar la URL de una herramienta, con los recursos multimedia completados. Captura facilitada el 26 de octubre de 2026; no muestra un envío finalizado. Los precios y contadores son detalles de la interfaz en ese momento.
Si estás creando un directorio multilingüe, puedes explorar Toolso con estas preguntas en mente: ¿contiene cada página de idioma información útil y describen sus señales de URL ese contenido con precisión?
Producir vídeo con IA en 2026: elegir modelo por plano, promptear el movimiento, keyframes, costes reales, corregir artefactos y migrar desde Sora.
Tres plataformas, tres formas: Zapier el más fácil, Make el de mejor precio, n8n el único autoalojable. El coste lo decide el modelo de facturación.
Prompt engineering en 2026: por qué los prompts breves puntúan un 10–15 % más, qué volvieron obsoleto los modos de razonamiento y cinco patrones.
El método de 2026 para programar con Claude: CLAUDE.md ligero, plan primero, subagentes, worktrees en paralelo, hooks y bucles de verificación.
Copilot en 2026 en la práctica: configurar Agent Mode, políticas de aprobación automática, revisión agéntica, disciplina de costes y hábitos que rinden.
La guía actual de Midjourney: estructura del prompt, parámetros clave, entrenamiento de personalización, la trampa 4× de GPU, modo vídeo y un ciclo útil.
El tutorial completo de V7 — parámetros, patrones de prompt y flujos de trabajo de la generación 2025, con una tabla completa de migración a V8.2.
Guía práctica de Notion AI: configurar Custom Agents programados, escribir Skills, gestionar créditos y la higiene del espacio de trabajo.
