A principios de 2023, un cliente de viajes vino a verme con lo que parecía una configuración de ensueño. Tenían 14,000 páginas de ubicación — cada ciudad, cada municipio, cada distrito de código postal en el Reino Unido — todas auto-generadas desde una base de datos de hoteles y restaurantes. Template limpio. Enlaces internos decentes. Y rankeaba. Durante aproximadamente cuatro meses.
Luego llegó la actualización central de marzo de 2024. Perdieron el 71% de su tráfico orgánico en seis semanas. Pasé tres semanas haciendo análisis forense. El contenido no estaba mal exactamente. Pero era vacío. Cada página decía las mismas tres cosas en orden ligeramente reorganizado, y Google había decidido claramente que no valía la pena servirlo a nadie. Reconstruimos el pipeline con compuertas de calidad apropiadas y nos recuperamos al 60% del pico en cinco meses. No es perfecto. Pero es una lección que se ha quedado conmigo.March 2024 core update hit. They lost 71% of their organic traffic in six weeks. I spent three weeks doing the forensics. The content wasn't wrong exactly. But it was hollow. Every page said the same three things in slightly shuffled order, and Google had clearly decided it wasn't worth serving to anyone. We rebuilt the pipeline with proper quality gates and recovered to 60% of peak within five months. Not perfect. But a lesson that's stayed with me.
El SEO programático sigue siendo una de las herramientas más poderosas en el toolkit de la agencia. Pero el margen para contenido de baja calidad es básicamente cero.
Qué Significa Realmente "Compuerta de Calidad" en un Pipeline de pSEO
La gente usa este término con soltura, así que permíteme ser preciso sobre cómo lo uso en Seahawk.
Un control de calidad es una regla o prueba verificada que una página debe pasar antes de publicarse, o antes de permanecer publicada. No es una evaluación superficial. Es un umbral específico y medible que permite que una página avance o la devuelve para revisión (o la elimina completamente).checkpointed rule or test that a page must pass before it gets published — or before it stays published. It's not a vibe check. It's a specific, measurable threshold that either lets a page through or sends it back for revision (or kills it entirely).
Piénsalo como integración continua para contenido. Los desarrolladores no suben código que falla pruebas unitarias. No deberías publicar páginas que fallen pruebas de contenido. La analogía no es perfecta, pero es lo suficientemente cercana para ser útil.
Un pipeline sin controles de calidad es solo una máquina de spam de contenido. Y en 2024, el clasificador de Google es lo suficientemente bueno para detectar eso a escala.
Las Tres Capas Donde Necesitan Vivir los Controles
Estructuro los controles en tres momentos:
- Pre-generación — antes de que se escriba cualquier contenido. Verificaciones de calidad de datos. ¿Esta entidad tiene suficientes atributos únicos para sustentar una página distinta? — before any content is written. Data quality checks. Does this entity have enough unique attributes to support a distinct page?
- Post-generación — después de que la IA o plantilla ha producido contenido. Puntuación automatizada para largo, singularidad, cobertura de entidades. — after the AI or template has produced content. Automated scoring for length, uniqueness, entity coverage.
- Monitoreo post-publicación — continuo. Las páginas que pierden impresiones o tasa de clics se marcan para revisión humana. — ongoing. Pages that drop in impressions or click-through rate get flagged for human review.
La mayoría de los equipos solo construyen la capa del medio. Por eso terminan quemados.
El Problema de Suficiencia de Datos (La Mayoría lo Salta)
Aquí está el punto — los peores problemas de contenido programático empiezan antes de escribir una sola palabra. Empiezan en la hoja de cálculo.
Si tus datos de origen tienen 12 atributos por entidad y 9 de ellos son idénticos en el 80% de tus registros, vas a producir páginas casi duplicadas sin importar cuán ingeniosos sean tus prompts. Aprendí esto en un directorio de abogados que construimos en Seahawk en 2021. Teníamos 6,000 registros de despachos legales. Aproximadamente 4,200 de ellos no tenían nada distintivo más allá de un nombre, un código postal y un área de práctica. Publicamos los 6,000. Google indexó quizás 1,800.
Compuerta previa a la generación: puntuación de riqueza de datos. Ahora paso cada dataset a través de un script simple de Python antes de tocar una plantilla. Cuenta el número de campos no nulos y no genéricos por registro e identifica cualquier cosa por debajo de un umbral — típicamente uso 7 de 12 como mínimo. Los registros que no superan esto van a una categoría "stub" que obtiene una página delgada con noindex, o ninguna página en absoluto. I now run every dataset through a simple Python script before we touch a template. It counts the number of non-null, non-generic fields per record and flags anything below a threshold — I typically use 7 out of 12 as a minimum. Records that don't clear it go into a "stub" category that gets a thin page with noindex, or no page at all.
Esto no es glamoroso. Pero es el cambio único que ha tenido el mayor impacto en la eficiencia de rastreo en nuestras construcciones.
Puntuación de Singularidad Después de la Generación
Entonces tus datos superaron la primera compuerta. El contenido ha sido generado. ¿Y ahora qué?
No publiques hasta haberlo puntuado por singularidad — no contra la web, sino contra tu propio corpus de páginas. El contenido interno casi duplicado es el problema más común, y es el que está más inmediatamente bajo tu control.
Uso una combinación de dos herramientas para esto:
- [API por lotes de Copyscape](https://www.copyscape.com/api.php) para identificar páginas que son demasiado similares a URLs ya indexadas for flagging pages that are too similar to existing indexed URLs
- Un script personalizado de similitud de coseno (usando sentence-transformers en Python) que punúa cada página nueva contra las 50 páginas más estructuralmente similares en la misma familia de plantillas
Mi umbral es 0.82 de similitud coseno. Cualquier cosa por encima de eso va a revisión manual. Cualquier cosa por encima de 0.91 se elimina o se reelabora fuertemente.
Sí, esto agrega fricción al pipeline. Bien. La fricción es el punto.
Lo que "Único" Realmente Necesita Significar
Único genuino no solo significa oraciones reorganizadas. Significa que la página responde una pregunta que solo esta entidad puede responder. Para una página de destino de una ciudad, eso es datos hiperlocales — listados de eventos reales, estadísticas locales actuales, una cita específica de una fuente local. Para una página de comparación de productos, son puntos de datos que diferencian estos dos productos específicos, no una introducción genérica con sustantivos intercambiados.this entity can answer. For a city landing page, that's hyper-local data — real event listings, actual local statistics, a specific quote from a local source. For a product comparison page, it's data points that differentiate these two specific products, not a boilerplate intro with swapped nouns.
La orientación propia de Google sobre contenido útil siempre ha dicho esto. El clasificador simplemente se volvió agresivo al aplicarlo. has always said this. The classifier just got aggressive about enforcing it.
Entity Coverage: La Puerta de la que Nadie Habla
Este me tomó más tiempo para resolverlo, y me molesta que haya sido así.
Cada página en una construcción programática es nominalmente "acerca de" algo — un lugar, un producto, una persona, un servicio. La entidad y sus atributos deben estar representados consistentemente en el contenido a través de menciones nombradas, asociaciones semánticas y datos estructurados. Si no lo están, la página se lee como delgada incluso si tiene 800 palabras.
Ahora ejecuto un paso NLP ligero en cada página generada usando spaCy para verificar que:spaCy to check that:
- La entidad principal se nombra en las primeras 100 palabras
- La página contiene al menos cuatro entidades o atributos semánticamente relacionados en el cuerpo del texto.
- La página contiene al menos un dato que es único para la entidad (extraído de los datos fuente, no generado por el modelo).
Por ahora esa última verificación es manual. Quiero automatizarla pero no he construido una forma confiable de hacer validación de referencias cruzadas a escala sin demasiados falsos positivos. Si lo has resuelto, genuinamente quiero saberlo.
La Trampa de la Página Delgada: Cuándo usar Noindex vs. Cuándo Eliminar
Digamos que una página se genera pero aún se siente delgada. Quizá los datos eran escasos, la entidad es obscura, y el resultado es técnicamente único pero no particularmente útil.
¿Qué haces?
Aquí está mi árbol de decisiones — simplificado, pero así es aproximadamente cómo lo pienso:
- Si la página tiene cero impresiones de búsqueda después de 90 días en GSC: elimina y redirige con 301 al padre relevante más cercano.delete and 301 to the nearest relevant parent.
- Si la página tiene impresiones pero CTR menor al 0.5% y sin backlinks: usa noindex y consolida en una página padre o de categoría.noindex and consolidate into a parent or category page.
- Si la página tiene impresiones, CTR razonable (1%+), pero posición promedio baja (40+): mantén, pero prioriza para enriquecimiento de contenido.keep, but prioritise for content enrichment.
- Si la página está funcionando: déjala en paz y deja de cuestionarte a ti mismo.leave it alone and stop second-guessing yourself.
No te imaginas cuántas veces he visto dueños de agencias noindexar páginas que estaban convirtiendo silenciosamente. No arregles lo que no está roto.
Datos Estructurados como Señal de Calidad (No Solo un Juego de Resultados Enriquecidos)
La mayoría de las personas añaden schema a páginas pSEO por los resultados enriquecidos. Está bien. Pero he empezado a tratar la completitud del schema como una puerta de control de calidad también.
Si el schema de una página tiene más del 30% de valores nulos o placeholder, eso me dice que los datos subyacentes son demasiado escasos para producir una página útil. Así que hemos construido un validador de schema en nuestro pipeline — verifica las propiedades requeridas y recomendadas contra la especificación Schema.org para el tipo que estemos usando. Las páginas que fallan esta verificación vuelven a la cola de enriquecimiento.Schema.org spec for whatever type we're using. Pages that fail this check go back into the enrichment queue.
¿Google usa la completitud del schema como una señal de ranking directo? Casi seguro que no de una manera simple. Pero las páginas con schema completo y preciso tienden a ser páginas con datos completos y precisos — y esas páginas tienden a rankear. La correlación es lo suficientemente fuerte como para que trate la calidad del schema como un diagnóstico útil incluso si no es el mecanismo.those pages tend to rank. The correlation is strong enough that I treat schema quality as a useful diagnostic even if it's not the mechanism.
Monitoreo Después de Publicar: La Puerta que Sigue Funcionando
Una puerta de calidad no es algo de una sola vez. Las páginas se degradan. Los datos envejecen. Una página que estaba bien en enero podría ser delgada en octubre porque el mundo avanzó y el contenido no.
Ejecuto un crawl mensual usando Screaming Frog en cada propiedad pSEO grande que gestionamos, marcando:Screaming Frog on every large pSEO property we manage, flagging:
- Páginas bajo 350 palabras (después de eliminar boilerplate)
- Páginas cuyo título coincide con más de 3 otras páginas del sitio
- Páginas sin enlaces internos apuntando hacia ellas (riesgo de orfandad)
Cruzo referencias con datos de GSC exportados vía API — específicamente buscando páginas que hayan perdido más del 40% de sus impresiones en los últimos 60 días. Esa intersección (marcada por Screaming Frog y en declive en GSC) es la cola de revisión de alta prioridad.and declining in GSC) is the high-priority review queue.
Honestamente, este paso de monitoreo es donde la mayoría de agencias cortan camino porque no es facturable de manera obvia. Pero es lo que separa una construcción pSEO que se sostiene de una que se desmorona después de la siguiente core update.
FAQ
¿Usar IA para generar contenido dispara automáticamente una penalización de Google?
No. Google ha dicho explícitamente que el contenido generado por IA no va contra sus directrices — el problema es el contenido poco útil, sin importar cómo se haya producido. La señal es la calidad, no el origen. Una página escrita manualmente que sea delgada y duplicativa recibirá el mismo trato. Lo que importa es si la página realmente sirve mejor la consulta del usuario que las alternativas. Si no lo hace, el método de producción es irrelevante.unhelpful content that's the problem, regardless of how it was produced. The signal is quality, not origin. A manually written page that's thin and duplicative will get treated the same way. What matters is whether the page genuinely serves the user's query better than the alternatives. If it doesn't, the method of production is irrelevant.
¿Cuántas páginas es "demasiado" para una construcción programática antes de que Google sospeche?
No hay un número fijo, y cualquier cifra específica que hayas visto en línea está inventada. Lo que importa es la relación entre páginas indexadas y páginas que rankean. Si tienes 20.000 páginas y 400 están obteniendo impresiones, eso es un problema de presupuesto de rastreo y calidad. Google empezará a ignorar el resto. Prefiero publicar 3.000 páginas sólidas que 20.000 mediocres. La tasa de cobertura de índice es la métrica a vigilar, no el conteo absoluto de páginas.
¿Puedo recuperarme de la penalización por contenido IA basura una vez me hayan golpeado?
Sí, pero toma tiempo y no es lineal. El cliente de viajes que mencioné al inicio se recuperó, pero requirió trabajo constante durante cinco meses: eliminar las páginas peor posicionadas, consolidar las de nivel medio, enriquecer las de mejor desempeño. La acción más impactante fue reducir el índice de 14.000 páginas a aproximadamente 4.200. Contraintuitivo, pero eso es lo que mostraron los datos.
¿Cuál es la forma más rápida de identificar cuáles páginas en una estructura grande son "basura"?
Extrae tus datos completos de desempeño de GSC de las últimas 16 semanas. Filtra por páginas con más de 0 impresiones pero menos de 0.8% CTR y posición promedio peor que 35. Ese conjunto es tu problema. Cruza referencias contra conteo de palabras y conteo de enlaces internos. La superposición de bajo CTR, bajo conteo de palabras y páginas huérfanas es casi siempre la parte más débil de cualquier estructura programática.
---
Construir a escala no te da permiso para construir mal. Los controles que describí agregan quizás dos o tres días de tiempo de configuración a un proyecto de pSEO nuevo. La alternativa —reconstruir después de que una actualización central te elimina— cuesta mucho más que eso. Lo sé porque lo he hecho de ambas formas.