Respuesta breve
Las directivas de indexación las genera el código que renderiza las páginas, así que se rompen como código. Un Disallow de preproducción o un noindex heredado sale a producción sin error y aflora seis semanas después.
Tres archivos deciden si una página existe
Hay tres puertas que una página cruza antes de que el posicionamiento sea siquiera una conversación, y ninguna de ellas mide lo bien escrita que está. robots.txt decide si un rastreador puede pedir la URL; la meta robots, o la cabecera X-Robots-Tag, decide si la respuesta ya descargada puede quedarse en el índice; el sitemap declara qué direcciones considera canónicas el propio sitio y quiere que se descubran rápido. Las tres son binarias y ninguna admite matices: o se pasa o no se pasa. Un texto excelente puede caer en las tres a la vez y seguir abriéndose con toda normalidad en el navegador de quien lo escribió.
El problema práctico no es qué hacen esos tres archivos, sino dónde viven. No son casillas de un panel de marketing que alguien de contenidos pueda repasar el lunes por la mañana. En cualquier stack moderno nacen durante la compilación, del mismo código que pinta la página: la ruta exporta su objeto de metadatos, el sitemap sale de una función que consulta la base de datos, robots.txt se emite distinto según el entorno y las canónicas se arman a partir de una constante con la URL base. Es decir: los edita, los refactoriza y los rompe un programador. Y ese programador jamás ha oído la expresión presupuesto de rastreo, ni tiene ninguna obligación de haberla oído.
La consecuencia es que las reglas de indexación se comportan como código, porque son código: tienen versiones, ramas y conflictos de fusión, y cambian de significado según qué variable de entorno estuviera definida el día del despliegue. Basta una actualización de dependencias que mueve un valor por defecto, o un helper que alguien traslada a un layout compartido para no repetirlo tres veces. Nadie anuncia ese cambio como un cambio de SEO, porque en el diff no lo parece en absoluto. Y, como todo código sin pruebas, derivan despacio hacia el estado en que las dejó el último commit con prisa.
Conviene señalar que el catálogo no trata esto como un consejo suelto, sino como un servicio con nombre y precio. «Mapa del sitio, robots.txt y protección de indexación en CI» vive en la categoría Indexación, con dificultad Principiante, ⏱ 2–5 horas y 5 000 – 20 000 ₽ o $80 – $300. Esa etiqueta de dificultad es honesta y algo incómoda al mismo tiempo. Nada de lo que hay aquí es difícil. Sencillamente no figura en la lista de tareas de nadie hasta que el tráfico ya se ha ido.
Cómo desaparece una sección sin que nadie toque el SEO
El primero es el bloqueo de preproducción que se escapa. Un equipo cierra el entorno de pruebas con un Disallow general —razonable: no quiere competir consigo mismo por las mismas consultas—, ese robots.txt se genera desde una plantilla y el entorno se lee de una variable; un día el despliegue sale con la variable equivocada, o sin ella, y cae en el valor por defecto que parecía el prudente. Producción sirve entonces un bloqueo de sitio completo, con un archivo impecablemente válido, sin error y sin build roja. Lo habitual es enterarse semanas más tarde por las impresiones, nunca por el código.
El segundo es un noindex que se sale de su jaula. Alguien lo pone durante el desarrollo sobre un único tipo de página: un filtro nuevo, un archivo paginado, un paso de compra a medio terminar. Meses después tres rutas necesitan el mismo envoltorio, la condición acaba refactorizada dentro de un componente de layout compartido y desde ese commit alcanza a todas las rutas hijas. La sección sigue viva, enlazada y bonita, y fuera del índice en absoluto silencio; ninguna prueba se pone roja, porque nadie escribe pruebas para directivas de indexación.
El tercero es un sitemap que se desploma. La generación consulta una fuente de datos en tiempo de compilación y filtra los borradores, hasta que alguien renombra el campo de estado o añade una columna cuyo valor por defecto es nulo. A partir de ahí, el filtro que excluía lo no publicado excluye casi todo. La compilación termina en verde y la salida es XML bien formado que valida contra el esquema. Contiene once URL donde antes había cuatro mil, y ningún paso del pipeline entiende que eso merezca un comentario.
El cuarto es una canónica que apunta al host equivocado, porque la URL base cae en el dominio de preproducción cuando falta su variable de entorno. Cada canónica del sitio pasa entonces a señalar un host al que el rastreador no llega o —bastante peor— al que sí llega. Ninguno de estos cuatro casos es un supuesto exótico construido para ilustrar un argumento. Los cuatro son refactorizaciones normales, de un martes por la tarde, que pasan la revisión de código sin levantar una ceja. El revisor mira la lógica del componente; el efecto sobre el rastreador no entra en su campo de visión.
La avería que llega seis semanas tarde
Una prueba unitaria falla ahora mismo, delante de quien la ha roto y con el número de línea señalado. Una regla de indexación rota falla según el calendario del rastreador: el bot tiene que volver, releer robots.txt, pedir de nuevo las páginas afectadas, convencerse de que la directiva es estable y no un accidente pasajero, y solo entonces retirar direcciones del índice. Nada de eso ocurre de golpe, así que las posiciones no desaparecen, se erosionan. El tráfico dibuja una curva perfectamente confundible con la estacionalidad, o con la campaña que un competidor lanzó justo ese mes.
Cuando la pérdida llega a un panel, el hilo causal ya está cortado. Han entrado decenas de commits desde entonces y nadie recuerda haber tocado una plantilla de robots, porque del lado del desarrollo aquello fue una línea de configuración dentro de una pull request mucho mayor. La investigación arranca en analítica y pasa por el seguimiento de posiciones. Llega al archivo culpable solo si a alguien se le ocurre compararlo con el que había el trimestre anterior. Y no hay con qué compararlo si nadie guardó nunca ese archivo.
Toda la defensa de meter la comprobación en el pipeline cabe en esa asimetría. Una prueba que corre en cada pull request convierte seis semanas de trabajo forense en una build roja con un nombre de archivo al lado: quien introdujo el cambio todavía lo tiene entre las manos y todavía conserva el contexto cargado, así que resolverlo cuesta aproximadamente un minuto. El mismo defecto descubierto desde un informe de tráfico cuesta un trimestre. La diferencia no está en la dificultad de la reparación, sino en el tiempo transcurrido entre la causa y su descubrimiento.
Nada de esto es un argumento sobre monitorización, y la distinción importa. La monitorización avisa de que el sitio ya está desindexado e invita a reaccionar; una afirmación en CI avisa de que el despliegue habría desindexado el sitio, antes de que nadie fuera del equipo llegue a verlo. Es la misma información entregada al otro lado de la frontera del lanzamiento, que resulta ser el único lado barato. Monitorizar la indexación sigue haciendo falta, pero como segunda línea y no como primera noticia.
Qué afirma una comprobación de indexación antes de dejar pasar un despliegue
Las comprobaciones que de verdad aguantan son aburridas y muy concretas. El robots.txt que sale de la build de producción no debe contener un bloqueo general y debe referenciar la URL del sitemap. Lo más útil viene después: debe coincidir con una instantánea del archivo guardada en el repositorio. Así cualquier cambio se convierte en un diff que alguien revisa, en lugar de un efecto colateral invisible de otra cosa. El cambio deliberado actualiza la instantánea y pasa; el accidental no la actualiza y rompe la build, y distinguir esos dos casos es todo lo que se le pide a la comprobación.
Al sitemap no le basta con validar: hay que contarlo y muestrearlo. Afirma un número mínimo de URL en relación con la última build correcta, para que un desplome de cuatro mil entradas a once sea un fallo y no un despliegue. Afirma que una muestra aleatoria de las direcciones listadas devuelve realmente un 200, que todas son absolutas y usan el host canónico, y que el archivo se parsea y respeta los límites de tamaño y de número de entradas. Cada una de esas afirmaciones ocupa una línea de prueba. Después funcionan durante años sin mantenimiento.
Las plantillas, por su parte, se escanean en busca de directivas que no deberían llevar: ningún tipo de página renderiza noindex salvo que figure en una lista blanca guardada en el repositorio —pasos de compra, área de cliente, resultados del buscador interno, lo que el equipo haya decidido de verdad—. Esa lista blanca es el entregable real de todo el trabajo, porque convierte una convención invisible en una declaración de intenciones escrita y revisable. Desde que existe, la pregunta por qué esta página lleva noindex tiene siempre una respuesta que alguien redactó a propósito.
El catálogo enuncia el alcance sin adornos: ⏱ 2–5 horas, 5 000 – 20 000 ₽ o $80 – $300, dificultad Principiante, categoría Indexación. Su descripción promete el resultado en el mismo registro sobrio: los motores ven exactamente las páginas que necesitan, encuentran rápido las nuevas y no gastan presupuesto de rastreo en basura, mientras que un sitio cerrado por accidente en una publicación deja de salirse del índice sin que nadie lo note. No hay una sola promesa de posiciones en esa descripción, y esa es exactamente la honestidad que conviene exigir.
Qué le dice realmente el micromarcado a una máquina
El HTML describe dónde está cada cosa; no describe qué es cada cosa. Para el árbol del documento, un precio, un teléfono y una referencia de producto son el mismo objeto: nodos de texto dentro de contenedores. Cualquier significado que una máquina saque de ahí es una inferencia sobre una maquetación pensada para ojos humanos, y las inferencias fallan. El micromarcado de Schema.org, normalmente en JSON-LD dentro de una etiqueta script, suprime ese paso declarando los tipos: esto es un Product, esto su precio, esto el código de moneda, esto el autor, esto la fecha de publicación.
Esa explicitud tiene dos consumidores que la aprovechan de maneras muy distintas. Los buscadores la leen para decidir si un resultado es apto para una presentación enriquecida: una valoración, un precio con disponibilidad, migas de pan, la fecha de un evento, un acordeón de preguntas bajo el enlace azul. Los modelos de lenguaje, que consumen la página como texto plano, reciben una afirmación inequívoca sobre qué entidad se describe y cómo se relaciona con las demás, en vez de reconstruirla desde una jerarquía visual que no llegan a ver. Los dos leen el mismo archivo, en el mismo formato, con propósitos que no se parecen en nada.
La descripción del catálogo dice eso y no dice nada más: los motores de búsqueda y los modelos de IA empiezan a comprender con claridad qué producto, empresa, autor y evento tienes, y aumentan tanto los fragmentos enriquecidos como la posibilidad de acabar citado en una respuesta de IA. El verbo que hay que subrayar es aumentar. No garantizar, no desbloquear, no posicionar. La distancia entre elegibilidad y resultado es el contenido íntegro del apartado siguiente.
El alcance figura así: «Micromarcado de Schema.org con verificación en CI», categoría Datos estructurados, dificultad Con experiencia, ⏱ 4 a 8 horas para 5 a 7 plantillas, 8 000 – 35 000 ₽ o $120 – $500. Conviene fijarse en la unidad, que es la plantilla y no la página. Marcas una vez la plantilla de producto y el marcado lo heredan todos los productos del sitio. Por esa misma vía, un solo error de plantilla se propaga a todo el catálogo en un único despliegue.
Lo que el marcado no hará, por mucho que escribas
No posicionará la página. El marcado es un formato de descripción, no una señal de calidad, y duplicarlo no duplica ninguna otra cosa. Una página con Organization, Product y BreadcrumbList impecables y nada que merezca leerse debajo se queda exactamente donde estaba. Los equipos que lo tratan como una palanca se sorprenden de verdad cuando la gráfica no se mueve, y esa sorpresa es un fallo de las expectativas fijadas durante la venta, no un fallo del trabajo técnico. Vender marcado como método para subir posiciones es firmar una reclamación con un trimestre de retraso.
No arreglará la indexación, y el orden entre ambas cosas no es negociable. Si robots.txt bloquea la URL, nadie llega a leer el JSON-LD, porque la respuesta ni siquiera se solicita; si un layout compartido arrastra un noindex, el marcado se descarta junto con la página que describía. De ahí que el servicio barato de indexación vaya primero en cualquier secuencia sensata: marcado sobre una página que no puede indexarse es un archivo perfectamente formado que nadie abrirá jamás. El orden no es cuestión de gusto ni de presupuesto, sino de qué depende técnicamente de qué.
No creará una elegibilidad que el contenido no se haya ganado. Los resultados enriquecidos vienen con requisitos propios: una reseña necesita una reseña real, una receta necesita ingredientes y pasos reales, un bloque de preguntas necesita preguntas efectivamente respondidas en la página visible. Marcar lo que el visitante no encuentra en pantalla no es optimizar, es abrir una discrepancia entre la versión legible por máquinas y la legible por personas. Y la discrepancia es lo único de toda esta área que conlleva riesgo de acción manual.
Tampoco sobrescribirá la página. Cuando el marcado y el contenido visible se contradicen, el visible se toma como verdad y el marcado es lo que se ignora; si la contradicción es sistemática, se desconfía de él en todo el dominio. El modelo mental útil es el pie de foto: uno bueno explica qué estás mirando, y uno que describe otra fotografía distinta es peor que no poner ninguno. Por eso el marcado se comprueba contra dos cosas a la vez, la validez del esquema y lo que de verdad sale en pantalla.
El marcado se pudre porque es una copia de datos que cambian
El JSON-LD es una proyección de tus datos, no una descripción de tu página. La plantilla de producto lee precio, moneda, disponibilidad, referencia y número de valoraciones de los mismos objetos que usa el HTML. Después los reemite en un segundo formato que vive dentro de una etiqueta que nadie mira. Quedan dos representaciones de los mismos hechos, producidas por dos caminos de código distintos, y solo una la revisa un ser humano todos los días. No cuesta adivinar cuál deja de coincidir en silencio.
Los modos de fallo son grises y constantes. Tras un cambio de localización, la moneda empieza a llegar como símbolo en lugar de código ISO. La disponibilidad deja de ser InStock y pasa a ser una cadena traducida; una fecha pierde su desplazamiento horario en una refactorización de la serialización; el autor se convierte de objeto en una simple cadena con un nombre después de migrar el gestor de contenidos. Ninguno de esos cambios rompe nada visible para una persona. Todos producen marcado que sigue parseándose como JSON impecable y ya no valida como Schema.org, que es la peor combinación posible.
Por eso el catálogo mete la verificación dentro del nombre del servicio, en vez de venderla como un extra posterior. El paso de CI renderiza cada plantilla marcada con datos reales, extrae el JSON-LD de la salida y lo valida contra las propiedades obligatorias y recomendadas del tipo declarado; si falta una obligatoria, la build cae. La comprobación se ejecuta en cada pull request mientras exista el repositorio, no una sola vez durante la semana de entrega. La distinción es de fondo: al marcado no lo rompe el día de la entrega, lo rompe el despliegue número cien.
De cinco a siete plantillas es una cifra realista para la mayoría de sitios: portada, producto o servicio, categoría o listado, artículo, y una página de organización o contacto. Esa lista cubre casi todo lo que un buscador o un modelo necesita identificar. Con ⏱ 4 a 8 horas para 5 a 7 plantillas, la aritmética que cualquier lector puede rehacer —ofrecida como ejemplo de cómo se reparte la horquilla, no como medición de nada— cae entre aproximadamente media hora y hora y media por plantilla. Eso es más o menos lo que cuesta escribir bien un tipo y cablear la afirmación de prueba que lo vigilará después.
Los rastreadores de IA leen un sitio distinto del que ves tú
Ahora hay dos audiencias y plantean dos preguntas de acceso separadas. Con los buscadores clásicos llevamos décadas negociando y su comportamiento está documentado hasta el detalle. Los rastreadores de IA son más nuevos y mucho más variados. Unos descargan páginas en masa para corpus de entrenamiento, otros recuperan un puñado de documentos en el momento de responder, otros piden una sola página porque un usuario acaba de preguntar justo por esa empresa. Llegan con sus propios user-agent, respetan robots.txt en grados distintos y en su mayoría no ejecutan JavaScript.
Esa última cláusula es la que sale cara, y casi siempre se descubre tarde. Un sitio renderizado íntegramente en el cliente devuelve un documento cáscara con un div raíz vacío a cualquier cosa que no arranque un motor de navegador completo. Una persona ve una página entera; un recuperador ve un título, un esqueleto de carga y nada más. Ninguna disciplina de marcado ni higiene de sitemap compensa eso, porque el contenido nunca estuvo en la respuesta que realmente se sirvió. Comprobarlo lleva un minuto: pide tu propia página sin ejecutar scripts y mira qué queda dentro.
La decisión de acceso es, en el fondo, una decisión de negocio, y no hay una respuesta correcta que valga para todos. Hay quien quiere el máximo alcance en respuestas de IA y lo abre todo a conciencia; hay quien prefiere la documentación legible y las páginas de precios fuera de los corpus masivos. Y hay quien rechaza los rastreadores de entrenamiento pero deja pasar al agente que recupera una página precisamente porque un cliente ha preguntado por ella. robots.txt sabe expresar las tres posturas, agente por agente; la mayoría de los sitios no expresa ninguna.
llms.txt es la convención emergente del otro lado del mismo problema: un mapa en texto plano en la raíz que declara qué es el sitio y qué página contiene la explicación canónica de cada tema, para que un lector guiado por modelos no tenga que deducirlo del menú. El catálogo lo recoge como «Preparando un sitio web para rastreadores de IA: robots.txt, llms.txt, renderizado», categoría Infraestructura de IA, dificultad Principiante, ⏱ 4–8 horas, 10 000 – 35 000 ₽ o $150 – $450. Su descripción añade el punto que más sacude al propietario: por primera vez ve quién le está quitando qué.
El orden que detiene primero la hemorragia
Ordena por dependencias, no por ambición y desde luego no por precio. La protección de la indexación va primero porque todo lo demás está condicionado a ella. El marcado, el acceso de la IA, la inversión en contenido y el enlazado interno valen exactamente cero sobre una URL bloqueada o con noindex. Encima es la más barata de las tres, 5 000 – 20 000 ₽ o $80 – $300, y la más corta, ⏱ 2–5 horas. Con esas cifras delante, la excusa habitual para aplazarla se queda sin argumento.
La preparación para rastreadores va segunda, porque es la otra mitad de la misma pregunta de acceso y toca exactamente los mismos archivos. Ya tienes robots.txt abierto: añadir reglas por agente, confirmar que las plantillas que importan se renderizan en servidor y publicar llms.txt pertenecen a esa misma pasada. El catálogo la sitúa en ⏱ 4–8 horas y 10 000 – 35 000 ₽ o $150 – $450. Separarla significa abrir el mismo archivo dos veces con dos modelos mentales distintos, que es justamente como aparecen las reglas contradictorias.
El marcado va tercero, y es el único de los tres calificado como Con experiencia en lugar de Principiante: ⏱ 4 a 8 horas para 5 a 7 plantillas, 8 000 – 35 000 ₽ o $120 – $500. Va tercero porque es trabajo de significado y no de acceso: presupone que las páginas son alcanzables, presupone que el contenido existe de verdad y presupone que alguien en la sala sabe decir de qué es instancia cada tipo de página. Ese último presupuesto es el que suele fallar.
Sumando —aritmética que cualquier lector puede rehacer con las cifras de arriba, ofrecida como ejemplo y no como precio de paquete anunciado— las tres horquillas abarcan de $350 a $1 250, o de 23 000 a 90 000 ₽, a lo largo de ⏱ 10 a 21 horas de trabajo. Es la capa entera de legibilidad por máquinas de un sitio expresada como una sola cifra que el comprador puede contrastar con su presupuesto antes de que empiece la conversación, en lugar de tres propuestas que llegan sueltas a lo largo de tres semanas.
Cómo sobreviven las comprobaciones al segundo año
Una comprobación que emite un aviso será una comprobación ignorada para la cuarta semana. La afirmación tiene que romper la build y bloquear el merge, y eso es una decisión social bastante más que técnica. Conviene tomarla en voz alta durante la entrega, con quien sea responsable del pipeline, porque la primera vez que una build se ponga roja por un diff de robots.txt alguien pedirá degradarla a aviso. La respuesta a esa petición tiene que existir antes de que la pregunta llegue.
El patrón de la instantánea versionada es lo que hace soportable una comprobación bloqueante. En lugar de una regla que diga robots.txt no debe cambiar nunca, el repositorio guarda un archivo que describe cómo debe ser robots.txt. Un cambio deliberado actualiza ese archivo en la misma pull request y se revisa como cualquier otro diff; uno accidental llega sin la actualización correspondiente y falla al instante. La comprobación no prohíbe el cambio: prohíbe el cambio inadvertido, que es el único que hace daño. Por eso nadie acaba saboteándola, porque no estorba al trabajo, estorba al trabajo a ciegas.
La otra mitad de la supervivencia es la propiedad. Estos archivos viven en el hueco entre marketing e ingeniería y por defecto no son de ningún departamento, que es justo la razón de que se pudran. Nombrar a una única persona revisora para los cambios en robots.txt, la generación del sitemap, la lógica de canónicas y la lista blanca de noindex no cuesta absolutamente nada. Y elimina la ambigüedad que deja salir una directiva sin examinar porque cada lado daba por hecho que miraba el otro.
Al marcado se vuelve cuando cambia el modelo de datos, no cuando lo manda el calendario. Un atributo nuevo de producto, una migración de gestor de contenidos, un tipo de página nuevo, un cambio en cómo se almacenan los autores: cada uno de esos hechos es un motivo real para revalidar, ninguno resulta visible desde una revisión trimestral, y todos vuelven a lanzar la validación solos si esta ya vive en CI. Ahí está la diferencia entre un proyecto que se entregó y una propiedad que el sitio ya tiene de forma permanente.
Preguntas frecuentes
¿Cuánto cuesta implementar el micromarcado de Schema.org en una web?
El catálogo de VIT MARKET fija «Micromarcado de Schema.org con verificación en CI» en 8 000 – 35 000 ₽ o $120 – $500, con una duración declarada de ⏱ 4 a 8 horas para 5 a 7 plantillas. Está clasificado con dificultad Con experiencia dentro de la categoría Datos estructurados. La unidad es la plantilla y no la página: una sola plantilla de producto cubre todo el catálogo.
¿Un despliegue puede sacar páginas de Google sin querer?
Sí, y normalmente ocurre sin ningún error visible. Un bloqueo de preproducción que llega a producción, un noindex olvidado dentro de un layout compartido o una consulta de sitemap que devuelve once URL en lugar de cuatro mil pasan la compilación sin problemas. Para eso existe en el catálogo «Mapa del sitio, robots.txt y protección de indexación en CI»: ⏱ 2–5 horas, 5 000 – 20 000 ₽ o $80 – $300, dificultad Principiante.
¿Los datos estructurados mejoran el posicionamiento?
No. El marcado hace que una página sea apta para presentaciones enriquecidas y declara sus entidades sin ambigüedad ante los modelos de IA, pero no es una señal de ranking y no rescata una URL bloqueada en robots.txt. El catálogo formula el beneficio como aumento de los fragmentos enriquecidos y de la posibilidad de ser citado en respuestas de IA: una posibilidad, no una garantía. El trabajo se cifra en ⏱ 4 a 8 horas para 5 a 7 plantillas.
¿Qué es llms.txt y necesita mi sitio uno?
llms.txt es un archivo de texto plano en la raíz que indica a los lectores guiados por modelos qué es el sitio y qué página es canónica para cada tema. Pertenece al servicio «Preparando un sitio web para rastreadores de IA: robots.txt, llms.txt, renderizado»: Infraestructura de IA, dificultad Principiante, ⏱ 4–8 horas, 10 000 – 35 000 ₽ o $150 – $450. Sirve de poco en un sitio renderizado en cliente, que devuelve una cáscara vacía a quien no ejecuta JavaScript.