Thin content: cómo decidir qué mejorar, unir o retirar

Un texto de doscientas palabras puede resolver una duda. Uno de dos mil puede dejarla intacta. El problema del thin content no se arregla engordando el contador.

Se arregla entendiendo para qué existe una página, qué necesita quien llega a ella y qué aporta frente a las alternativas. Después se decide si merece una mejora, una unión con otro contenido o una retirada. En ese orden, no con la papelera abierta desde el principio.

¿Qué es el thin content y por qué no se mide en palabras?

Thin content es una expresión habitual en SEO para hablar de contenido que aporta poco valor a quien lo consulta. La palabra "thin" invita a pensar en algo escaso. El salto peligroso es convertir "escaso" en "menos de tantas palabras".

Google no establece una longitud preferida. En su guía para crear contenido útil y pensado para las personas pide evaluar si la página permite alcanzar el objetivo del lector y si aporta información, análisis o trabajo propio. También pregunta si el contenido deja a la persona con la necesidad de volver a buscar una respuesta mejor.

Esa es una comprobación bastante más útil que contar párrafos. Una página de horarios puede cumplir su función con muy poco texto. Una guía que promete explicar un trámite y no cuenta los requisitos, los pasos o dónde hacerlo puede quedarse corta aunque ocupe varias pantallas.

Tampoco conviene usar "thin content" como diagnóstico automático de penalización. Las políticas de spam de Google describen prácticas concretas, como producir muchas páginas para manipular posiciones sin ayudar a los usuarios o publicar afiliación sin valor añadido. Una página mejorable no demuestra, por sí sola, que el sitio incurra en esas prácticas.

¿Cómo distinguir una página breve de una página que aporta poco?

La diferencia está en la tarea. Antes de juzgar la cantidad de contenido, hay que poder completar esta frase: "Esta página existe para que una persona pueda...".

Consultar un horario, comparar dos servicios y aprender a configurar una herramienta son tareas distintas. No necesitan la misma extensión ni las mismas pruebas.

Pongo un ejemplo ficticio. La página de un taller explica qué bicicletas repara, dónde está, cuándo abre y cómo pedir cita. Puede ser breve y resolver bien la visita. Otra página del mismo taller habla durante mil palabras de lo importante que es cuidar una bicicleta, pero no aclara si repara frenos hidráulicos. La segunda tiene más texto y deja sin contestar una pregunta de negocio.

Para una primera lectura, revisaría estas señales:

• La promesa del título se cumple dentro de la página.
• La información permite tomar una decisión o completar una tarea.
• Los detalles son específicos del servicio, producto o duda, no intercambiables entre veinte páginas.
• Los datos importantes tienen una fuente o una explicación comprobable.
• La página aporta algo más que una versión resumida de otras.

No son un test oficial de Google ni una fórmula de puntuación. Son preguntas de revisión editorial. Si una página falla, conviene escribir qué falta exactamente. "Necesita más contenido" no dice qué hay que arreglar.

¿Qué datos conviene revisar antes de cambiar una URL?

Leer la página es imprescindible. Mirar qué está pasando con ella evita tomar una decisión a ciegas.

Empezaría por su función dentro de la web. Puede captar visitas desde Google, explicar una condición comercial, ayudar a un cliente que ya está comparando o dar soporte después de la compra. Tener poco tráfico orgánico no invalida todas esas funciones.

Después consultaría Search Console. Su informe de rendimiento permite revisar clics, impresiones, consultas y páginas, además de comparar periodos. Conviene filtrar la URL y mirar para qué búsquedas aparece, no quedarse con el total del sitio.

Si necesitas ordenar esa primera lectura, en mi guía de Search Console explico qué revisar y en qué orden.

Una URL con cero clics puede no estar indexada, tener poca demanda, ser nueva o responder a una búsqueda estacional. También puede ser poco útil. El número, por sí solo, no permite elegir entre esas explicaciones.

Comprobaría además si recibe enlaces, visitas desde otros canales o contactos. Revisaría qué páginas internas la utilizan y si existe otra URL que resuelve la misma necesidad. Para comparar periodos, elegiría ventanas con sentido para ese negocio y su estacionalidad, sin fijar un plazo universal.

Dejaría una nota sencilla antes de tocar nada: función de la URL, problema observado, datos revisados y cambio propuesto. Sirve para recordar por qué se tomó la decisión cuando toque comprobarla.

¿Cuándo merece la pena mejorar el contenido?

Cuando la página tiene una función clara, pero la respuesta es incompleta, confusa o difícil de utilizar.

Mejorar puede ser añadir información que falta. También puede ser quitar una introducción que retrasa la respuesta, ordenar los apartados, sustituir una explicación genérica por detalles verificables o actualizar una condición que ya no es correcta.

