Por qué Google puede ver tu blog técnico como contenido de poco valor aunque los artículos sean buenos

Hace unos meses solicité AdSense para oshy.tech. La respuesta fue un rechazo con la etiqueta “low value content”. Mi primera reacción fue pensar que estaban equivocados. Los artículos estaban escritos desde la experiencia, con código real, sin relleno. No eran artículos de cinco párrafos generados por una IA sin criterio. Eran piezas que habían requerido horas de escritura, revisión y prueba de los snippets de código.

Después de analizar el sitio con más distancia, entendí que Google no estaba evaluando solo la calidad de cada artículo individual. Estaba evaluando el sitio como un todo. Y visto como un todo, oshy.tech tenía problemas reales que no había querido ver.

Este artículo es el análisis honesto de qué puede hacer que un blog técnico parezca “low value” para Google, incluso cuando el contenido de los artículos es genuinamente bueno. No es una guía de cómo engañar al algoritmo. Es una reflexión desde la experiencia de alguien que fue rechazado, investigó por qué, y descubrió que el problema no estaba donde pensaba.

Qué significa “low value content” para Google

Cuando Google marca un sitio como contenido de poco valor, no siempre significa que el contenido sea malo. Significa que el sitio, evaluado en conjunto, no cumple los criterios que Google considera suficientes para mostrar anuncios o para posicionar de forma favorable.

Es una distinción importante. Google no lee tu artículo sobre Spring Boot y Kotlin y dice “esto no vale”. Lo que hace es evaluar el sitio como un sistema: cuántas páginas tiene, qué porcentaje de esas páginas son contenido sustancial, qué señales de calidad detecta, cómo se comportan los usuarios y qué estructura informativa presenta.

Las señales que Google evalúa van más allá del texto de cada artículo:

• Volumen de contenido indexado. Un sitio con 5 artículos y 30 páginas indexadas tiene un ratio muy desfavorable. Google se pregunta: si solo hay 5 artículos, para qué existen las otras 25 páginas?
• Proporción de páginas con valor vs páginas sin valor. Si de 40 URLs indexadas, 25 son categorías vacías, tags con un artículo y páginas de paginación, el porcentaje de contenido real es bajo.
• Señales de engagement. Tiempo en página, tasa de rebote, páginas por sesión. Un sitio nuevo tiene poco tráfico y pocas señales positivas, lo que no ayuda a demostrar utilidad.
• E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness). Para contenido técnico, Google quiere ver quién escribe, qué experiencia tiene y por qué debería ser creíble.
• Contenido duplicado o muy similar. Esto incluye traducciones directas que Google puede interpretar como contenido duplicado cross-language si el hreflang no está bien implementado.
• Frecuencia y patrón de publicación. Un sitio que publica 5 artículos de golpe y luego nada durante meses puede parecer menos comprometido que uno con publicación regular.

El Helpful Content Update de Google (ahora integrado en el sistema de ranking general) evalúa si un sitio produce contenido “primariamente para personas” o “primariamente para buscadores”. No basta con que cada artículo sea útil; el sitio como conjunto tiene que demostrarlo.

Las señales que probablemente estaba enviando oshy.tech

Voy a ser transparente con los problemas que identifiqué en mi propio sitio. No porque quiera exponerme, sino porque estos son errores que comete casi cualquier desarrollador que monta un blog técnico y que son difíciles de ver cuando estás dentro del proyecto.

Pocas páginas de contenido real vs muchas páginas de estructura

Cuando solicité AdSense, oshy.tech tenía unos 10-12 artículos publicados. Pero el sitio generaba muchas más URLs. Esto es lo que un crawler veía:

• Página principal (1)
• Páginas de blog por idioma (3: es, en, ca)
• Cada artículo en 3 idiomas (30-36 URLs)
• Categorías en cada idioma (probablemente 20-25 URLs de categorías)
• Páginas de tags (quizá otras 15-20)
• Paginación de listados
• Páginas estáticas (about, legal, contacto)

De repente, un sitio con 12 artículos tenía más de 80 URLs potencialmente indexables. Y de esas 80, la mayoría eran páginas de listado con 1-2 artículos. Google ve eso y piensa: este sitio tiene más estructura que contenido. Más envoltorio que producto.

