Todo lo que querrías saber antes de instalar.
Una mirada detallada a cómo funciona DataFirefly Indexing API — Envío automático Google Indexing API e IndexNow (Bing, Yandex, Naver) para PrestaShop 8 y 9, por qué lo construimos así y la lógica detrás de las características anteriores.
§ 01
El problema: Googlebot y Bingbot tardan en rastrear
Es el punto ciego SEO de cualquier tienda en crecimiento. Publicas un nuevo producto el lunes por la mañana y Google no lo indexa hasta el jueves por la noche. Corriges una errata en una ficha y Bing sigue mostrando la versión antigua dos semanas después. Durante ese retraso, pierdes tráfico orgánico, pierdes conversiones, y tus usuarios ven información desactualizada en los resultados de búsqueda. Para una tienda que publica o modifica 20 productos por semana, son cientos de URLs perpetuamente atrasadas. El sitemap XML sigue siendo imprescindible: es el canal de descubrimiento oficial y debe mantenerse limpio y al día. Pero no otorga ninguna prioridad, y el ping clásico de sitemap ya no sirve de nada desde que Google eliminó su endpoint de ping en junio de 2023. Para señalar un cambio en minutos en lugar de días, hay que recurrir al envío directo.
§ 02
Google Indexing API: qué hace y qué no hace
Google expone un endpoint REST en indexing.googleapis.com que acepta notificaciones de actualización o eliminación de URL. La autenticación es vía un Service Account de Google Cloud: creas un Service Account, descargas su clave en formato JSON, lo añades como propietario de tu propiedad de Search Console. El módulo firma un JWT RS256 con la clave privada, intercambia ese JWT por un token de acceso OAuth2 en oauth2.googleapis.com, mantiene ese token en caché durante 55 minutos, y lo usa para autenticar cada envío. El punto que conviene conocer antes de comprar: la documentación de Google restringe oficialmente esta API a páginas que contengan datos estructurados JobPosting, o BroadcastEvent integrado en un VideoObject. Una ficha de producto o una página de categoría no encaja en ninguno de los dos casos. La API acepta igualmente el envío y responde 200, pero ese 200 solo significa que la notificación se ha recibido: Google decide solo sobre el rastreo y la indexación. La cuota predeterminada es de 200 URLs por día por Service Account, y el aumento de cuota está reservado a sitios que usan efectivamente JobPosting o BroadcastEvent, así que una tienda no debe contar con ello. El módulo envía, registra el código de retorno, y el dashboard refleja la respuesta de la API, no la decisión de indexación. Si buscas una ganancia de indexación medible en un catálogo de productos, IndexNow es lo que la aporta.
§ 03
IndexNow: Bing, Yandex, Naver, Seznam en una sola llamada
IndexNow es un protocolo abierto impulsado por Microsoft Bing y Yandex en 2021, al que se unieron Naver (el motor dominante en Corea del Sur) y Seznam (el motor histórico en República Checa). A diferencia de la API de Google, IndexNow no impone ninguna restricción sobre el tipo de página: fichas de producto, categorías y páginas CMS están dentro de su ámbito normal. El principio: generas una clave alfanumérica, la publicas en la raíz de tu dominio (archivo clave.txt), y llamas al endpoint api.indexnow.org con una lista de URLs a indexar. La llamada es gratuita, ilimitada y se propaga automáticamente a todos los motores participantes. Sin cuota, sin Service Account, sin OAuth: solo una clave y una llamada HTTP. El módulo genera la clave automáticamente al instalarse, ofrece dos métodos para servirla en la raíz (reescritura .htaccess con snippet generado, o archivo físico), y agrupa URLs hasta 100 por llamada para ahorrar peticiones.
§ 04
Los hooks PrestaShop escuchados
El módulo se engancha a los hooks oficiales del ciclo de vida de los objetos PrestaShop. Para productos: actionProductSave se llama en la creación y en cada modificación, y si el producto está activo la URL se encola como URL_UPDATED, si no como URL_DELETED. actionProductDelete se llama en la eliminación definitiva, con URL_DELETED encolado. Para páginas CMS: actionObjectCmsAddAfter (creación), actionObjectCmsUpdateAfter (actualización), actionObjectCmsDeleteAfter (eliminación). Para categorías: actionCategoryAdd, actionCategoryUpdate, actionCategoryDelete, ignorándose la raíz de categoría (ID 1 y 2) por seguridad. Cada hook construye la URL canónica mediante el objeto Link oficial de PrestaShop, lo que garantiza el respeto de las preferencias SEO friendly URL, los prefijos de idioma y las reglas multilingües.
§ 05
La cola: por qué y cómo
Enviar de forma sincrónica en cada hook sería doblemente malo: la latencia ralentizaría la administración (una llamada a Google puede tardar 2 a 5 segundos), y un fallo de API impediría guardar el producto. El módulo encola cada envío en una tabla persistente (df_indexapi_queue) y un CRON procesa el lote cada pocos minutos. La deduplicación es clave: si modificas un producto tres veces en una hora, el módulo reconoce que ya existe un trabajo para esa tupla (tienda, tipo, ID, proveedor, acción) y simplemente actualiza su URL y fecha, no crea tres. El bloqueo lógico pending a processing evita el procesamiento doble si dos CRONs paralelos reclaman de la cola al mismo tiempo. Y cada fallo incrementa un contador de reintentos, activando un reintento automático en el siguiente CRON hasta un máximo configurable (predeterminado 5). Más allá, el trabajo pasa a error y permanece visible en la pantalla Cola con el mensaje exacto de la API.
§ 06
El registro y el dashboard
Cada envío produce una entrada en la tabla df_indexapi_log: proveedor Google o IndexNow, tipo y ID de objeto, URL exacta enviada, acción URL_UPDATED o URL_DELETED, código HTTP devuelto, indicador aceptado o rechazado, mensaje completo de respuesta y fecha. La pantalla Registro expone estos datos en un HelperList estándar de PrestaShop con filtros nativos (proveedor, código HTTP, aceptado), ordenación y exportación CSV. El Dashboard agrega todo: cinco tarjetas para los contadores por estado de la cola, dos tarjetas de diagnóstico de proveedor (Service Account de Google configurado o no, clave y host IndexNow configurados o no), una tabla de tasa de aceptación a 30 días por proveedor con coloración semántica (verde por encima de 90, naranja entre 60 y 90, rojo por debajo), y un gráfico Chart.js de envíos diarios superponiendo total enviado y total aceptado. Léelo como un indicador de la salud técnica de las llamadas a la API, no como una prueba de indexación.
§ 07
Seguridad del CRON y archivo clave
El controlador CRON está expuesto en una URL frontend estándar de PrestaShop, pero protegido por un token aleatorio de 32 caracteres generado al instalar y regenerable con un clic desde la configuración. Sin el token correcto, el controlador devuelve 403. Se admiten tres acciones: process procesa un lote de la cola (a llamar cada 5 a 15 minutos por tu CRON de hosting), purge elimina trabajos y registros procesados más allá de la retención configurada (a llamar una vez al día), y key sirve el contenido del archivo clave IndexNow como text/plain para la reescritura .htaccess (protegido por el conocimiento previo de la clave en el parámetro k). El snippet .htaccess exacto a pegar en la raíz de PrestaShop se genera automáticamente en la página Configuración con la clave actual.
§ 08
Casos de uso típicos
Tienda en crecimiento con 50 nuevos productos por semana: el módulo encola cada creación, el CRON envía en 10 minutos, y Bing, Yandex, Naver y Seznam suelen tener en cuenta las nuevas URLs en las horas siguientes. Del lado de Google, el envío acelera el descubrimiento sin garantía de resultado. Tienda multilingüe con catálogo de 5000 productos: en cada cambio de ficha, las URLs canónicas de todos los idiomas se encolan y envían, en todos tus mercados a la vez. Tienda B2B con catálogo técnico frecuentemente actualizado (precios, stocks, fichas técnicas): la deduplicación evita saturar las APIs en ráfagas de cambios, un único trabajo por producto incluso si lo modificas veinte veces en un día. Recuperación SEO tras migración: un botón Reintentar todos los trabajos en la pantalla Cola permite reenviar en masa tras resolver un problema de configuración o cuota.
§ 09
Limitaciones conocidas y buenas prácticas
Google reserva oficialmente la Indexing API a las páginas JobPosting y BroadcastEvent, lo que convierte a IndexNow en el canal principal del módulo para un catálogo de productos. Activa IndexNow primero y trata Google como un extra registrado. IndexNow no gestiona URL_DELETED: el protocolo considera que un 404 o 410 en la URL es la forma adecuada de señalar una eliminación, así que el módulo ignora esos trabajos (Google sí admite ese tipo de acción). La cuota Google está limitada a 200 URLs por día por Service Account, y como el aumento de cuota está condicionado a la presencia de marcado JobPosting o BroadcastEvent, una tienda debe considerar ese techo como definitivo: restringe el filtro de Google a las novedades, o crea un segundo Service Account con su propia cuota. El módulo no envía variantes ni combinaciones de productos, ya que la URL canónica del producto principal basta y Google consolida las variantes naturalmente. Y la raíz de categoría (ID 1 y 2) se ignora para evitar enviar URLs no relevantes.
No hay valoraciones aún.