En el ejemplo ficticio del taller, no añadiría una historia de la bicicleta. Aclararía qué reparaciones ofrece, qué necesita saber para dar presupuesto y cómo se reserva una cita. Si hay limitaciones, las explicaría. Si un precio depende de revisar la avería, no inventaría una tarifa para llenar una tabla.

La guía de Google sobre contenido útil propone valorar si hay información original, análisis y valor frente a otras páginas. Esa aportación puede estar en una comparación bien hecha, una prueba documentada o una explicación que permite actuar. No exige adornar cada artículo con una experiencia que nadie ha tenido.

Mi criterio sería corregir primero lo que impide cumplir la tarea. La extensión resultante será una consecuencia de la mejora, no el objetivo del encargo.

¿Cuándo conviene unir dos páginas y cuándo retirar una?

Unir tiene sentido cuando dos páginas responden esencialmente a la misma necesidad y mantenerlas separadas no ofrece una diferencia útil. Antes de decidirlo, compararía sus consultas, su contenido y el papel de cada una. Dos títulos parecidos no bastan para justificar una fusión.

Si se unen, conservaría lo valioso de ambas en un destino que responda a la necesidad original. Después revisaría los enlaces internos y el traslado de la URL que deja de utilizarse.

Google admite redirigir contenidos consolidados a su nueva página común, pero desaconseja enviar muchas URLs a un destino irrelevante, como la portada. No todo lo eliminado tiene que acabar en la home como si fuese un cajón de objetos perdidos.

Una canonical tampoco traslada al visitante. Como explico al hablar de qué es una canonical, sirve para señalar una versión preferida entre páginas duplicadas o muy similares. No sustituye cualquier decisión de mejora, fusión o retirada.

Retirar sería la última opción, no la primera. La documentación de Google sobre cambios tras una actualización principal recomienda considerar la eliminación como último recurso cuando el contenido no se puede recuperar de forma útil.

Si una página ya no tiene función ni un sustituto equivalente, puede corresponder eliminarla. En ese caso hay que devolver el estado adecuado, no una página vacía con respuesta de éxito. En el artículo sobre cuándo corregir un error 404 y cuándo dejarlo desarrollo esa diferencia.

Tabla para tomar la decisión

La tabla orienta la revisión. No autoriza cambios en bloque ni sustituye el análisis de cada URL.

¿Cómo comprobar si la decisión ha funcionado?

Primero comprobaría la implementación. ¿Se ve el contenido completo en móvil? ¿Los enlaces llevan al destino esperado? ¿La página sigue accesible e indexable cuando debe estarlo? ¿Una URL retirada o redirigida responde como se había previsto?

Después compararía el resultado con el objetivo anotado. Si faltaba una condición para contratar, comprobaría que ahora se entiende. Si se unieron dos páginas, revisaría que no se perdió información útil. Si el objetivo era mejorar la captación, seguiría las consultas relevantes y los contactos, no solo el número total de visitas.

Google advierte de que los efectos de los cambios pueden tardar y no garantizan una mejora de posiciones. Publicar la corrección y mirar el gráfico al día siguiente no demuestra el resultado.

El checklist de cierre sería este:

• La URL tiene una función que puedo explicar.
• El contenido responde a esa función con información comprobada.
• He revisado otras páginas antes de decidir una unión.
• Los enlaces y estados de las URLs coinciden con la decisión.
• He guardado una referencia anterior y una fecha para revisar los datos.

Si hay muchas URLs y decisiones dependientes entre sí, hace falta ordenar el trabajo. Ese diagnóstico y sus prioridades forman parte de una auditoría SEO. No es una competición para borrar más páginas que nadie.

Preguntas frecuentes

¿Pocas visitas significan thin content?

No. Las visitas describen un resultado, no la utilidad de la página. Antes de juzgarla hay que revisar su función, la demanda, la indexación y las consultas para las que aparece.

¿Google exige una longitud mínima?

No establece un número preferido de palabras en su guía de contenido útil. La pregunta es si la respuesta permite cumplir la tarea, no si supera una cifra.

¿La IA convierte un texto en thin content?

No por el mero hecho de utilizarla. Hay que revisar el resultado, la exactitud y el valor que aporta. Como explico sobre Google y el contenido creado con IA, automatizar no elimina la responsabilidad editorial.

¿Hay que borrar todo lo que no posiciona?

No. Puede necesitar una mejora, una revisión técnica o simplemente cumplir otra función. Eliminar sin entender el motivo puede llevarse por delante una página que sí ayudaba a los usuarios.

Para acabar el café

Thin content no es una orden de escribir más ni de borrar deprisa. Es una invitación a justificar cada página: qué resuelve, qué aporta y por qué merece existir por separado.

La decisión buena no es la que deja el informe con menos avisos. Es la que deja una web más útil, con cada URL haciendo un trabajo claro.