Para visualizarlo con números concretos:

Un 40% de páginas con contenido real no es terrible, pero cuando las páginas de alto valor son traducciones entre sí (12 artículos originales, no 36), el ratio real baja mucho más. Google está viendo quizá 12 piezas de contenido original en un sitio con 89 URLs. Eso es un 13%.

Categorías con un solo artículo

Este fue probablemente el problema más grave y el más fácil de evitar. Creé categorías pensando en el futuro editorial. “Kotlin”, “Java”, “Linux”, “OSINT”, “Data Analysis”, “Automatización”… El problema es que varias de esas categorías tenían un solo artículo. Algunas ni siquiera tenían uno en todos los idiomas.

Una página de categoría con un artículo es, funcionalmente, una página que tiene un título, un par de líneas de descripción y un enlace. Para Google, eso es thin content. No aporta nada que el artículo por sí mismo no aporte ya. Y cada una de esas páginas diluye la calidad percibida del sitio.

Pensé que tener categorías preparadas mostraría que el sitio tenía una estructura editorial seria. En realidad, mostraba lo contrario: una estructura ambiciosa sin el contenido que la justificara. Es como abrir un restaurante con 30 mesas y servir comida en 3. La estructura vacía no impresiona; genera desconfianza.

Multidioma como multiplicador del problema

Tener el blog en tres idiomas (español, inglés, catalán) triplica todos los problemas anteriores. Un artículo son tres URLs. Una categoría son tres páginas de categoría. Un tag son tres páginas de tag.

Si el artículo en español es bueno pero la versión en inglés es una traducción directa con poco tráfico y la versión en catalán tiene aún menos, Google puede ver dos de esas tres versiones como contenido de bajo valor. No porque el texto sea malo, sino porque no tiene señales de utilidad: nadie lo lee, nadie lo enlaza, nadie interactúa con él.

Además, si la implementación de hreflang no es perfecta, Google puede interpretar las versiones como contenido duplicado en vez de como traducciones legítimas. Un detalle técnico que tiene consecuencias grandes en la percepción global del sitio.

El multidioma también afecta a las métricas de engagement. Si Google ve que la versión en catalán de un artículo tiene 0 visitas en tres meses, esa es una señal negativa. No es que Google penalice por tener poco tráfico, pero la ausencia de señales positivas en muchas páginas suma para la evaluación general.

Falta de señales de autoría y experiencia

Los primeros artículos de oshy.tech no tenían una página de autor clara, no enlazaban a un perfil profesional verificable, y la página “About” era mínima. Para el Helpful Content Update, las señales de E-E-A-T importan especialmente en contenido técnico.

Google quiere saber: esta persona que escribe sobre Spring Boot y Kotlin, realmente trabaja con eso? Dónde está la evidencia? Un blog anónimo sin señales de autoría real compite en desventaja con blogs que tienen autores identificables con perfiles profesionales enlazados.

No se trata de poner un CV entero en la página About. Se trata de que existan señales verificables: un nombre real, un perfil de LinkedIn, contribuciones a proyectos, menciones en otros sitios, experiencia demostrable. Sin esas señales, Google trata el contenido como anónimo, y el contenido técnico anónimo tiene menos credibilidad algorítmica que el firmado por alguien con trayectoria verificable.

Contenido duplicado cross-language: un problema que se subestima

Cuando traduces un artículo del español al inglés, el contenido es estructuralmente el mismo. Los mismos títulos, la misma estructura, los mismos ejemplos de código, la misma argumentación. Google es bastante bueno detectando traducciones. Con hreflang correctamente implementado, entiende que son versiones del mismo contenido y no las penaliza como duplicado.

Pero hay matices que importan.

El primer matiz es que hreflang tiene que ser perfecto. Si hay errores (URLs que no coinciden, hreflang no recíproco, URLs con redirecciones), Google puede ignorar las señales de hreflang y tratar las versiones como páginas independientes con contenido muy similar. En ese caso, puede decidir indexar solo una versión y descartar las demás, o puede tratar todo como contenido de baja originalidad.

