popnetmedia/ai-search-readiness

Preparación para Búsqueda por IA

Tres movimientos. No son sobre calidad de contenido, que está gobernada por non-commodity-content. Se trata de si el sitio puede ser encontrado, cotizado y con el que se pueda transaccionar por una máquina que actúa en nombre de un cliente.

Un sitio puede cumplir todas las reglas de contenido y seguir siendo invisible para un agente, porque nunca publicó un número y nunca expuso un endpoint de reserva que una máquina pueda leer.

---

Movimiento 1: publicar el rango de precios

La regla. Todo sitio comercial publica lo que cuesta su servicio. No un libro de precios. Un rango con los dos extremos y lo que mueve el número entre ellos.

La gente le pregunta a la IA cuánto cuestan las cosas, constantemente. Una IA sin nada que cotizar los envía a un competidor que publicó algo. "Llame para obtener precio" es un callejón sin salida para una máquina, y cada vez más para una persona.

Qué publicar, como mínimo:

• el extremo inferior y el extremo superior, como cifras reales
• qué lo mueve: las dos o tres variables que deciden dónde cae un trabajo en el rango
• la fecha en que se midió el rango, junto a las cifras
• cada tarifa fija, en su totalidad: envío, configuración, depósito, limpieza, mínimos, penalizaciones
• un enlace a la fuente en vivo para una cotización exacta

La objeción, y la respuesta. Los operadores se resisten porque los precios se mueven y temen que se les exija cumplir una cifra obsoleta. Esa objeción se refiere a un precio fijo único presentado como el precio. No es un argumento en contra de un rango. Un rango fechado con sus factores nombrados es más preciso que el silencio, y es lo que el operador está en una posición única para indicar.

La regla que lo resuelve. Nunca publiques una tarifa simple. Publica:

Las tarifas nocturnas oscilan entre $106 y $175 en toda la flota, medidas el 18 de septiembre de 2026. Qué casa rodante y qué fechas deciden dónde caes. Verifica tus fechas para la tarifa exacta.

No:

Casas rodantes desde $106/noche.

Nunca escribas un precio dos veces. Léelo de la fuente que la empresa ya mantiene, en el momento de la compilación: el feed de la plataforma de reservas, el POS, la tabla de tarifas publicada. Un precio escrito en una página es un precio que discrepará del pago en menos de un mes. Cuando el número se analiza de la propia página del operador, los dos nunca pueden desviarse.

Donde una tarifa realmente no se puede publicar (se cotiza por trabajo, o la establece un tercero), la página aún le debe al lector todo lo adyacente que sea fijo: la tabla de tarifas, los mínimos, el depósito, la penalización por cambiar una reserva. Luego di claramente que la tarifa en sí se establece en la cotización, y señala dónde. Una página que dice "no publicamos X, aquí está por qué, aquí está dónde obtenerlo, y aquí está todo lo que no se mueve" supera a una página que no dice nada.

Verificación previa a la publicación para cualquier página de precios:

• Ambos extremos del rango son cifras reales, no "desde"
• Los factores que mueven el precio están nombrados
• La fecha de medición está junto a las cifras
• Cada tarifa fija está publicada en su totalidad
• Las cifras se leen de una fuente en el momento de la compilación, no escritas
• Los datos estructurados llevan los mismos números que el texto (ver Movimiento 2)
• Donde algo no se puede fijar el precio, la página lo dice y señala la cotización

---

Movimiento 2: programación apta para agentes

La regla. Si el agente de un cliente no puede ver cómo transaccionar con el calendario, el negocio es invisible para él. La reserva agentiva está activa: un asistente reservará una mesa, una llamada de servicio, un alquiler. Busca datos estructurados primero y el DOM después.

Tres capas, todas requeridas.

1. La oferta, en datos estructurados. Cada cosa reservable lleva una Offer con un precio real o un rango priceSpecification, una moneda, un estado de disponibilidad y un priceValidUntil que coincida con la fecha de medición. Un priceRange en el negocio no es suficiente; la máquina quiere la oferta en el artículo que se le pide reservar.

"offers": {
  "@type": "Offer",
  "priceCurrency": "USD",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "priceCurrency": "USD",
    "minPrice": 106,
    "maxPrice": 175,
    "unitCode": "DAY",
    "referenceQuantity": { "@type": "QuantitativeValue", "value": 1, "unitCode": "DAY" }
  },
  "availability": "https://schema.org/InStock",
  "priceValidUntil": "2026-12-31",
  "url": "https://example.com/book"
}

