Cómo detectamos y retiramos variantes SEO huérfanas

El 27 de julio de 2026 retiramos las variantes de intención de las URLs de herramientas de PriviTools. La decisión no respondió a una penalización ni a una alerta de Google: respondió a una auditoría de nuestra implementación estática.

La primera versión de esta historia incluía una cifra agregada que no podía reconciliarse con todas las tablas del build. La retiramos. Un post-mortem útil debe permitir que otra persona compruebe sus premisas; si una cifra no se puede reconstruir a partir del commit y del artefacto de build, no merece estar en el titular.

Lo que sí pudimos verificar en el código histórico es el problema de diseño: cada página base tenía cuatro variantes de URL para «gratis», «rápido», «Mac» y «Windows». Es decir, cada herramienta se construía cinco veces. La versión actual conserva esos argumentos como secciones de una página canónica, en lugar de convertirlos en URLs separadas.

La idea: una URL por cada matiz de búsqueda

La intuición era sencilla. Una persona puede buscar «comprimir PDF», «comprimir PDF gratis» o «comprimir PDF para Mac». Creamos una ruta para cada formulación:

/es/herramientas/comprimir-pdf/
/es/herramientas/comprimir-pdf-gratis/
/es/herramientas/comprimir-pdf-rapido/
/es/herramientas/comprimir-pdf-mac/
/es/herramientas/comprimir-pdf-windows/

El generador recorría las herramientas disponibles por idioma y les aplicaba los cinco modificadores. Las variantes recibían copy adicional para evitar que fueran copias exactas, pero su tarea y su resultado eran los mismos que los de la página base.

Para evitar competir con la base, las cuatro variantes emitían una canónica hacia ella. Esa decisión ya era una señal de que no eran documentos independientes: si la URL necesita decirle a los buscadores que otra URL representa el contenido principal, hay que cuestionar por qué existe como página separada.

Lo que encontró la auditoría

Auditamos el generador, el sitemap y los enlaces del sitio construido. Encontramos tres hechos que justificaban consolidar las variantes:

1. No tenían enlaces internos contextuales. La navegación, las categorías y las páginas de herramientas apuntaban a la URL base, no a las variantes.
2. No se declaraban en el sitemap. El generador excluía las rutas canonicalizadas para no presentar duplicados como páginas prioritarias.
3. Su canónica apuntaba a otra URL. Incluso cuando un robot llegara a una variante por una fuente externa, la propia página proponía a la base como representante.

No es correcto afirmar que un buscador nunca pueda descubrir una URL sin esos dos primeros caminos: puede conocerla por un enlace externo, una URL histórica u otras señales. Sí es correcto decir que el producto no le ofrecía una vía interna, sistemática y consistente para descubrirla. Google explica que el enlazado interno exhaustivo y el sitemap ayudan a descubrir páginas, sin garantizar que todas se rastreen o indexen. Consulta la documentación sobre sitemaps.

Por qué una canónica no arregla la arquitectura

Una etiqueta canónica es una preferencia para consolidar señales; no convierte cinco intenciones ligeras en cinco documentos con valor independiente. Aquí tenía sentido una sola página que respondiera a las preguntas de precio, velocidad y compatibilidad, con una experiencia coherente y una única URL que enlazar, medir y mantener.

También evitamos normalizar el patrón de crear rutas casi idénticas sólo para repetir una keyword. Google considera problemáticas las páginas creadas para dirigir búsquedas similares al mismo destino cuando no aportan valor propio. Sus políticas sobre spam describen este patrón.

El cambio: contenido consolidado, no contenido borrado

No eliminamos las explicaciones sobre compatibilidad, gratuidad o procesamiento local. Las convertimos en bloques editoriales dentro de cada página base. Así una persona que busca una herramienta encuentra la misma información sin atravesar una ruta paralela.

La regla quedó expresada en código y cubierta por una prueba: getSeoPaths genera una sola URL por herramienta e idioma. Si alguien vuelve a añadir un modificador al slug, el test falla. Ese detalle importa más que una declaración de intenciones en una reunión: convierte la decisión en una propiedad verificable del proyecto.

Cómo repetir la auditoría

Para revisar una arquitectura de SEO programático no basta con mirar una página en el navegador. Recomendamos revisar el artefacto estático y responder estas preguntas:

• ¿Cada URL importante aparece en el sitemap o tiene enlaces internos suficientes?
• ¿El contenido justifica una canónica propia?
• ¿Las diferencias entre rutas son sustantivas o sólo cambian un modificador?
• ¿Cuántas rutas, pruebas y cambios de plantilla se multiplican por cada nueva variante?
• ¿Existe una prueba que impida recrear el mismo patrón?

Si la respuesta sugiere que las rutas compiten entre sí, la consolidación suele ser más honesta y más mantenible que añadir más copy a cada URL. Puedes ver las herramientas de PriviTools como ejemplo de páginas base que reúnen las intenciones relacionadas en un solo documento.

Lo que mediremos a partir de ahora

Este artículo queda actualizado el 28 de julio de 2026. Publicaremos cambios sólo cuando haya datos comparables: cobertura e indexación en Search Console, impresiones, clics y cualquier cambio de rastreo observado. No anticiparemos resultados a 7, 14 o 30 días ni los presentaremos como evidencia antes de que existan.