El segundo matiz es que incluso con hreflang correcto, Google evalúa cada versión de forma independiente para ranking. Si la versión en español tiene 50 visitas al mes y la versión en catalán tiene 0, Google puede decidir que la versión en catalán no merece estar indexada. Y si tiene muchas versiones que “no merecen estar indexadas”, eso contribuye a la percepción general de bajo valor.

El tercer matiz afecta específicamente a los snippets de código. En un artículo técnico, gran parte del contenido (el código) es idéntico en todos los idiomas. Si tienes un artículo de 300 líneas donde 100 son código y 200 son texto, el 33% del contenido es literalmente idéntico en las tres versiones. Google puede interpretar eso como un porcentaje alto de contenido compartido.

No estoy diciendo que el multidioma sea malo. Estoy diciendo que multiplicar idiomas sin tener la base técnica correcta multiplica también los problemas. Y que para un sitio pequeño, cada idioma adicional tiene que justificar su existencia con tráfico y engagement reales.

Qué es el Helpful Content System y cómo afecta a blogs pequeños

El sistema de contenido útil de Google (originalmente “Helpful Content Update”, ahora integrado en el ranking general) evalúa si un sitio produce contenido primariamente para ayudar a personas o primariamente para atraer tráfico de buscadores.

Esto suena abstracto, pero tiene implicaciones concretas. Las señales que Google usa incluyen:

• Proporción de contenido original vs contenido derivativo. Si la mayoría de tus páginas son listados generados automáticamente (categorías, tags, archivos) y pocas son contenido original (artículos), la proporción es desfavorable.
• Profundidad del contenido. Artículos superficiales que cubren un tema sin profundidad se clasifican como thin content. Un artículo de 300 palabras que explica qué es Kotlin no compite con uno de 2000 que analiza las fricciones reales de usar Kotlin con JPA.
• Experiencia demostrable. Contenido que muestra experiencia real (código probado, decisiones justificadas, errores cometidos y resueltos) se evalúa mejor que contenido teórico genérico.
• Consistencia temática. Un sitio que habla de todo sin profundizar en nada tiene menos autoridad temática que uno enfocado en 2-3 temas con profundidad.
• Contenido first-party vs contenido genérico. Google distingue entre contenido que aporta perspectiva propia y contenido que recopila información disponible en otros sitios.

Para un blog técnico pequeño, el tercer y cuarto punto son especialmente relevantes. Si escribes sobre Kotlin, SEO, Python, Linux, OSINT y análisis de datos en 12 artículos, no estás demostrando expertise en ninguno de esos temas. Estás demostrando que sabes un poco de muchas cosas. Google prefiere la profundidad a la amplitud, especialmente en sitios con poca autoridad de dominio.

Esto no significa que no puedas tener temas variados. Significa que necesitas masa crítica en cada tema. Tres artículos sobre Kotlin con profundidad real demuestran más experiencia que un artículo sobre cada uno de diez temas diferentes.

El rechazo de AdSense: qué dice y qué no dice

El rechazo de AdSense por “low value content” es una evaluación binaria: el sitio pasa o no pasa un umbral de calidad. Google no da detalles específicos sobre qué falló. Eso genera frustración, pero también obliga a hacer una revisión completa.

Lo que el rechazo dice:

• El sitio, evaluado como un todo, no cumple los estándares mínimos de Google para mostrar anuncios.
• Hay señales suficientes de bajo valor como para no aprobarlo.

Lo que el rechazo no dice:

• No significa que el contenido sea malo. Puede ser que el contenido sea bueno pero la estructura sea pobre.
• No es permanente. Se puede reaplicar después de hacer cambios.
• No afecta directamente al ranking orgánico. AdSense y el algoritmo de búsqueda son sistemas separados, aunque comparten algunos criterios de calidad.

El error más común después de un rechazo es publicar más artículos rápido pensando que el problema es de volumen. Si el problema es estructural, más artículos sobre la misma estructura rota no lo resuelven. De hecho, pueden empeorarlo si cada artículo nuevo genera más categorías y tags de bajo valor.

El plan: qué haría antes de reaplicar a AdSense

Después de analizar todo esto, construí un plan concreto. No es teoría; es lo que estoy implementando en oshy.tech antes de volver a intentarlo.

