Un marketplace con verificación de identidad y cumplimiento legal escrito en el código: cómo lo construimos y qué cuesta.
24 min de lectura · Publicado el 6 de septiembre de 2026 · Caso de estudio Webhexup
Casi todos los casos de estudio que se publican en esta industria son de proyectos bonitos. Un rediseño que quedó lindo, una tienda que subió las ventas. Este no es de esos.
Este proyecto tiene una particularidad que lo hace interesante como ejercicio técnico: opera en un vertical donde la ley no es un anexo del proyecto sino parte de la arquitectura. No puedes ponerle un párrafo de términos y condiciones y seguir. Tienes que escribir el cumplimiento dentro del código, porque si el sistema permite algo que la ley prohíbe, el problema no es de política de uso: es del sistema.
Además me obligó a resolver cosas que en un proyecto normal no aparecen: URLs jerárquicas de tres niveles con miles de combinaciones, verificación de identidad con documentos que nunca pueden ser públicos, y un modelo de cobro por visibilidad con vencimiento automático.
Por confidencialidad no menciono ni el cliente ni el sector. Todo lo demás es exacto: las versiones, los archivos, los bugs y los precios.
- Qué me pidieron construir
- Los dos pivots de stack antes de arrancar en serio
- La arquitectura de URLs y el bug que me costó una semana
- Cumplimiento legal escrito en el código
- El schema de nueve tipos y la estrategia de keywords
- Las tres veces que le dije que no
- Qué hay construido hoy
- Cuánto cuesta un proyecto así
- Preguntas frecuentes
Qué me pidieron
construir.
El encargo llegó descrito como "un directorio". Después de la primera reunión quedó claro que era un marketplace completo con estas piezas:
- Registro público autogestionado. El proveedor del servicio crea su propio perfil, sube documentos de identidad y espera aprobación. Sin intervención manual salvo en la moderación.
- Verificación de identidad obligatoria. Documento por ambos lados más una selfie sosteniéndolo. Esos archivos nunca pueden ser públicos.
- Cinco niveles de visibilidad con cobro semanal y vencimiento automático.
- Ocho ciudades con zonas dentro de cada una, y URLs que reflejen esa jerarquía.
- Sistema de reseñas con calificaciones por criterio y posibilidad de respuesta.
- Canal de reportes con categorías críticas que disparan alerta inmediata.
- Panel propio para que cada proveedor gestione su perfil sin tocar el admin de WordPress.
Nada de eso existe empaquetado. Hay plugins de directorio genéricos, pero ninguno resuelve verificación de identidad con custodia de documentos, ni jerarquía de URLs de tres niveles, ni un modelo de cobro por visibilidad con vencimiento. Tocaba construirlo.
Los dos pivots de stack
antes de arrancar en serio.
Esta parte la cuento porque me parece la más útil para cualquiera que esté decidiendo con qué construir.
Arrancamos en WordPress. A las pocas semanas propusimos migrar a Next.js: mejor rendimiento, control total del frontend, la decisión que cualquier desarrollador habría defendido en una reunión técnica. Montamos un sprint completo en Next.js 15.
Y después volvimos a WordPress.
No por un problema técnico. Por una razón mucho más importante: el cliente conoce WordPress y no conoce Next.js. Puede entrar al admin, cambiar un texto, subir una imagen, revisar un perfil pendiente. Con Next.js dependía de mí para cada cambio.
Perdimos unas semanas en ese ida y vuelta. Pero la decisión final fue la correcta, y prefiero perder tres semanas que entregar algo que el cliente no pueda operar.
La arquitectura de URLs
y el bug que me costó una semana.
Esta es la parte que más le va a servir a quien haya peleado con reglas de reescritura en WordPress.
Lo que necesitábamos
Cada perfil tenía que vivir en una URL que reflejara ciudad y zona, porque esa jerarquía es la que sostiene todo el SEO local del proyecto:
// Estructura objetivo
/medellin/el-poblado/nombre-del-perfil/
/bogota/chapinero/otro-perfil/
/cali/granada/tercer-perfil/
// Y además, landings propias de cada nivel
/medellin/ ← landing de ciudad
/medellin/el-poblado/ ← landing de zonaOcho ciudades con varias zonas cada una. La jerarquía de URL es lo que le dice a Google que el contenido es local y a qué nivel de granularidad.
El error que parecía obvio y no lo era
La forma intuitiva de hacerlo es registrar el tipo de contenido con placeholders en el slug de reescritura. Algo así:
// Esto NO funciona
register_post_type('escort', [
'rewrite' => [
'slug' => '%ec_ciudad%/%ec_zona%',
'with_front' => false,
],
]);Parece razonable. WordPress no lo interpreta así.
WordPress toma esos placeholders de forma literal. Genera reglas de reescritura que buscan la cadena de texto %ec_ciudad% en la URL, no el valor de la taxonomía. Esas reglas nunca coinciden con nada, y el resultado es 404 en todos los perfiles del sitio.
Y había un segundo problema encima. La taxonomía de ciudad estaba registrada con slug vacío para que las URL quedaran limpias. Eso hace que la taxonomía capture cualquier URL de un solo segmento. O sea que además de los perfiles, se cayeron las páginas normales: contacto, términos, blog. Todo.
Cómo lo resolví
La solución fue dejar de pedirle a WordPress que adivine y construir las reglas explícitamente desde los slugs de ciudad reales:
// Clase Rewrites: genera las reglas desde los datos reales
foreach ($ciudades as $ciudad) {
$c = $ciudad->slug;
// 1. Paginación PRIMERO. Este orden es crítico:
// si va después, el patrón genérico se come /page/2/
add_rewrite_rule(
"^{$c}/page/([0-9]+)/?$",
'index.php?ec_ciudad=' . $c . '&paged=$matches[1]',
'top'
);
// 2. Perfil dentro de zona, con lookahead negativo
// para que /page/ nunca entre como si fuera una zona
add_rewrite_rule(
"^{$c}/((?!page/)[^/]+)/([^/]+)/?$",
'index.php?post_type=escort&name=$matches[2]',
'top'
);
// 3. Landing de zona
add_rewrite_rule(
"^{$c}/((?!page/)[^/]+)/?$",
'index.php?ec_ciudad=' . $c . '&ec_zona=$matches[1]',
'top'
);
// 4. Landing de ciudad, la más genérica va de último
add_rewrite_rule(
"^{$c}/?$",
'index.php?ec_ciudad=' . $c,
'top'
);
}Dos detalles que parecen menores y no lo son: el orden de las reglas y el lookahead negativo. Sin cualquiera de los dos, la paginación se rompe en silencio.
Entre encontrar la causa, entender el segundo problema del slug vacío y dejar el orden de reglas estable, se me fue una semana completa. Lo dejo escrito acá para que a alguien más no le pase.
Cumplimiento legal escrito
en el código.
Acá está la diferencia entre un proyecto de vertical regulado y uno normal. Tres leyes colombianas que no quedaron en el documento de términos sino dentro del sistema.
Protección de menores
La Ley 1336 de 2009 sanciona la publicidad que promueva servicios sexuales con menores de edad. Lo que hice:
- Validación de edad del lado del servidor, no solo en el formulario. Si alguien manipula el HTML, el rechazo ocurre igual.
- Cuando el rechazo se dispara, la pantalla no dice solo "no puedes registrarte": muestra la línea 141 del ICBF y el 018000-522020 de la línea contra la trata.
- Verificación con documento por ambos lados más selfie sosteniéndolo, con revisión manual antes de publicar.
Habeas Data
La Ley 1581 de 2012 regula el tratamiento de datos personales. Dos decisiones técnicas concretas:
// Las IPs nunca se guardan en claro
$ip_hash = hash('sha256', $ip . wp_salt('auth'));
// Sirve para detectar abuso y votos duplicados,
// pero no reconstruye quién visitó qué perfilPuedes contar visitas únicas y frenar abuso sin conservar un dato que, en este vertical, sería material sensible si alguna vez se filtra la base.
Los documentos de verificación se conservan después de aprobar el perfil, pero en carpeta privada protegida a nivel de servidor, nunca publicados, accesibles solo con permiso explícito y con registro de cada acceso. Si alguien del equipo abre un documento, queda constancia.
Prevención de trata
La Ley 985 de 2005 adopta medidas contra la trata de personas. En el sistema, dos categorías de reporte están marcadas como críticas y se muestran destacadas en el panel de administración, con las líneas de denuncia visibles al lado. No entran en la cola normal de moderación.
El schema de nueve tipos
y la estrategia de keywords.
Por qué un grafo y no un bloque suelto
Cada perfil emite un grafo de schema con nueve tipos conectados entre sí. No son nueve bloques sueltos: es un grafo donde cada nodo referencia a los otros con identificadores, para que el buscador entienda que la persona, el servicio, la ubicación y las reseñas son partes de la misma entidad.
Ese nivel de detalle en un directorio de miles de perfiles es lo que hace la diferencia entre que Google entienda la estructura o la trate como páginas sueltas.
La estrategia de keywords
Acá aplicamos algo que he escrito en otros artículos: el término con más volumen no siempre es el término correcto.
| Nivel | Tipo de término | Por qué |
|---|---|---|
| Primario | El colombianismo local | Alta intención de compra, competencia internacional mucho menor porque solo se usa acá |
| Secundario | El término internacional | Captura turismo y búsquedas desde fuera del país |
| Complementario | El término neutro | Segmento que evita el vocabulario más directo |
El primario es el que manda la arquitectura de contenido, aunque en volumen absoluto no sea el más grande. Un término que solo se usa en Colombia tiene una ventaja enorme: los sitios internacionales con autoridad de dominio brutal no lo están trabajando.
Las tres veces
que le dije que no.
Un caso de estudio donde el proveedor solo cuenta lo que salió bien no sirve de mucho. Estas son las tres decisiones donde no hice lo que me pidieron, y por qué.
La categoría que no implementé
Me pidió replicar la lista de categorías de un competidor. La implementé completa menos una, porque en ese contexto esa palabra significa apariencia de menor de edad.
Le expliqué tres razones. La primera es legal: la Ley 1336 sanciona la publicidad que promueva servicios sexuales con menores, y una categoría cuyo significado en el sector es ese te pone en una conversación que no quieres tener. La segunda es operativa: ese vocabulario dispara revisiones automáticas en buscadores, redes de distribución de contenido y pasarelas de pago. La tercera es que el segmento que él quería cubrir ya estaba cubierto por otra categoría sin ninguno de esos problemas.
Lo aceptó. Y dejé un test automatizado que verifica que ese vocabulario no vuelva a aparecer en el código, porque en un equipo que crece alguien puede agregarlo sin conocer el contexto.
La obligatoriedad total que habría roto los filtros
Me pidió que todos los campos del formulario fueran obligatorios. Suena razonable hasta que miras la estructura de datos.
Hay grupos de opciones que tienen una sola alternativa. Si haces obligatorio un grupo de una sola opción, todo el mundo la marca, y entonces ese filtro queda inservible: filtras por esa característica y te devuelve el catálogo entero.
La solución fue distinguir entre grupos descriptivos y excluyentes, que sí son obligatorios, y grupos aditivos, que no. Quedaron doce obligatorios y ocho opcionales, con una bandera por grupo que se cambia en una línea si él quiere ajustar el criterio después.
El hosting que le advertí
El proyecto vive en un hosting compartido de un proveedor grande. Le advertí que un vertical de este tipo en hosting mainstream es un riesgo de suspensión latente, y le di alternativas de proveedores que sí aceptan el sector explícitamente.
Decidió quedarse donde está por costo. Es su decisión y la respeto, pero quedó por escrito. Si algún día llega la suspensión, no va a ser una sorpresa.
Qué hay construido
hoy.
Estado al momento de escribir esto, con los números reales de los archivos entregados.
El plugin, versión 1.6.0
Unos 106 KB, 33 archivos PHP, requiere PHP 8.1 o superior. Contiene:
- Tipo de contenido propio con las URL jerárquicas de tres niveles
- Nueve taxonomías, seis públicas y tres internas
- Cuatro roles de usuario con permisos diferenciados
- Cuatro tablas propias: reseñas con calificaciones por criterio, pagos, reportes y registro de visitas
- Sistema de cinco niveles de visibilidad con tarea programada de vencimiento
- Registro público en asistente de once pasos
- Panel del proveedor con nueve secciones
- Moderación de perfiles y de reseñas
- Gestión de reportes con marcado de casos críticos
- Registro de visitas y de clics de contacto
- Capa de compatibilidad con Yoast
El tema, versión 1.4.0
Unos 50 KB. Plantillas propias para inicio, perfil individual con el grafo de schema, landing de ciudad, landing de zona, directorio, blog, páginas y error 404. Los textos alternativos de las imágenes se generan con el formato que necesita el negocio para búsqueda por imágenes.
Lo que sigue
| Pendiente | Qué implica |
|---|---|
| Buscador con filtros en las landings de ciudad | Es lo principal que falta. La base ya está: las taxonomías, los grupos y los datos de prueba |
| Pagos con comprobante manual | Subir soporte, confirmar desde el admin y activar el nivel. La tabla ya existe |
| Despliegue y optimización | Rendimiento, caché, imágenes y paso a producción |
Cuánto cuesta
un proyecto así.
Te lo desgloso por componentes, porque casi nadie publica esto y creo que hace falta.
Plugin a la medida
Es el corazón del proyecto y donde se va la mayor parte del trabajo. Incluye:
- Modelo de datos y tablas propias
- Tipos de contenido, taxonomías y roles
- Arquitectura de URLs y reglas de reescritura
- Registro público y panel del usuario
- Flujos de moderación y reportes
- Sistema de niveles con vencimiento automático
- Cumplimiento normativo implementado en código
Tema a la medida
Plantillas propias para cada tipo de página, diseño responsivo, identidad visual aplicada y el grafo de schema por perfil. No es una plantilla comprada con ajustes: es código escrito para este modelo de datos.
Arquitectura SEO y contenido base
Estrategia de palabras clave, arquitectura de URLs pensada para SEO local, schema estructurado, redacción de las páginas legales y del contenido base del sitio, y configuración técnica completa.
Despliegue, pruebas y documentación
Paso a producción, pruebas de carga, optimización de rendimiento, herramientas de diagnóstico y documentación para que el cliente pueda operar sin depender de la agencia para todo.
Qué mueve el precio dentro del rango
| Factor | Efecto |
|---|---|
| Cantidad de reglas de negocio propias | Cada flujo que no existe empaquetado suma desarrollo |
| Marco regulatorio del sector | Verticales regulados suman validaciones, auditoría y custodia de datos |
| Número de roles y permisos | Cada rol multiplica los casos a probar |
| Integraciones de pago | Pasarela estándar es rápido; flujos manuales con comprobante son más trabajo del que parece |
| Volumen de contenido inicial | Redactar páginas legales y contenido base no es gratis |
Cómo estructuro el pago
Anticipo del 40% para arrancar
Cubre descubrimiento, modelo de datos, arquitectura de URLs y el primer bloque de desarrollo. Es la fase donde se define todo lo demás.
30% contra entrega funcional
Plugin y tema funcionando en ambiente de pruebas, con el flujo completo operativo de punta a punta.
30% contra puesta en producción
Sitio en producción, optimizado, documentado y con el cliente capacitado para operarlo.
Preguntas frecuentes
sobre este tipo de proyecto.
¿Cuánto cuesta desarrollar un marketplace a la medida en WordPress?
Entre 28 y 42 millones de pesos colombianos, o entre 7.000 y 10.500 dólares, para un proyecto con plugin y tema propios, arquitectura de URLs jerárquica, schema estructurado y cumplimiento normativo integrado. El rango depende de cuántas reglas de negocio propias tenga y de qué tan estricto sea el marco regulatorio del sector.
¿Por qué construir a la medida y no usar un plugin de directorio?
Los plugins de directorio resuelven bien los casos genéricos. Cuando necesitas verificación de identidad con custodia de documentos, URLs jerárquicas de tres niveles, niveles de visibilidad con vencimiento automático y validaciones normativas del lado del servidor, ninguno lo cubre. Terminas peleando contra el plugin en vez de construir.
¿Por qué WordPress y no Next.js o un framework moderno?
En este proyecto hicimos ese cambio y volvimos atrás. Next.js rinde mejor, pero el cliente no lo conoce y quedaba dependiendo del desarrollador para cada cambio de texto. WordPress bien construido le deja el control a él. El stack se elige por quién va a mantener el sistema, no solo por lo que rinde en un benchmark.
¿Por qué fallan las URL con placeholders en el slug de reescritura?
Porque WordPress interpreta los placeholders del tipo por ciento nombre por ciento de forma literal y genera reglas que buscan esa cadena de texto en la URL, no el valor de la taxonomía. Esas reglas nunca coinciden y el resultado es 404 en todo el tipo de contenido. La solución es construir las reglas explícitamente desde los slugs reales, cuidando el orden y usando lookahead negativo para que la paginación no se rompa.
¿Cuánto tarda un desarrollo de este tipo?
Entre cuatro y seis meses de trabajo efectivo para un alcance como el descrito. En este caso se alargó por los dos cambios de stack al inicio, que costaron unas semanas. El descubrimiento y el modelo de datos son la fase que más determina el resto: si se hace mal, se paga después en retrabajos.
¿Cómo se maneja el cumplimiento legal en un proyecto de vertical regulado?
Escribiéndolo dentro del código, no solo en los términos y condiciones. Validaciones del lado del servidor que no se pueden saltar manipulando el formulario, custodia de documentos sensibles en carpeta privada con registro de accesos, datos personales tratados con las restricciones que exige la norma, y canales de reporte con categorías críticas que no entran en la cola normal de moderación.
¿Qué no está incluido en el precio de desarrollo?
Hosting, dominio, revisión legal de los términos con un abogado del sector, constitución de la sociedad si aplica, registro de bases de datos ante la autoridad de protección de datos y el mantenimiento mensual posterior. En verticales regulados, la revisión legal no es opcional: es parte del costo real del proyecto.
¿Se puede convivir con Yoast SEO en un desarrollo a la medida?
Sí, y conviene. En este proyecto el plugin detecta si Yoast está activo: cuando lo está, desactiva su propio sitemap y robots.txt para no duplicar, y le agrega hooks a Yoast para que incluya el tipo de contenido nuevo. El schema estructurado propio se sigue emitiendo siempre, porque es específico del negocio y Yoast no lo cubre.
Contenido relacionado
del ecosistema Webhexup.
Llevo casi veinte años haciendo SEO técnico y desarrollo con marcas de Colombia y Estados Unidos. Los casos que publico incluyen los bugs que me costaron tiempo y las veces que le dije que no al cliente, porque un caso donde todo salió perfecto no le enseña nada a nadie. Y publico los precios, que casi nadie lo hace.
Escríbeme: LinkedIn · WhatsApp +57 313 682 9935
Perdió 11.861 páginas del índice de Google en 77 días: caso de estudio sobre OCH Group y la señal técnica que anticipó el colapso tres días antes.
36 min de lectura · Publicado el 22 de agosto de 2026 · Caso de estudio Webhexup Research
OCH Group, que opera comercialmente como Ochoa Consulting Holding SAS, es una firma colombiana de consultoría en contabilidad, auditoría, revisoría fiscal, peritaje y cumplimiento corporativo. Su sitio funciona como repositorio editorial de alto volumen: artículos técnicos, un archivo de normas y plantillas descargables que la comunidad contable colombiana usa a diario.
Cuando llega un trimestre con caída de doble dígito, la conversación suele irse hacia los sospechosos habituales: una actualización del algoritmo, competencia agresiva, contenido que envejeció. En este caso ninguna de esas explicaciones sobrevive al cruce de datos. La causa es técnica, está documentada en los propios informes de Search Console, y tiene una fecha de inicio bastante precisa.
Publico este análisis con autorización expresa del cliente porque el patrón que encontramos se repite en muchos sitios editoriales del mercado hispanohablante que crecieron rápido en volumen sin vigilar la capacidad técnica que ese volumen exige. La secuencia es reconocible, medible con herramientas gratuitas y, sobre todo, reversible.
- Metodología y alcance
- Los números del periodo sin interpretación
- La causa raíz: el colapso del índice
- El disparador: rendimiento móvil y presupuesto de rastreo
- Anatomía de las 29.513 páginas fuera del índice
- La segunda historia: la explosión en IA generativa
- Hallazgos principales del estudio
- Factores secundarios: estacionalidad y caducidad normativa
- Lo que sí está creciendo
- Limitaciones del estudio
- Discusión: qué generaliza más allá de este caso
- Plan de recuperación priorizado
- Preguntas frecuentes
Metodología y alcance
del estudio.
Este caso analiza una propiedad real con autorización expresa del cliente. El diagnóstico se construyó exclusivamente con datos de primera parte exportados de Google Search Console, sin herramientas de terceros ni estimaciones, para que cualquier lector pueda replicar el mismo procedimiento sobre su propia propiedad.
OCH Group, que opera comercialmente como Ochoa Consulting Holding SAS, es una firma colombiana de consultoría en contabilidad, auditoría, revisoría fiscal, peritaje y cumplimiento corporativo. Su sitio funciona como repositorio editorial de alto volumen: artículos técnicos, un archivo de normas y plantillas descargables dirigidas a la comunidad contable colombiana. El perfil es representativo de un segmento amplio de sitios editoriales profesionales del mercado hispanohablante.
Se exportaron seis informes de Google Search Console el 22 de agosto de 2026: rendimiento en búsqueda, rendimiento en funciones generativas de IA, rendimiento en Discover, cobertura de indexación, Core Web Vitals para móvil y Core Web Vitals para escritorio, más el informe de sitios con más enlaces. El conjunto abarca 1.605 consultas, 1.260 URL con rendimiento registrado, 86 días de serie diaria de indexación y 90 días de serie diaria de métricas de rendimiento.
Los informes de rendimiento comparan los últimos tres meses contra los tres meses inmediatamente anteriores, que es el corte que ofrece la herramienta por defecto. Las series diarias de cobertura y Core Web Vitals cubren desde el 23 de mayo hasta el 20 de agosto de 2026, lo que permite ubicar eventos en fechas concretas y establecer secuencias temporales entre informes distintos.
El análisis se ejecutó en cuatro pasos. Primero, cuantificación de las variaciones agregadas de cada informe por separado. Segundo, segmentación de las 1.260 URL por tipo de contenido y por carga estacional, aplicando reglas de clasificación sobre la estructura de las rutas. Tercero, cruce de las series diarias de cobertura y Core Web Vitals para calcular correlación de Pearson y detectar secuencias temporales. Cuarto, cruce del informe de funciones generativas con el de rendimiento para segmentar las URL por cuota de impresiones en IA y comparar su comportamiento.
La clasificación por tipo de contenido usó la estructura de rutas del sitio: repositorio de normas, documentos descargables, contenido en inglés, páginas corporativas, portada y blog editorial. La clasificación estacional marcó como tal toda URL cuya ruta contuviera términos asociados al ciclo tributario colombiano. Para el cruce con IA se filtraron las URL con más de 500 impresiones en el periodo actual y más de 20 clics en el anterior, con el fin de excluir del análisis las URL con volumen insuficiente para ser estadísticamente comparables.
Los números del periodo
sin interpretación.
Primero los datos crudos, sobre 1.260 URL y 1.605 consultas, comparando los últimos tres meses contra los tres anteriores.
| Métrica | Periodo anterior | Periodo actual | Variación |
|---|---|---|---|
| Clics | 39.260 | 24.324 | -38,0% |
| Impresiones | 3.221.942 | 2.261.654 | -29,8% |
| CTR agregado | 1,22% | 1,08% | -11,7% |
| Posición media ponderada | 7,22 | 8,04 | -0,82 |
| Páginas indexadas | 25.880 | 14.019 | -45,8% |
| Impresiones en funciones de IA | 16.666 | 418.378 | +2.410% |
Los clics caen más que las impresiones, lo que indica pérdida de exposición y de eficiencia de clic simultáneas. Esa brecha de ocho puntos entre ambas caídas es la primera pista del diagnóstico.
Hay un dato en la tabla que resuelve el caso de entrada: las páginas indexadas cayeron más que los clics. Cuando un sitio pierde tráfico por competencia o por una actualización del algoritmo, el índice se mantiene y lo que baja es la posición. Cuando pierde casi la mitad del índice, el problema es de otra naturaleza y se resuelve por otra vía.
Un segundo dato confirma la dirección. Las consultas de marca perdieron apenas 8,3% de clics, mientras las 1.600 consultas genéricas cayeron 53,2%. La demanda de OCH Group como firma está intacta. Lo que se rompió es la capacidad del sitio de aparecer ante quien todavía no la conoce.
El colapso del índice:
11.861 páginas desaparecidas.
El informe de cobertura muestra la caída con claridad incómoda. El 29 de mayo de 2026 el sitio tenía 25.880 páginas indexadas. El 14 de agosto tenía 14.019.
La caída no fue gradual. Dos eventos concretos concentran el 71% de la pérdida total de índice. Ese patrón escalonado descarta el desgaste natural y apunta a una decisión del sistema de rastreo.
La forma de la curva importa tanto como la magnitud. Una erosión gradual sugeriría contenido envejeciendo o competencia ganando terreno. Dos escalones verticales en fechas concretas indican otra cosa: que Google tomó una decisión sobre este sitio en esos dos momentos.
Rendimiento móvil y presupuesto
de rastreo: la secuencia.
Aquí está la parte del análisis que convierte una observación en diagnóstico. Al cruzar el informe de Core Web Vitals con el de cobertura, la secuencia temporal es difícil de leer como coincidencia.
Las dos series se mueven en espejo. Cuando las URL con rendimiento móvil deficiente suben, las páginas indexadas bajan, con un desfase de entre tres y ocho días.
| Fecha | Evento en Core Web Vitals | Evento en cobertura |
|---|---|---|
| 23 may | 0 URL con LCP deficiente | 25.491 páginas indexadas |
| 9 jun | 678 URL pasan a LCP superior a 4 s | Sin cambios todavía |
| 12 jun | 710 URL deficientes | -3.767 páginas desindexadas |
| 22 jun | 1.027 URL deficientes | Sin cambios todavía |
| 30 jun | 888 URL deficientes | -4.669 páginas desindexadas |
| 4 jul | 1.131 URL deficientes, máximo del periodo | Descenso sostenido posterior |
| 20 ago | 1.100 deficientes y 550 en zona de mejora | 14.019 páginas indexadas |
Por qué el rendimiento afecta a la indexación
La conexión no es que Google castigue las páginas lentas quitándolas del índice. El mecanismo es más prosaico y tiene que ver con economía de rastreo.
Googlebot asigna a cada sitio una capacidad de rastreo que depende, entre otros factores, de cuánto tarda el servidor en responder y de cuántos recursos consume procesar cada página. Cuando el tiempo de carga se degrada de forma generalizada, el rastreador reduce su ritmo para no saturar el servidor. Menos rastreo significa menos páginas revalidadas, y las páginas que no se revalidan durante un tiempo suficiente terminan cayendo del índice.
En un sitio de cuarenta mil URL esa reducción no se nota durante semanas. Cuando se nota, ya se perdieron miles de páginas de golpe, que es exactamente la forma escalonada que muestran los datos.
Anatomía de las 29.513 páginas
que están fuera del índice.
No todas las páginas fuera del índice son un problema. Algunas están excluidas correctamente y otras representan pérdida real. Esta es la composición exacta:
Las dos primeras categorías concentran el 89,6% del problema y requieren tratamientos completamente distintos.
Rastreada, actualmente sin indexar: 18.078 páginas
Es la categoría más grande y la más ambigua. Significa que Googlebot visitó la página, la procesó y decidió no incluirla. Las causas habituales son contenido considerado insuficiente o duplicado, páginas de paginación y archivo sin valor propio, o presupuesto de rastreo agotado antes de llegar a revalidarlas.
En un sitio con repositorio de normas y estructura de etiquetas extensa, buena parte de estas URL probablemente son páginas de archivo, paginación y taxonomías que nunca debieron competir por índice. La tarea aquí no es forzar su indexación sino decidir explícitamente cuáles deben existir y excluir el resto de forma limpia.
Excluida por noindex: 8.358 páginas
Esta categoría es intencional por definición: alguien puso la directiva. La pregunta es si esas 8.358 páginas están correctamente excluidas o si hay una regla demasiado amplia que arrastró contenido valioso.
Es el punto que revisaría primero, porque es el de corrección más rápida. Si una configuración de plugin aplicó noindex a una categoría completa de contenido útil, revertirlo es una tarea de horas con impacto en semanas.
404 y errores 4xx: 1.596 páginas
Mil quinientas noventa y seis URL que Google conoce y que devuelven error. Cada una representa enlaces internos rotos, autoridad que se pierde en el camino y presupuesto de rastreo malgastado. En un contexto de rastreo restringido, cada visita de Googlebot a un 404 es una visita que no se dedicó a revalidar una página real.
La explosión en IA generativa
que ocurre en paralelo.
Mientras el índice colapsaba, algo completamente distinto pasaba en otro informe. Las impresiones dentro de funciones generativas de IA pasaron de 16.666 a 418.378.
Ciento setenta y cuatro URL sin presencia previa en respuestas generadas la adquirieron durante el periodo. El crecimiento fue transversal a todos los países y dispositivos.
El crecimiento fue uniforme en toda la geografía: Colombia 2.479%, México 2.122%, Perú 1.988%, España 2.451%, Estados Unidos 4.564%. En escritorio 2.356% y en móvil 2.739%.
Cuando un patrón es tan homogéneo entre mercados y dispositivos, no significa que el contenido mejorara de golpe en todas partes. Significa que Google desplegó funciones generativas de forma masiva durante el periodo, y que el contenido de OCH quedó entre los seleccionados como fuente.
Hallazgos principales
del estudio.
Los siete hallazgos se presentan con identificador persistente y ancla propia, de modo que puedan citarse individualmente desde documentos externos o desde respuestas generadas por sistemas de IA que referencien este caso.
El sitio perdió 11.861 páginas de su índice en 77 días, un 45,8% del total, cayendo de 25.880 a 14.019 URL indexadas.
La caída no fue gradual sino escalonada: dos eventos concretos, el 12 y el 30 de junio de 2026, concentraron 8.436 páginas perdidas, es decir el 71% de toda la pérdida del periodo. Esa forma vertical descarta el desgaste natural por envejecimiento de contenido y apunta a una decisión del sistema de rastreo en fechas específicas.
La correlación entre URL con LCP deficiente en móvil y páginas indexadas es de -0,797, con cada colapso ocurriendo entre tres y ocho días después de un salto en el rendimiento deficiente.
El 9 de junio, 678 URL móviles pasaron de rendimiento correcto a LCP superior a cuatro segundos. Tres días después se desindexaron 3.767 páginas. El 22 de junio la cifra de URL deficientes subió a 1.027, y ocho días más tarde se desindexaron 4.669 páginas adicionales. La secuencia se repite en ambos eventos con el mismo orden y un desfase compatible con los ciclos de revalidación de rastreo.
En los 90 días analizados ninguna URL del sitio calificó como buena en Core Web Vitals, ni en móvil ni en escritorio.
El conteo de URL en verde permanece en cero durante toda la serie en ambos dispositivos. En móvil hay 1.100 URL con LCP superior a cuatro segundos y 550 en zona de mejora. En escritorio, 1.650 URL con LCP superior a 2,5 segundos y 1.100 con CLS por encima de 0,1. No es un problema localizado en plantillas concretas sino una condición general del sitio.
Solo el 32,2% de las URL que Google conoce del dominio están indexadas: 14.019 de 43.532.
De las 29.513 páginas excluidas, el 61,3% corresponde al estado rastreada sin indexar (18.078 URL) y el 28,3% a exclusión por etiqueta noindex (8.358 URL). Las dos categorías concentran el 89,6% del problema y requieren tratamientos opuestos: la primera exige decidir qué debe existir, la segunda verificar si la exclusión fue intencional.
Las impresiones en funciones generativas de IA crecieron 2.410% en el mismo periodo, pasando del 0,52% al 18,50% de las impresiones totales del sitio.
El crecimiento fue transversal a geografías y dispositivos: Colombia 2.479%, México 2.122%, España 2.451%, Estados Unidos 4.564%, escritorio 2.356% y móvil 2.739%. La uniformidad del patrón indica despliegue de producto por parte de Google más que mejora súbita del contenido. Ciento setenta y cuatro URL sin presencia previa en respuestas generadas la adquirieron durante el periodo.
Las URL con mayor presencia en respuestas generadas cayeron 11,5 puntos menos que las de baja presencia: 36,0% frente a 47,5%.
Sobre las URL con volumen comparable, las que tienen al menos el 20% de sus impresiones dentro de funciones de IA perdieron 36,0% de clics y mantienen un CTR de 1,63%. Las que tienen menos del 10% perdieron 47,5% y su CTR es de 0,44%. La relación es correlacional y no causal: la interpretación más sólida es que la presencia en IA no produce la resiliencia sino que señala el mismo perfil de contenido específico y completo que resiste mejor cualquier cambio de rastreo o de algoritmo.
El contenido con carga estacional tributaria representa el 13% de las URL del sitio pero concentró el 35,3% de la pérdida total de clics.
Las 166 URL clasificadas como estacionales perdieron 63,7% de sus clics frente al 31,2% del contenido perenne, aportando 5.277 de los 14.936 clics perdidos. Este factor es cíclico y esperable en el vertical de consultoría contable colombiana, donde el primer cuatrimestre concentra la temporada de información exógena y declaración de renta. Su presencia obliga a comparar contra el mismo trimestre del año anterior y no contra el trimestre inmediatamente previo.
Además de caer menos, las URL con alta presencia en IA mantienen un CTR casi cuatro veces superior. La correlación no es causal, pero la dirección es inequívoca.
Estacionalidad y caducidad
normativa: el resto de la caída.
El colapso de indexación explica la mayor parte del problema, pero no todo. Hay dos factores adicionales que amplifican la caída y conviene separar, porque uno es normal y el otro es una decisión estratégica pendiente.
El ciclo tributario colombiano
El periodo anterior abarca de febrero a mayo, que concentra la temporada de información exógena, los decretos tributarios de comienzo de año y el arranque de la declaración de renta. El periodo actual va de mayo a agosto, temporada baja para ese contenido.
| Segmento | URL | Clics anteriores | Clics actuales | Variación |
|---|---|---|---|---|
| Contenido estacional o tributario | 166 | 8.279 | 3.002 | -63,7% |
| Contenido perenne | 1.094 | 30.981 | 21.322 | -31,2% |
Casos concretos: el artículo sobre información exógena pasó de 1.530 a 71 clics; la ficha del Decreto 0188 pasó de 788 a cero; el artículo sobre el Decreto 1474 pasó de 581 a 6; la ficha del Decreto 0182 pasó de 365 a cero.
Esto no es un problema sino el funcionamiento normal del sector. La comparación correcta para un sitio de consultoría contable colombiana no es contra el trimestre inmediatamente anterior sino contra el mismo trimestre del año previo.
La caducidad del repositorio normativo
OCH Group mantiene un archivo de normas con 478 URL: decretos, resoluciones, sentencias y conceptos. Captura muy bien el tráfico inmediato cuando sale una norma nueva, y explica varias de las mayores ganancias del trimestre. Pero ese tráfico tiene vida corta: 597 consultas pasaron de tener clics a tener cero, sumando 2.531 clics perdidos.
Lo que sí está creciendo
en medio de la caída.
Un diagnóstico honesto tiene que incluir lo que funciona, y en este caso hay cuatro señales claras.
El contenido en inglés es el único segmento en crecimiento
Las 16 URL bajo la ruta en inglés crecieron 73,2% en clics, pasando de 224 a 388, mientras todos los demás segmentos caían. El artículo sobre la debilidad del dólar frente al peso pasó de 36 a 301 clics y capturó 15.255 impresiones en funciones de IA, el 66,2% de sus impresiones totales.
Es la mayor oportunidad no explotada del sitio: 16 URL frente a más de mil en español, con el mejor comportamiento relativo de toda la propiedad.
Las plantillas descargables son el activo más eficiente
Las 146 URL de documentos descargables cayeron solo 14,1%, la menor caída de cualquier segmento, con un CTR de 3,51%. La plantilla de certificación de composición accionaria mantiene un CTR del 8,90% y capturó 5.353 impresiones en IA.
Son activos de intención transaccional pura que la comunidad contable usa como herramienta de trabajo. Merecen tratamiento de producto, no de anexo.
La portada mejoró su eficiencia de forma notable
La página principal perdió 16,6% de clics pero subió su CTR de 4,10% a 6,26%. Combinado con la resistencia de las consultas de marca, que cayeron apenas 8,3%, indica que la percepción de OCH Group como firma se mantiene sólida.
460 consultas nuevas aparecieron en el periodo
Con 882 clics ganados. Varias con posiciones excelentes: la Resolución 0941 de 2026 del IGAC en posición 1,76 con CTR del 28,2%, y la sentencia 26808 en posición 1,14 con CTR del 41,1%. La capacidad de capturar novedad normativa sigue funcionando bien.
Y dos vacíos que conviene nombrar
Discover está prácticamente sin explotar. El informe registra una sola URL con 82 impresiones y cero clics en todo el trimestre. Para un sitio con este volumen editorial y esta autoridad temática, es un canal entero sin activar.
El perfil de enlaces es estructuralmente débil. Solo 59 dominios referentes con 152 páginas de enlace. El 73% de esos dominios aporta un único enlace, y cinco son propiedades de Yandex sin valor real. Hay señales de autoridad valiosas (Ámbito Jurídico, Actualícese, Camacol, INCP, Supersociedades, El Colombiano, Deloitte) pero el volumen total es bajo para el tamaño del sitio. Ese es el techo estructural que limita la recuperación de posiciones incluso después de resolver lo técnico.
Limitaciones del estudio
y qué queda sin resolver.
Un diagnóstico honesto declara lo que no puede concluir. Estas son las cinco limitaciones que acotan el alcance de los hallazgos anteriores.
La relación de -0,797 entre rendimiento deficiente e indexación es estadísticamente fuerte y la secuencia temporal es consistente en ambos eventos, pero no constituye prueba causal. Un tercer factor no observado podría estar produciendo ambos efectos: por ejemplo, un cambio de infraestructura que simultáneamente degradara el rendimiento y afectara la respuesta del servidor al rastreador. El evento del 9 de junio sigue sin identificarse.
El corte de tres meses contra tres meses que ofrece Search Console por defecto compara temporada alta con temporada baja en este vertical. El Hallazgo 7 cuantifica ese efecto, pero la separación entre ciclo y tendencia solo puede cerrarse con una serie de dieciséis meses que permita comparar contra el mismo trimestre del año anterior. Esa exportación no estaba disponible al momento del análisis.
La segmentación por tipo de contenido y por carga estacional se hizo aplicando reglas sobre la estructura de las URL, no mediante revisión manual de cada pieza. El método es replicable y consistente, pero introduce error de clasificación en los casos límite: un artículo perenne con un término tributario en su ruta queda marcado como estacional y viceversa.
El estudio mide clics, impresiones e indexación. No incorpora datos de comportamiento en el sitio ni de conversión a contacto comercial. Una caída del 38% en clics puede convivir con estabilidad en leads si el tráfico perdido era de baja intención, escenario perfectamente posible dado que buena parte de lo perdido era contenido normativo de consulta puntual.
Los hallazgos describen una propiedad concreta en un periodo concreto. El mecanismo propuesto en el Hallazgo 2 es coherente con la documentación pública sobre presupuesto de rastreo, pero validar que el patrón se generaliza requiere replicación en otras propiedades con perfil comparable. La sección siguiente separa explícitamente lo que es específico de este caso de lo que es razonablemente extrapolable.
Qué generaliza
más allá de este caso.
La utilidad de un caso de estudio está en distinguir lo circunstancial de lo estructural. Estas son las tres lecturas que considero transferibles a otros sitios editoriales, y las dos que no lo son.
Lo que sí generaliza
La indexación es un indicador adelantado que casi nadie vigila. En este caso la caída de páginas indexadas precedió y superó en magnitud a la caída de clics. Cualquier sitio con volumen editorial debería tener la serie de indexación en su reporte mensual, no solo la de tráfico. Un escalón vertical en esa serie es señal de intervención inmediata, mucho antes de que el tráfico lo refleje.
La proporción entre indexadas y URL conocidas es más diagnóstica que el número absoluto. Un sitio puede tener quince mil páginas indexadas y estar perfectamente sano, o estar en crisis. Lo que informa es qué porcentaje del total conocido representa. Por debajo del 50% conviene auditar; en el 32,2% de este caso, la arquitectura está generando URL que compiten por un presupuesto que no alcanza.
La cuota de impresiones en IA funciona como indicador indirecto de calidad de contenido. Es el hallazgo más aprovechable del estudio. Search Console entrega gratis una métrica que separa el contenido que los sistemas de recuperación consideran fuente confiable del que no, y ese corte predice resiliencia. Usarla como diagnóstico de calidad, y no solo como métrica de visibilidad, es un uso que hoy prácticamente nadie le está dando.
Lo que no generaliza
Las magnitudes concretas son específicas de este caso. El 45,8% de pérdida de índice, la correlación de -0,797 y el desfase de tres a ocho días describen esta propiedad en este periodo. Otro sitio con degradación de rendimiento similar puede mostrar respuestas muy distintas según su autoridad acumulada, su frecuencia de rastreo previa y su arquitectura.
El peso de la estacionalidad depende del vertical. El 35,3% de caída atribuible al ciclo tributario es propio de la consultoría contable colombiana, con su calendario de exógena y renta. Un sitio de comercio electrónico, salud o tecnología tendrá ciclos completamente distintos, y aplicar este porcentaje como referencia sería un error de lectura.
Plan de recuperación
priorizado por impacto.
El orden importa más que la lista. Producir contenido nuevo mientras el rastreo está restringido es tirar recursos: las páginas nuevas entrarán a competir por un presupuesto que ya no alcanza para las existentes.
Fase 1 · Primeros 30 días: rendimiento
- Diagnosticar qué cambió alrededor del 9 de junio: despliegue, plugin nuevo, cambio de plantilla, migración de servidor o script de terceros añadido
- Atacar el LCP móvil de las 1.100 URL en rojo: optimización de imágenes, carga diferida correcta, revisión de recursos bloqueantes
- Resolver el CLS de las 1.100 URL en escritorio, que normalmente se soluciona reservando dimensiones de imágenes y contenedores
- Verificar tiempo de respuesta del servidor bajo carga de rastreo, que es la variable que Googlebot usa para decidir su ritmo
Fase 2 · Días 30 a 60: higiene de rastreo
- Auditar las 8.358 páginas con noindex y confirmar que la exclusión es intencional en todos los casos
- Resolver las 1.152 URL con 404: redirigir las que tienen equivalente, corregir los enlaces internos que apuntan a ellas
- Revisar las 444 URL con error 4xx y las 12 con 403
- Resolver las 231 páginas duplicadas sin canónica declarada
- Recuperar de forma prioritaria el activo de puc, que valía 16.449 impresiones trimestrales
Fase 3 · Días 60 a 90: arquitectura
- Clasificar las 18.078 páginas rastreadas sin indexar entre las que deben recuperarse y las que deben excluirse explícitamente
- Consolidar taxonomías y paginación que estén generando URL sin valor propio
- Reforzar el enlazado interno hacia las páginas que se quiere recuperar, que es la señal más directa de prioridad para el rastreador
- Enviar sitemaps segmentados por tipo de contenido para facilitar el seguimiento de la recuperación
Fase 4 · Meses 3 a 6: crecimiento
- Escalar el contenido en inglés, que es el único segmento en crecimiento y el de mejor comportamiento en IA
- Tratar las plantillas descargables como producto, con páginas de aterrizaje propias y contexto editorial alrededor
- Activar Discover, hoy en cero, con formato editorial y visual adecuado
- Trabajo de relaciones públicas digitales para ampliar el perfil de enlaces más allá de los 59 dominios actuales
- Añadir capas de contenido perenne alrededor de cada norma del repositorio para que el activo no muera cuando pasa la novedad
Preguntas frecuentes
sobre este caso.
¿Qué le pasó al tráfico orgánico de OCH Group?
Entre mayo y agosto de 2026 perdió el 38% de sus clics orgánicos y el 29,8% de sus impresiones. La causa principal fue la pérdida de 11.861 páginas del índice de Google, un 45,8% del total, que cayó de 25.880 a 14.019 URL indexadas. La caída de clics es consecuencia de la caída de indexación, no de un problema de posicionamiento o de demanda.
¿Por qué se desindexaron tantas páginas de golpe?
El análisis cruzado apunta a una restricción del presupuesto de rastreo provocada por la degradación del rendimiento móvil. La correlación entre URL con LCP deficiente y páginas indexadas es de -0,797, y cada colapso de indexación ocurrió entre tres y ocho días después de un salto en las URL con rendimiento deficiente.
¿Puede recuperarse un sitio que perdió el 45% de su índice?
Sí, y normalmente más rápido de lo que se teme. Las páginas que ya estuvieron indexadas conservan historial y señales acumuladas, por lo que vuelven al índice mucho antes que contenido nuevo. Resolviendo la causa técnica en los primeros treinta días, la recuperación de indexación suele empezar a verse entre las semanas seis y diez.
¿Los Core Web Vitals afectan realmente a la indexación?
No de forma directa como factor de ranking, sino a través del presupuesto de rastreo. Googlebot ajusta su ritmo según el tiempo de respuesta del servidor y el coste de procesar cada página. Cuando el rendimiento se degrada de forma generalizada, el rastreador reduce su actividad, menos páginas se revalidan y las que llevan tiempo sin revalidarse salen del índice.
¿Aparecer en respuestas de IA reduce los clics de una página?
Los datos de este caso apuntan en dirección contraria. Las URL con al menos el 20% de sus impresiones dentro de funciones de IA cayeron 36% en clics, mientras las que tienen menos del 10% cayeron 47,5%. Además mantienen un CTR casi cuatro veces superior. La interpretación más sólida es que la presencia en IA no causa la resiliencia sino que la señala.
¿Cuánto de la caída de tráfico fue estacionalidad?
El 35,3%. El contenido tributario y normativo con fecha, que representa solo el 13% de las URL del sitio, concentró 5.277 de los 14.936 clics perdidos. El periodo anterior incluía la temporada de información exógena y declaración de renta en Colombia, mientras el actual es temporada baja.
¿Qué significa el estado Rastreada, actualmente sin indexar?
Que Googlebot visitó la página, la procesó y decidió no incluirla en el índice. Las causas habituales son contenido considerado insuficiente o duplicado, páginas de archivo y paginación sin valor propio, o presupuesto de rastreo agotado antes de revalidarlas. En este caso son 18.078 páginas, el 61,3% de todas las excluidas.
¿Por qué una consulta puede pasar de 16.000 impresiones a cero?
Cuando las impresiones caen a cero absoluto y no simplemente descienden, casi siempre indica que la URL salió del índice, no que perdió posiciones. Una pérdida de posición reduce impresiones progresivamente; una desindexación las corta de golpe.
¿En qué orden hay que atacar un problema de indexación?
Rendimiento primero, higiene de rastreo después, arquitectura en tercer lugar y contenido al final. Producir contenido nuevo mientras el rastreo está restringido es contraproducente, porque las páginas nuevas compiten por un presupuesto que ya no alcanza para las existentes.
¿Cómo detecto si mi sitio tiene el mismo problema?
Revisa tres cosas en Search Console. Primero, la evolución de páginas indexadas en el informe de cobertura durante los últimos seis meses buscando escalones verticales. Segundo, la proporción entre indexadas y total de URL conocidas: por debajo del 50% merece atención. Tercero, el informe de Core Web Vitals buscando si hay URL en verde y cuándo empezaron a degradarse. Si las fechas de degradación preceden a las caídas de indexación, tienes el mismo patrón.
Contenido relacionado
del ecosistema Webhexup.
Cerca de 20 años trabajando en SEO técnico con marcas de Colombia y Estados Unidos. Los casos que publico en Webhexup Research salen de datos reales de propiedades reales, con autorización expresa del cliente, porque un diagnóstico documentado enseña más que cualquier lista de buenas prácticas. Este análisis cruzó seis informes distintos de Search Console para llegar a una causa que ningún informe aislado mostraba.
Contacto: LinkedIn · WhatsApp +57 313 682 9935