2. La acción. La entidad lleva un potentialAction que nombra el endpoint de reserva, el objetivo HTTP y las entradas que requiere. Esta es la parte que casi nadie publica y la parte que un agente realmente necesita.

"potentialAction": {
  "@type": "ReserveAction",
  "name": "Reservar esta casa rodante",
  "target": {
    "@type": "EntryPoint",
    "urlTemplate": "https://example.com/book?rental_id={rental_id}&from={checkin}&to={checkout}",
    "actionPlatform": [
      "https://schema.org/DesktopWebPlatform",
      "https://schema.org/MobileWebPlatform"
    ],
    "httpMethod": "GET"
  },
  "result": { "@type": "Reservation", "name": "Reserva de alquiler de casa rodante" },
  "object": { "@type": "Product", "name": "Jayco Jay Flight 2023" }
}

Elige el tipo de acción que coincida con el verbo: ReserveAction para una reserva, ScheduleAction para una cita, OrderAction para una compra, RsvpAction para un evento.

3. Las restricciones, expresadas como datos, no como texto. Un agente que reserva una estancia que el negocio no puede honrar ha perdido el tiempo de todos. Publica las reglas que harían fallar una reserva:

• duración mínima y máxima
• tiempo de antelación y fecha límite (availabilityStarts, advanceBookingRequirement)
• elegibilidad (edad mínima, licencia, depósito)
• área de servicio (areaServed), y lo que cuesta llegar a cada parte
• ventanas de apertura o entrega, donde la hora de llegada está restringida por otra persona

Pon cada una de ellas en el esquema donde exista una propiedad, y en oraciones simples en la página donde no exista. Ambos, siempre: el agente lee uno, la persona lee el otro, y deben coincidir.

Renderizado legible por agente. Contenido crítico renderizado en servidor, HTML semántico, encabezados reales, texto alternativo, tablas como <table>. Un agente lee el DOM y el árbol de accesibilidad. El contenido que aparece solo después de una recuperación del lado del cliente es contenido que el agente no vio.

No finjas capacidad. Solo publica una ReserveAction contra un endpoint que realmente acepte una reserva. Una acción que apunta a un formulario de contacto es una mentira en la que un agente actuará, y el cliente se entera en el peor momento. Cuando la reserva es genuinamente por teléfono, publica el número de teléfono en el esquema y ninguna acción de reserva.

Las capas del protocolo, y cuál construir

Existen tres capas. No son alternativas, se apilan, y el orden importa porque las inferiores se leen hoy y las superiores en su mayoría aún no.

Capa 1: datos estructurados (construye esto primero, siempre). Offer más potentialAction, como se indicó. Esto es lo que los asistentes actuales consumen realmente cuando responden una pregunta sobre un negocio y cuando siguen un enlace para actuar. Cuesta una página de JSON-LD y funciona de inmediato.

Capa 2: un feed legible por máquina. Una URL JSON estable que contenga el catálogo: qué está en alquiler o venta, el precio de cada uno, las restricciones, la URL de reserva y la fecha en que se midió. Sin compromiso de protocolo, sin endpoint que defender, legible por cualquier agente, rastreador o sitio hermano. Barato, y la cosa que hace que la capa 3 sea trabajo de una mañana más adelante.

Capa 3: A2A (Agent2Agent). El protocolo abierto para la delegación de tareas de agente a agente: una tarjeta de agente en una URL conocida que describe la identidad, habilidades y autenticación del agente, y un endpoint que habla JSON-RPC sobre HTTPS que acepta tareas y devuelve resultados. Es la respuesta correcta cuando el asistente de un cliente debería poder hacer preguntas y obtener respuestas, en lugar de leer una página.

Sé honesto sobre dónde se encuentra. A finales de 2026 no hay un registro que los asistentes de consumo rastreen rutinariamente en busca de tarjetas de agente, por lo que publicar una es una apuesta a que el descubrimiento llegue, no una fuente de reservas este trimestre. Constrúyela cuando el negocio tenga algo que un agente necesite genuinamente preguntar y que un feed estático no pueda responder, típicamente disponibilidad en vivo.

La regla de honestidad se aplica más estrictamente aquí. Una tarjeta de agente declara habilidades, y otro agente las invocará. Declara solo lo que el endpoint realmente hace. La mayoría de los pequeños operadores no pueden completar una reserva de agente a agente en absoluto, porque el pago, el seguro y el contrato de alquiler residen dentro de una plataforma de terceros. Eso está bien, y la tarjeta debería decirlo:

{
  "name": "Asistente de reservas de Ejemplo Alquileres",
  "description": "Responde preguntas de disponibilidad y precio para una flota. No puede recibir pagos.",
  "skills": [
    { "id": "check-availability", "description": "Qué unidades están libres entre dos fechas" },
    { "id": "quote-stay", "description": "Total para una unidad y fechas, incluida la entrega por ciudad" }
  ],
  "capabilities": { "streaming": false, "pushNotifications": false }
}

Una tarjeta que afirma una habilidad book-stay que termina en una redirección es el mismo fracaso que una ReserveAction que apunta a un formulario de contacto, con una máquina al otro lado en lugar de una persona.

Pagos. Los rieles de pago agentivos (AP2 como extensión de A2A, y las especificaciones competidoras de comercio agentivo) se mueven rápido y no son compatibles con la mayoría de las plataformas de reservas. No diseñes un proceso de pago en torno a ellos. Entrega a la plataforma de pago propia y dílo en la tarjeta.

Verificación previa a la publicación para cualquier página reservable:

• Offer con precio o rango de precios, moneda, disponibilidad, priceValidUntil
• potentialAction con un EntryPoint real que un agente pueda llamar
• Los parámetros de la plantilla de URL de la acción son los que el sistema de reservas realmente toma
• Mínimos, tiempos de antelación, elegibilidad y área de servicio publicados como datos y como texto
• Cada cifra en el esquema coincide con la cifra en el texto
• La página renderiza sus datos de reserva del lado del servidor
• No se publica ninguna acción para una capacidad que no existe

---

Movimiento 3: contenido a partir de preguntas reales

La regla. Las preguntas que los clientes realmente hacen son el contenido. Cada llamada telefónica, cada correo electrónico, cada pregunta de "antes de reservar" es una página o una sección, respondida en público, con las propias palabras del cliente.

La propia guía de Google dice que el contenido de consejos genéricos ("7 consejos para el verano") no gana. Lo que gana es lo hiperespecífico y real. La pregunta que un cliente hizo esta mañana es ambas cosas, por construcción, porque un competidor que escribe a partir de fuentes públicas no sabe que se hizo.

El hábito operativo:

1. Captura la pregunta textualmente. La redacción del cliente, no la jerga de la industria. "¿Pueden dejarlo en mi casa mientras arreglan el techo?" es la consulta. "Logística de colocación residencial" no lo es. Esta es la misma regla que escribir el sustantivo del buscador.
2. Respóndela donde el lector la tiene. En la página donde surge la pregunta, no en una publicación de blog a la que nadie llega.
3. Respóndela con una fuente. Una respuesta sin fuente es una opinión; es la tarifa fija, la regla publicada, la cifra medida que hace que valga la pena citarla.
4. Di cuándo la respuesta no es tuya para dar. Donde la respuesta pertenece a un tercero, un consejo, una aseguradora, un parque, dílo y nombra a quién preguntar. Esa oración es un activo.
5. Mantén una lista de lo que solo el operador sabe. Cada proyecto mantiene un archivo de preguntas abiertas. Esas respuestas son el contenido que nadie puede copiar, y el archivo es la agenda de la entrevista.

Los bloques de preguntas frecuentes son para los lectores, con marcado FAQPage porque indica claramente lo que responde la página. No son la palanca que gana citas. La especificidad de primera mano lo es.

---

Cómo encajan los tres

Un lector llega de una respuesta de IA que citó el rango. La página confirma la cifra, nombra lo que la mueve y responde la pregunta que realmente tenían. Su agente entonces la reserva, porque la oferta y la acción se publicaron como datos.

Cualquier falta rompe la cadena. Un sitio con gran contenido y sin precio publicado no se cotiza. Un sitio con precio y sin acción no se puede transaccionar con él. Un sitio con ambos y contenido genérico no vale la pena cotizarlo en primer lugar.

Fuentes

1. Discurso principal de Danny Sullivan, Google Search Central Live Toronto, abril de 2026, sobre contenido no commoditizado.
2. Guía de optimización para IA, Google Search Central, sobre legibilidad para agentes y expansión de consultas.
3. schema.org Offer, UnitPriceSpecification, ReserveAction, EntryPoint.
4. Protocolo A2A (Agent2Agent), Linux Foundation, para la tarjeta de agente y la interfaz de tareas JSON-RPC.