1. Consolidar categorías

Reducir el número de categorías a las que tienen al menos 3-4 artículos. Las categorías con 1-2 artículos se fusionan en categorías más amplias o se eliminan. Menos categorías con más contenido cada una es mejor que muchas categorías vacías.

En la práctica, esto significó pasar de tener categorías como “Kotlin”, “Java”, “Linux”, “OSINT”, “Sherlock”, “Data Analysis” a algo más consolidado: “Backend” (que agrupa Kotlin, Java, Spring Boot), “Data” (que agrupa análisis, pipelines, ETL), “Herramientas” (que agrupa automatización, scraping, OSINT). Menos categorías, pero cada una con suficiente contenido para justificar su existencia como página indexable.

2. Noindex agresivo en páginas de bajo valor

Todas las páginas de listado (categorías, tags) que tengan menos de 3 artículos llevan noindex. Las páginas de paginación llevan noindex. Las páginas de tags se eliminan directamente si no tienen volumen suficiente.

El objetivo es que las páginas indexadas sean mayoritariamente artículos completos, no envolturas con un enlace. Si Google ve 50 URLs y 45 son artículos con profundidad, la percepción es completamente diferente a 50 URLs de las cuales 20 son listados vacíos.

3. Mejorar el ratio contenido/estructura

Publicar más artículos antes de reaplicar. Pero no artículos rápidos o de relleno, sino contenido sustancial que demuestre experiencia real. El objetivo es que cuando Google visite el sitio, la mayoría de URLs indexadas sean artículos con profundidad, no páginas de estructura.

La meta concreta es llegar a 20-25 artículos sustanciales antes de reaplicar. Eso, con categorías consolidadas y noindex en páginas de bajo valor, debería dar un ratio de contenido real mucho más favorable.

4. Resolver el multidioma correctamente

Revisar que todos los hreflang sean correctos, recíprocos y apunten a URLs finales sin redirecciones. Asegurarme de que los canonical de cada versión apunten a sí mismos. Considerar si todas las versiones en todos los idiomas realmente aportan valor o si es mejor ser más selectivo con qué artículos se traducen.

No todos los artículos necesitan existir en tres idiomas. Un artículo sobre la lotería nacional española tiene sentido en español pero no necesariamente en inglés. Ser selectivo con las traducciones es mejor que traducir todo automáticamente para “rellenar” los otros idiomas.

5. Reforzar E-E-A-T

Mejorar la página About con información verificable. Enlazar a perfil profesional. Incluir una bio del autor en cada artículo con contexto relevante (“backend engineer con experiencia en Spring Boot y Kotlin”). Añadir Schema Person/Author con datos reales.

También incluir en los artículos señales de experiencia: mencionar proyectos reales, explicar decisiones que se tomaron y por qué, documentar errores que se cometieron. Eso no es alardear; es demostrar que el contenido viene de alguien que ha trabajado con lo que escribe.

6. Schema Article en todos los artículos

Datos estructurados correctos en cada artículo: TechArticle, autor, fechas, descripción, idioma. No es un factor de ranking directo, pero ayuda a Google a entender el contenido y puede mejorar la presentación en resultados de búsqueda.

7. Revisar Search Console semanalmente

Google Search Console es la herramienta más importante para entender qué ve Google. Las páginas con errores de indexación, las URLs “descubiertas pero no indexadas”, los problemas de cobertura, las queries que generan impresiones. Todo eso indica dónde están los problemas reales, sin adivinar.

Un dato que descubrí en Search Console: varias páginas de categorías estaban marcadas como “crawled - currently not indexed”. Google las rastreó, las evaluó y decidió no indexarlas. Eso es una señal directa de que Google consideró esas páginas insuficientes para su índice.

Lo que este proceso me ha enseñado

La lección más importante no es técnica. Es de perspectiva. Como desarrolladores, tendemos a pensar en calidad de contenido como la calidad del texto que escribimos. Nos preguntamos: es correcto? es útil? está bien explicado? Y esas son preguntas válidas, pero incompletas.

Google no evalúa artículos aislados. Evalúa el sitio como un sistema. La arquitectura de la información, la proporción de contenido real sobre el total de páginas, las señales de autoría, la coherencia técnica del multidioma, la consistencia temática. Todo eso cuenta tanto o más que la calidad individual de cada artículo.

Un artículo excelente en un sitio con mala estructura técnica rinde menos de lo que debería. No porque Google “no lo entienda”, sino porque las señales del sitio completo bajan la credibilidad del artículo individual. Es como presentar un buen plato en un restaurante sucio: el plato puede ser bueno, pero el contexto contamina la percepción.

La otra lección es sobre la honestidad con uno mismo. Es fácil ver un rechazo de AdSense y pensar “Google está equivocado, mi contenido es bueno”. Puede que tu contenido sea bueno. Pero si tu sitio tiene categorías vacías, tags sin volumen, multidioma mal implementado y poca señal de autoría, estás saboteando tu propio contenido con decisiones de estructura que tomaste sin pensar en cómo las vería un crawler.

La tercera lección es que el SEO técnico no es un tema aparte del contenido. Son lo mismo. Un artículo sin canonical correcto, sin hreflang funcional, en una categoría con thin content, es un artículo que empieza la carrera con desventaja. Y en un sitio pequeño sin autoridad de dominio, esa desventaja puede ser la diferencia entre posicionar y no existir.

El contenido bueno es condición necesaria pero no suficiente. La estructura que lo rodea determina si Google lo ve como contenido valioso dentro de un sitio valioso, o como contenido aislado dentro de un sitio que todavía no ha demostrado su valor.

Lo que no haría: reacciones que empeoran la situación

Después de un rechazo, hay reacciones instintivas que parecen lógicas pero que pueden empeorar las cosas. Las menciono porque estuve a punto de caer en varias.

Publicar artículos rápidos para “llenar” el sitio. Si el problema es de proporción contenido/estructura, añadir artículos superficiales no mejora el ratio. De hecho, añade más páginas que Google puede considerar thin content. Cada artículo nuevo debería ser sustancial, no relleno para alcanzar un número.

Crear más categorías para los artículos nuevos. Exactamente el mismo error que causó el problema original. Si publicas un artículo sobre Docker y creas la categoría “DevOps” con un solo artículo, has empeorado la estructura. Mejor ponerlo en una categoría existente que ya tenga contenido suficiente.

Traducir todo a más idiomas. Si el multidioma ya es un problema, añadir un cuarto idioma no lo resuelve. Cada idioma adicional multiplica las páginas de bajo valor si no hay audiencia real para esa versión.

Comprar backlinks o hacer outreach agresivo. Los backlinks ayudan al posicionamiento orgánico, pero no son lo que evalúa AdSense. El problema con “low value content” es interno del sitio, no de autoridad externa. Gastar esfuerzo en backlinks cuando la estructura está rota es poner una fachada bonita en un edificio con los cimientos mal.

Ignorar el rechazo y seguir como si nada. La tentación de pensar “ya posicionará solo” es fuerte. Pero las señales de bajo valor no se corrigen solas con el tiempo. Se corrigen con cambios estructurales deliberados.

La reacción correcta es pararse, analizar, corregir la estructura y luego seguir publicando sobre una base sólida. No es la respuesta rápida que uno quiere escuchar, pero es la que funciona.

Para quién es esto útil

Si tienes un blog técnico pequeño y quieres entender por qué no posiciona o por qué Google no lo valora como esperabas, revisa la estructura antes de culpar al contenido. Si tienes pocas páginas pero muchas URLs indexadas, si tienes categorías con un artículo o si tienes multidioma sin hreflang correcto, es probable que el problema esté ahí.

No es un problema de escribir más. Es un problema de ordenar lo que tienes antes de crecer. Un sitio pequeño con estructura limpia tiene más posibilidades que un sitio pequeño con estructura inflada. Y eso es algo que puedes arreglar esta semana, sin escribir ni un artículo nuevo.

Abre Google Search Console, mira qué URLs están indexadas, cuáles están marcadas como “not indexed” y cuáles tienen errores. Esa información te va a decir más sobre tu problema que cualquier checklist genérico de SEO. Y si descubres que la mitad de tus URLs indexadas son páginas de categorías vacías, ya sabes por dónde empezar.