• Las versiones corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. PHP pide actualizar de inmediato.
• Hay arreglo también para versiones antiguas. El equipo de PHP ha publicado el código de la corrección para PHP 7.4, 8.0 y 8.1, y en los paquetes de Ondřej Surý, los más usados en Ubuntu y Debian, ya están llegando versiones corregidas para todas las versiones de PHP que mantiene, de la 5.6 a la 8.5.
• Desactivar la barra de progreso de subida solo frena uno de los dos fallos, y no del todo. Ya no basta con eso: hay que actualizar.

Hemos reescrito la entrada con la información oficial. La primera versión, de las 08:00, se basaba en lo que se había filtrado.

Seguiremos actualizando esta entrada según haya novedades.

Si tienes una tienda en PrestaShop, hoy toca prestar atención al servidor. PHP, el lenguaje sobre el que funciona PrestaShop (y también WordPress, WooCommerce, Magento o Drupal), acaba de corregir dos fallos de seguridad con una puntuación de 9,2 sobre 10. Ambos permiten a un atacante ejecutar código en el servidor sin necesidad de usuario ni contraseña.

La información se filtró ayer, antes de lo previsto, y desde las 16:00 los detalles técnicos son públicos. Se esperan ataques masivos en las próximas horas, así que no conviene dejarlo para mañana.

¿Qué ha confirmado PHP?

¿Dónde está el problema?

PHP ha confirmado dos fallos distintos. Los dos ocurren antes de que se ejecute el código de tu tienda, mientras PHP prepara la petición. Por eso no se pueden arreglar desde PrestaShop ni con un módulo: la corrección tiene que llegar al servidor.

El primero (CVE-2026-109618) aparece cuando PHP se queda sin memoria a mitad de procesar una petición. En ese momento algunos datos internos quedan a medio preparar, y al limpiar PHP los trata como si fueran válidos. Un atacante puede provocar esa situación a propósito con una petición preparada.

El segundo (CVE-2026-109619) tiene que ver con restos de una petición anterior. Cuando PHP termina de atender a un visitante, algunos datos internos pueden quedarse «colgando» aunque la memoria que usaban ya se haya liberado. Si la siguiente petición que atiende ese mismo proceso es la del atacante, puede aprovechar esos restos. Una de las vías confirmadas para provocarlo es la función que informa del progreso de subida de ficheros, la que se filtró ayer. No es la única.

Con cualquiera de los dos, un atacante podría leer la base de datos (clientes, pedidos), instalar código malicioso en el checkout o usar tu servidor para atacar a otros.

¿Hay PHP corregido para tu versión de PrestaShop?

PHP da soporte a cada versión durante cuatro años. Hoy solo tienen soporte 8.2, 8.3, 8.4 y 8.5, y son las únicas con versión oficial corregida. Por la gravedad del caso, PHP ha hecho una excepción y ha publicado también el código de la corrección para 7.4, 8.0 y 8.1. Aun así, no hay versión oficial para esas ramas: el PHP corregido tiene que llegarte a través de tu proveedor o de la distribución de Linux.

Si cruzamos esto con las versiones de PHP que admite oficialmente cada PrestaShop, el resultado es este:

Fuente: documentación oficial de requisitos de PrestaShop 9, PrestaShop 8 y PrestaShop 1.7, y aviso de seguridad de PHP.

Esta mañana parecía que las tiendas en PrestaShop 1.6, 1.7 y 8 se quedaban sin solución. Ya no es así: casi todas pueden tener PHP corregido sin migrar, siempre que su proveedor o su servidor lo instale. La diferencia con PrestaShop 9 es que dependen de terceros, y que la próxima vez puede no haber excepción.

¿No sabes qué versión de PHP tienes? En el panel de PrestaShop la verás en Parámetros avanzados > Información, en el apartado de configuración del servidor.

Qué hacer ahora

Lo primero: actualizar PHP

Si tu tienda está en un hosting compartido o gestionado, escribe hoy a tu proveedor y pídele que confirme que ha instalado PHP corregido. Si usas PHP 8.2 o superior, la versión debe ser 8.2.35, 8.3.36, 8.4.27 o 8.5.12. Si usas una versión anterior, pregunta expresamente si su PHP incluye la corrección de CVE-2026-109618 y CVE-2026-109619.

Un detalle que despista: en los paquetes de Ubuntu y Debian el número de versión a veces no cambia, porque solo se aplica la corrección. Por eso es mejor preguntar por los CVE que fiarse del número.

Si administras tu propio servidor con Ubuntu o Debian y usas los paquetes de Ondřej Surý (ppa:ondrej/php o packages.sury.org), ya hay paquetes corregidos para todas las versiones de PHP que mantiene, de la 5.6 a la 8.5, según confirman usuarios que ya los han recibido. Actualiza solo los paquetes de PHP y reinicia. Por ejemplo, para PHP 7.4:

sudo apt update
sudo apt install --only-upgrade 'php7.4-*'
sudo systemctl restart php7.4-fpm

Cambia 7.4 por tu versión, y reinicia Apache en lugar de PHP-FPM si usas mod_php. Con apt-cache policy php7.4-fpm puedes comprobar que se ha instalado el paquete nuevo. Si no aparece todavía, vuelve a intentarlo en unas horas: los paquetes se están publicando a lo largo del día.

Si usas el repositorio de Remi (habitual en CentOS, AlmaLinux o Rocky), PHP avisa de que hoy no tendrá actualización y recomienda pasar a los paquetes de la distribución. En servidores con CloudLinux, sus paquetes alt-php corregidos están en preparación.

Si no puedes actualizar hoy: reduce el riesgo

PHP propone varias medidas temporales. Ninguna hace el servidor seguro; solo cierran algunos caminos de ataque mientras llega la actualización.

Desactiva la barra de progreso de subida. Es la medida que ya circulaba esta mañana, y PHP la confirma para el segundo fallo. Las subidas de imágenes, CSV o módulos siguen funcionando igual; solo deja de verse la barra de progreso que pinta PHP.

Atención a dónde se pone, porque PHP ha sido claro: tiene que ir en el php.ini, en el pool de PHP-FPM o en la configuración del servidor web. No sirve ponerlo en el código de la tienda (ini_set()) ni en un fichero .user.ini. Si estás en un hosting compartido y no tienes acceso a esa configuración, pídeselo a tu proveedor.

Si administras el servidor, crea un fichero de configuración propio para que no se pierda al actualizar PHP, por ejemplo /etc/php/8.x/fpm/conf.d/99-no-upload-progress.ini:

session.upload_progress.enabled = Off

Y en el pool de PHP-FPM, para que ningún dominio pueda volver a activarlo:

php_admin_flag[session.upload_progress.enabled] = off

Es la configuración que compartió esta mañana DMNTR Network Solutions. Después, reinicia PHP-FPM (o Apache si usas mod_php) para que se apliquen en todos los procesos.

Si usas PHP 8.5, añade también fatal_error_backtraces = Off.

Limita el tamaño de las peticiones. PHP recomienda bajar post_max_size para dificultar el primer fallo. Como PrestaShop necesita subir ficheros, el valor que propone es 32M, con upload_max_filesize por debajo. Si importas CSV muy grandes, puede que tengas que partirlos mientras dure esta medida.

PHP también menciona quitar el límite de memoria (memory_limit = -1). En una tienda no lo aplicaríamos sin más: un proceso descontrolado podría comerse toda la memoria del servidor. Solo tiene sentido si el servidor ya tiene otro límite por encima, como un contenedor.

Comprueba que se ha aplicado. Crea un fichero con solo <?php phpinfo(); en la raíz, ábrelo en el navegador y busca session.upload_progress.enabled: debe aparecer como Off. Borra ese fichero en cuanto termines, porque muestra mucha información de tu servidor. No te fíes de php -i en la terminal: muestra la configuración de la línea de comandos, que no es la que usa la web.

Una capa extra si usas Cloudflare

El mismo 21 de octubre, Cloudflare publicó actualizaciones de emergencia en sus reglas gestionadas, tanto para planes de pago como para el plan gratuito. Añaden reglas nuevas que bloquean peticiones anómalas. Cloudflare no las vincula expresamente a estos fallos de PHP, pero coinciden en fecha.

Para que te protejan, las reglas administradas tienen que estar activadas. Compruébalo en Seguridad > WAF > Reglas administradas:

• En el plan gratuito, el Cloudflare Free Managed Ruleset.
• En los planes Pro, Business o Enterprise, el Cloudflare Managed Ruleset.

Si tu plan permite reglas personalizadas que lean el cuerpo de la petición, puedes añadir además una regla propia que bloquee las peticiones que intenten usar la barra de progreso de subida. En Seguridad > WAF > Reglas personalizadas, crea una regla con acción Bloquear y esta expresión:

any(http.request.body.form.names[*] == "PHP_SESSION_UPLOAD_PROGRESS") or http.request.body.raw contains "PHP_SESSION_UPLOAD_PROGRESS"

Ayuda, pero no basta: si alguien llega al servidor sin pasar por Cloudflare, ninguna de estas reglas sirve.

Plan de acción según tu versión de PrestaShop

Si tu tienda está en PrestaShop 9

1. Actualiza hoy PHP a 8.2.35, 8.3.36, 8.4.27 o 8.5.12, o pide a tu hosting que lo haga y te lo confirme.
2. Si tu servidor sigue en PHP 8.1, aprovecha para subir a 8.2 o superior. PrestaShop recomienda PHP 8.4 para la versión 9.0 y PHP 8.5 para la 9.1.
3. Hasta que esté actualizado, aplica las medidas temporales y activa las reglas de Cloudflare si lo usas.

Si tu tienda está en PrestaShop 1.6, 1.7 u 8

No puedes subir a PHP 8.2 sin migrar PrestaShop, porque la tienda dejaría de funcionar. Pero sí puedes tener tu versión actual de PHP corregida.

Hoy:

1. Pregunta a tu proveedor si su PHP ya incluye la corrección de CVE-2026-109618 y CVE-2026-109619 para tu versión. Si administras el servidor y usas los paquetes de Ondřej Surý, actualiza como explicamos arriba.
2. Mientras no lo tengas, aplica las medidas temporales y activa las reglas de Cloudflare si lo usas.
3. Si tu proveedor no va a ofrecer PHP corregido para tu versión, tómatelo como una urgencia: o cambias de proveedor o adelantas la migración.
4. Vigila la tienda en los próximos días: ficheros PHP nuevos que no reconozcas, cambios en el checkout o administradores que nadie ha creado.

En las próximas semanas:

• Planifica la migración a PrestaShop 9 con PHP 8.4 u 8.5. Esta vez ha habido corrección para versiones antiguas porque el fallo era muy grave; la próxima puede no haberla. Además, PHP 8.2 deja de tener soporte el 31 de diciembre de 2026.
• Antes de migrar, revisa que tus módulos y tu tema sean compatibles con PrestaShop 9. Es el paso que más tiempo suele llevar.

No queremos ser alarmistas, pero una tienda online que procesa pagos y datos de clientes no debería depender de que alguien haga una excepción para recibir parches de seguridad.

Conclusión

En Amarillo Limón te recomendamos comprobar hoy mismo que tu servidor tiene PHP corregido, sea cual sea tu versión de PrestaShop. Si quieres que lo revisemos por ti o que planifiquemos contigo la migración a PrestaShop 9, contacta con nosotros.

Fuentes

• PHP: aviso de seguridad y versiones corregidas (21/10/2026)
• PHP: aviso técnico de CVE-2026-109618
• PHP: aviso técnico de CVE-2026-109619
• PHP: aviso previo de la actualización de seguridad (20/10/2026)
• ma.ttias.be: cómo aplicar el parche en Ubuntu, Debian y RHEL
• Cloudflare: actualización de emergencia del WAF, planes de pago (21/10/2026)
• Cloudflare: actualización de emergencia del WAF, plan gratuito (21/10/2026)
• PrestaShop: requisitos del sistema (9, 8 y 1.7)
• Sansec: Critical PHP RCE CVE-2026-109618 y CVE-2026-109619
• Roots Discourse: mitigación en php.ini y regla de Cloudflare
• DMNTR Network Solutions: aviso a clientes y configuración de PHP-FPM (X)
• deb.sury.org: seguimiento de la actualización de los paquetes de Ondřej Surý

En las últimas semanas se ha detectado algo interesante en las AI Overviews de Google: el buscador empieza a mostrar el nombre del autor junto al enlace de la fuente, sobre todo cuando la citación viene de plataformas como LinkedIn o Medium. No hay confirmación oficial de Google de que sea un despliegue global y definitivo (ya hubo un test parecido en 2025 que no llegó a consolidarse), pero la señal es clara y va en la misma dirección que todos los movimientos del último año.

El SEO ha dejado de ser solo una guerra entre URLs para pasar a ser una guerra entre entidades, personas y marcas reconocidas.

En este post te voy a contar exactamente qué ha cambiado, qué dicen los datos sobre cómo los LLM eligen sus fuentes, qué pasa ya en SERPs en español, qué sectores están sufriendo más y, sobre todo, qué deberías estar haciendo desde ya si quieres que Google, ChatGPT, Perplexity y demás citen a tu marca cuando tu cliente potencial los utilicen.

Cómo está cambiando el SEO en 2026

• El primer estudio académico riguroso en España (Universitat de Barcelona, febrero de 2026) detecta AI Overviews ya en el 29,8% de las SERPs analizadas. Y subiendo.
• Varios estudios internacionales coinciden en que el CTR orgánico cae aproximadamente a la mitad cuando aparece una AI Overview.
• Google publicó en mayo de 2026 su guía oficial para SEO en búsqueda con IA y zanja el debate: no existen «trucos GEO». La IA usa el mismo índice y los fundamentos siguen siendo los mismos. Lo que cambia es el peso de cada pieza: E-E-A-T, autor verificable, marca y contenido con criterio propio pasan a ser el centro.
• La estrategia que funciona en 2026 combina contenido con autor real, schema bien implementado, presencia en plataformas que la IA cita mucho (Reddit, YouTube, LinkedIn) y linkbuilding «natural».

Nombres de autor en AI Overviews

En las últimas semanas se han detectado algunas citaciones de las AI Overviews, Google ya no muestra solo el dominio (ej. «linkedin.com»), sino algo del tipo «LinkedIn – Nombre del autor» o «Medium – Nombre del autor».

Tiene lógica. En plataformas donde cualquiera puede publicar, el nombre del autor aporta una pista de confianza que el dominio por sí solo no da. Como ya pensábamos hace unos años: Google está empezando a tratar a los autores como entidades con peso propio.

Llevamos años viendo cómo Google asocia contenido a autores, evalúa su trayectoria y construye su propio grafo de conocimiento sobre quién es experto en qué. La novedad es que ahora ese trabajo invisible empieza a hacerse visible en plena SERP, dentro de la respuesta generada por IA.

¿Despliegue global confirmado? No. ¿Test serio en varios mercados? Sí. ¿Tendencia de fondo evidente? Absolutamente.

Qué está pasando ya en SERPs en español

Una de las preguntas más habituales: «¿esto pasa también en castellano o solo se ha desplegado en EEUU?». La respuesta corta: sí, ocurre en castellano, y va a más.

Google AI Overviews aterrizó oficialmente en España en marzo de 2025. Y el primer estudio académico riguroso sobre el impacto en SERPs en español (Universitat de Barcelona) deja datos que conviene fijar:

• El 29,8% de las SERPs analizadas activan ya una AI Overview en España. Casi 3 de cada 10 búsquedas muestran un resumen de IA antes del primer enlace.
• Las búsquedas con «por qué» disparan AIO el 92% de las veces. Con «qué», el 86%. Cuanto más conversacional es la consulta, más probabilidad de IA.
• Por sectores: Sociedad 59%, Economía 48%, Tecnología 45%, Cultura 40%. En el extremo opuesto, Deporte (2,4%) y Política (24%), donde Google se autolimita por riesgo de errores.
• El 43,6% de las SERPs no muestra ni AIO ni Top Stories. El estudio lo llama acertadamente «un océano azul de oportunidad» para el SEO clásico bien hecho.

Y hay un dato paradójico que aparece en el estudio: el medio líder en tráfico en España según los datos de medición oficial es el último en visibilidad dentro de las AI Overviews. Traducción: el volumen masivo de visitas no garantiza ser citado por la IA.

A nivel de medios, varias publicaciones nacionales reportan ya caídas interanuales del 30-40% en tráfico orgánico, en buena parte atribuibles a este cambio. Y lo más significativo: una parte importante de ese tráfico perdido era de búsquedas de marca, no genéricas. Ya hay medios anunciando despidos y dejando caer que esto va a más.

Qué fuentes cita cada IA o LLM

Si en el SEO clásico la pregunta era «¿en qué top rankeo?», en la era de los LLM la pregunta correcta es «¿qué fuentes consume el modelo cuando le preguntan algo de mi sector?».

Los estudios disponibles a mediados de 2026, que han analizado cientos de millones de citaciones en ChatGPT, Gemini, Perplexity, Claude y Google AI Overviews, coinciden en varias cosas:

• Reddit es la fuente número 1 en prácticamente todos los motores de IA, con una frecuencia de citación cercana al 40%.
• Wikipedia domina ChatGPT (entre el 26% y el 48% de su top 10 de citaciones).
• YouTube tiene una ventaja brutal sobre cualquier otra fuente de vídeo y aparece de forma masiva en las AI Overviews de Google.
• LinkedIn ha duplicado su frecuencia de citación en pocos meses y es la fuente número 1 para queries profesionales.
• Los 15 dominios principales acaparan el 68% del total de citaciones en IA. La concentración es mucho mayor que la que jamás produjo el PageRank.

El dato que más llama la atención: solo alrededor del 38% de las páginas citadas en AI Overviews rankean también en el top 10 orgánico para esa misma query. Hace un año estaba en torno al 76%, es decir, ha caído tanto que puedes estar en la primera posición de Google y no aparecer citado en la IA. O puedes no aparecer ni en el top100 de las SERPs de Google pero salir gracias a un vídeo de YouTube o en un hilo de Reddit.

La guía oficial de Google: no hay «truco GEO» que valga

En mayo de 2026, Google publicó su primera guía oficial sobre cómo optimizar contenido para búsqueda con IA. Y el mensaje es claro: no existen atajos ni trucos especiales que reemplacen las buenas prácticas de SEO de siempre.

Lo más importante de la guía, resumido:

• La IA de Google usa el mismo índice de búsqueda. No hay un «índice paralelo de AI Overviews».
• Chunking (trocear contenido para que la IA lo digiera mejor) no es reconocido por Google como técnica oficial. Estructurar bien ayuda a la lectura humana, pero no es un factor de ranking específico.
• llms.txt no forma parte de la documentación oficial. Algunos lo hemos estado implementado por la gran demanda por parte de los clientes, pero no es necesario para aparecer en AI Overviews.
• La postura es coherente: evita tácticas diseñadas para manipular sistemas de IA y céntrate en crear contenido valioso para humanos.

¿Qué sí marca diferencia, según la propia documentación de Google y los análisis sectoriales?

1. E-E-A-T reforzado: experiencia, conocimiento, autoridad y confianza pesan más que nunca.
2. Estructura clara y semántica: encabezados descriptivos que respondan preguntas concretas.
3. Datos estructurados (schema) bien implementados: Article, FAQPage, Product, HowTo, Organization, Person.
4. Contenido original con punto de vista propio: estudios de caso, datos propios, benchmarks internos, comparativas detalladas, análisis con criterio experto.

E-E-A-T: la pieza que lo conecta todo

Para los que se acaben de incorporar al tema, recordatorio rápido:

• E – Experience: experiencia de primera mano.
• E – Expertise: nivel de conocimiento técnico.
• A – Authoritativeness: autoridad reconocida externamente.
• T – Trustworthiness: confianza y fiabilidad. Es el pilar central.

E-E-A-T no es un «factor de ranking» como tal. Es un marco que describe lo que Google intenta detectar para decidir qué contenido es fiable. Y eso, en la era de los LLM, vale oro.

Cuando una IA decide qué citar, está haciendo (a su manera) una evaluación de E-E-A-T: ¿quién dice esto? ¿Tiene trayectoria? ¿Está respaldado por otras fuentes? ¿Hay coherencia entre lo que dice aquí y lo que ha dicho antes en otros sitios? Si tu marca y tus autores no responden bien a esas preguntas, no te van a citar.

Qué deberías estar haciendo con tus autores

1. Páginas de autor reales, no un «Sobre el autor» de tres líneas. Bio extensa, credenciales, foto consistente, listado de publicaciones internas y externas.
2. Schema Person y Organization con propiedades sameAs apuntando a LinkedIn, Wikipedia, Crunchbase, perfiles donde el autor publica, X, etc. Esto permite a Google «atar» la identidad de tu autor a una entidad reconocida en su grafo de conocimiento.
3. Enlazar el author del schema del artículo a la URL de la página de autor con su propio schema Person. Cadena entidad–artículo–autor verificable.
4. Consistencia: nombre, foto y bio iguales en web, LinkedIn, X, medios externos.
5. Publicaciones fuera de tu dominio: guest posts en medios sectoriales, ponencias grabadas en YouTube, participación en podcasts. Cada mención externa refuerza la entidad.

Este último punto enlaza con algo que llevamos años defendiendo: el linkbuilding moderno no va solo de enlaces «follow» en sitios con DR alto, va de construir autoridad real y reconocible alrededor de personas y marcas. Si quieres profundizar, échale un ojo a nuestra guía para hacer linkbuilding: hace dos años que se redactó y ya hablábamos de la importancia del EEAT.

Marca y menciones: la palanca que muchos ignoran

Un dato que conviene tatuarse: las marcas con más menciones web reciben más de 10 veces más citaciones en AI Overviews que las del siguiente tramo. Y aproximadamente una de cada cuatro marcas no recibe ninguna citación. La concentración es brutal.

En 2026 deberías estar trabajando, sí o sí, estas seis palancas:

• PR digital y notas de prensa en medios sectoriales.
• Participación en Reddit y comunidades de nicho (no como spam, sino como experto que aporta).
• LinkedIn como repositorio editorial: artículos firmados, no solo posts.
• YouTube con vídeos optimizados (títulos descriptivos, transcripciones limpias, descripciones que mencionen tu marca de forma natural).
• Aparición en «best lists» y rankings sectoriales: una parte enorme de lo que cita la IA son listas tipo «los mejores X de [año]».
• Reseñas en plataformas terceras relevantes a tu sector (G2, Trustpilot, Capterra, foros sectoriales).

Si tu marca solo existe en tu web, eres invisible para la IA.

Sectores afectados por EEAT e IA

No todos los sectores están sufriendo lo mismo, ni al mismo ritmo.

El SEO no ha muerto, pero sí cambia: en los próximos 24 meses las búsquedas tradicionales de 10 enlaces azules perderán peso de forma sostenida, ganará protagonismo el AI Mode conversacional (ya por defecto en parte de las búsquedas en algunos países), y el foco se desplazará del ranking al citation share (cuántas veces y con qué peso te cita la IA), con el branded search como KPI crítico y YouTube consolidándose como canal clave por ser fuente recurrente de citas de IA.

Lo que no cambia son los fundamentos: SEO técnico impecable para que te crawleen, contenido excelente con experiencia real y datos propios, enlaces (hay correlación clara entre páginas muy enlazadas y aparecer en AI Overviews) y un E-E-A-T más importante que nunca.

Google está acelerando un cambio que ya estaba en marcha. El sistema ya no premia páginas, premia entidades. Y una entidad puede ser una marca, una organización o una persona con trayectoria reconocible. El día que tu nombre o el de tu agencia aparezca junto a una respuesta de IA en plena SERP va a ser porque has construido autoridad real, verificable y conectada.

Si tienes dudas sobre cómo aplicar todo esto a tu proyecto, puedes contactar con nosotros.

Conversiones sin identificar en Google ADS

Se trata de una problemática de mayor alcance del que habitualmente se considera: Google Ads deja sin atribuir entre el 30% y el 60% de las conversiones generadas desde su plataforma.

Principales factores que limitan el rastreo de conversiones:

• Bloqueadores de anuncios (AdBlock): Se estima que aproximadamente el 20% de los usuarios emplea este tipo de herramientas, impidiendo el registro de sus interacciones.
• Navegadores con restricciones de seguimiento: Plataformas como Safari o el ecosistema iOS limitan de forma nativa el rastreo de usuarios, lo que puede afectar hasta al 30% de la audiencia.
• Rechazo de cookies: Según estimaciones del sector, el 25% de los usuarios no acepta las cookies de seguimiento, lo que imposibilita su atribución.

Si bien es posible estimar el volumen real de conversiones a partir del porcentaje de pérdida calculado, el verdadero problema reside en que Google no recibe esa información y, por tanto, el algoritmo de las campañas no puede optimizarse con datos completos.

Campañas PMax y la necesidad de tener ese 100% de conversiones

El rendimiento de las campañas Performance Max (PMax) depende en gran medida de la capacidad del algoritmo para adaptarse de forma continua a los resultados obtenidos. Cuando parte de esos datos de conversión no llega a Google, el sistema de optimización trabaja con información incompleta y el potencial de la campaña queda inevitablemente mermado.

Por este motivo, resulta imprescindible no solo registrar el 100% de las conversiones internamente, sino garantizar que Google las reciba en su totalidad para que el algoritmo pueda ajustar las campañas con la máxima precisión.

Los datos lo avalan: las campañas que superan holgadamente sus objetivos reciben un mayor volumen de tráfico y de mayor calidad. En sentido contrario, aquellas que no alcanzan las metas establecidas experimentan una reducción progresiva del tráfico y pueden entrar en un estado de infraactividad que compromete su viabilidad.

¿Cómo conseguimos identificar ese 100% de conversiones?

El enfoque que proponemos no es disruptivo, pero sí ha demostrado ser altamente eficaz: consiste en aprovechar las conversiones offline para notificar a Google de todas las ventas con origen en Google Ads que se generen en el ecommerce.

El primer paso consiste en crear la conversión offline. Para ello, accedemos al apartado de Objetivos en Google Ads y seleccionamos “+ Crear acción de conversión”.

A continuación, seleccionamos “Conversiones offline” y procedemos a editar la fuente de datos.

Marcamos la opción de “Conectar un producto nuevo” y elegimos Google Sheets tal como se muestra en la captura.

Marcamos la opción de “Conectar un producto nuevo” y elegimos Google Sheets tal como se muestra en la captura.

Ahora es cuando debemos seleccionar cual es el Google Sheets que vamos a utilizar para ello y asignamos sus campos.

Ahora es cuando debemos seleccionar cual es el Google Sheets que vamos a utilizar para ello y asignamos sus campos.

Plantilla Google Sheet para importar las conversiones offline

Para obtener la plantilla, acceda a su cuenta de Google Ads, diríjase al apartado de Objetivos y seleccione la opción Subidas.

Dentro de la sección “Subir conversiones” encontrará un enlace directo para descargar la plantilla.

Los campos recomendados para una integración completa son: Google Click ID, Conversion Name, Conversion Time, Conversion Value, Conversion Currency y Email.

¿Cómo obtenemos los datos de las conversiones?

Esta es, posiblemente, la fase más técnica del proceso. Es necesario implementar en el ecommerce un sistema capaz de identificar cada visita procedente de Google Ads (mediante el parámetro GClick) y registrarla en caso de que culmine en una venta.

En Amarillo Limón hemos desarrollado un módulo específico para PrestaShop que automatiza todo este proceso y vuelca las conversiones directamente en Google Sheets.

Dada la complejidad de esta implementación, dedicaremos un artículo específico para explicarla en detalle.

A modo de referencia y para ilustrar el impacto real de esta solución, compartimos los resultados obtenidos en una de las últimas cuentas en las que hemos aplicado esta metodología.

Los resultados hablan por sí solos: se registró un incremento superior al 50% en el número de conversiones atribuidas, y el valor total generado rozó prácticamente el doble del inicialmente registrado.

Si necesitas ayuda para configurar tu cuenta de Google ADS o con tus campañas, ¡no dudes en ponerte en contacto con nosotros!

¿Qué está pasando exactamente?

Los motores de IA, los rastreadores de precios y otros bots recorren Internet de forma continua para recopilar información de las tiendas online. No es nada nuevo, pero la intensidad ha crecido enormemente en los últimos tiempos, y algunos de estos bots están aprovechando el parámetro resultsPerPage.

Este parámetro es el que controla cuántos productos muestra una página de categoría o de resultados de búsqueda. El problema es que PrestaShop no pone ningún límite a este valor por defecto. Eso significa que un bot puede hacer una petición como esta:

https://tutienda.com/categoria?resultsPerPage=99999

¿Y qué ocurre? Que PrestaShop obedientemente intenta recuperar de la base de datos los 99.999 productos solicitados. Si tu categoría tiene miles de referencias, la consulta es tan pesada que puede saturar el servidor y dejarte la tienda caída durante minutos… o más.

No es un ataque sofisticado. No hace falta ningún conocimiento especial. Cualquier bot —o persona con malas intenciones— puede hacerlo con una simple URL manipulada. Y lo estamos viendo en tiendas reales, con consecuencias reales.

¿Por qué ocurre esto?

El parámetro resultsPerPage está pensado para que los usuarios puedan elegir entre ver 12, 24 o 36 productos, y en condiciones normales funciona perfectamente. El problema surge cuando un bot lo usa de forma abusiva con valores extremos, algo para lo que ninguna plataforma está preparada por defecto. No es un fallo de diseño, simplemente es un escenario que hasta hace poco nadie contemplaba con esta intensidad.

La solución: limitar el número máximo de productos por página

Desde Amarillo Limón hemos desarrollado un módulo específico para resolver este problema. La idea es sencilla: establecer un máximo razonable de productos por página, de forma que aunque un bot pida 99.999, el servidor nunca devuelva más del límite que tú hayas configurado.

El módulo es compatible con PrestaShop 1.7.x, 8.x y 9.x, y lo hemos publicado de forma completamente gratuita.

¿Cómo funciona técnicamente?

Para quien quiera entrar en detalle: el módulo se engancha al hook hookActionProductSearchProviderRunQueryBefore, que se ejecuta justo antes de que PrestaShop lance la consulta a la base de datos. Si no sabes como funcionan los hooks, puedes consultar este artículo de nuestro blog: Cómo funcionan los hooks en PrestaShop.

En ese momento, comprueba si el número de resultados solicitado supera el límite configurado, y si es así, lo reduce automáticamente. La tienda sigue funcionando con normalidad para el usuario, pero el servidor ya no recibe peticiones abusivas.

public function hookActionProductSearchProviderRunQueryBefore(array $params)
{
    $query = $params['query'];
    $limit = (int) Configuration::get(self::CONFIG_KEY);

    if ($limit <= 0) {
        $limit = self::DEFAULT_LIMIT;
    }

    if ($query->getResultsPerPage() > $limit) {
        $query->setResultsPerPage($limit);
    }
}

Sencillo, limpio y eficaz.

¿Cómo instalo el módulo?

La instalación es igual que cualquier otro módulo de PrestaShop:

1. Descarga el módulo desde el enlace al final de este artículo.
2. Entra en el panel de administración de tu tienda y ve a Módulos > Gestión de módulos.
3. Haz clic en Subir un módulo y selecciona el archivo descargado.
4. Una vez instalado, accede a la configuración del módulo y establece el número máximo de productos por página que consideres razonable (recomendamos entre 60 y 120).

Y listo. A partir de ese momento, ningún bot podrá solicitar más productos de los que hayas autorizado.

¿Quién debería instalar este módulo?

Cualquier tienda PrestaShop con un catálogo amplio debería valorarlo, pero es especialmente recomendable si:

• Tienes categorías con cientos o miles de productos.
• Has notado picos de consumo de CPU o memoria sin causa aparente.
• Tu proveedor de hosting te ha avisado de un uso excesivo de recursos.
• Tu tienda ha sufrido caídas intermitentes que no tienen una explicación clara.
• Apareces en comparadores de precios o tienes competidores activos que podrían usar scrapers.

Descarga gratuita

Puedes descargar el módulo Amarillo Limón Limit Category Results desde este enlace: amarillolimonlimitcategoryresults.zip

Si tienes cualquier duda sobre la instalación o quieres que echemos un vistazo a la configuración de tu tienda, no dudes en contactarnos. En Amarillo Limón llevamos años trabajando con PrestaShop y estaremos encantados de ayudarte.

¿Qué es el ROI (Return on Investment)?

El ROI mide la rentabilidad de una acción de marketing comparando los beneficios obtenidos con la inversión realizada. Es una de las métricas más utilizadas porque permite saber rápidamente si una campaña, canal o estrategia es rentable. Un ROI positivo indica que la inversión genera beneficios, mientras que uno negativo señala pérdidas.

Si una empresa invierte 1.000 € en una campaña de paid media y genera 1.500 € en ingresos atribuibles. El ROI es del 50 %, lo que indica que la acción es rentable y escalable.

¿Qué es el ROA y cómo se aplica en marketing?

El ROA entendido de forma general como retorno sobre los activos, se utiliza para analizar la eficiencia del presupuesto invertido en acciones como campañas de Google Ads. En Amarillo Limón es uno de los conceptos que más nos escucharás repetir, ya que lo tenemos muy presente en nuestro día a día a la hora de determinar la rentabilidad de las distintas campañas, ya que permite evaluar si los recursos destinados a publicidad están generando ingresos de forma eficiente.

Es importante tener en cuenta que el ROA puede analizarse por canal, lo que facilita comparar el rendimiento entre distintas plataformas o estrategias.

Si invertimos 1.000 € en una campaña de Google y genera 20.000 € en ingresos, estaríamos hablando de que esa campaña tiene un ROA 20, pero la rentabilidad real dependería del margen de beneficio de cada proyecto.

¿Qué es el Coste de Adquisición de Cliente (CAC)?

El CAC indica cuánto cuesta, de media, conseguir un nuevo cliente. Incluye todos los gastos de marketing y ventas y es clave para evaluar si una estrategia de captación es sostenible a largo plazo.

El coste de adquisición de cliente también se puede determinar por canal o campaña, si queremos tomar datos más específicos.

Si una empresa invierte 10.000 € en marketing y ventas en un mes y adquiere 100 nuevos clientes, el CAC es de 100 € por cliente.

¿Qué es el Lifetime Value (LTV)?

El LTV representa el valor total que un cliente aporta a lo largo de toda su relación con la empresa. Compararlo con el CAC es fundamental para entender la rentabilidad real de un negocio y evaluar si el crecimiento es sostenible.

Personalmente, es un concepto que me encanta y que intento calcular en la mayoría de proyectos, ya que un LTV sólido determina si un coste de adquisición de cliente es rentable o no y, por tanto, permite guiar el resto de decisiones estratégicas del proyecto.

El Lifetime Value se ve directamente afectado por una buena estrategia de fidelización y reactivación de usuarios. Por ello, además de realizar acciones de prospección, es clave maximizar la retención de aquellos clientes que ya han confiado en nosotros.

Si un cliente genera 50 € mensuales durante una relación media de 24 meses, su LTV es de 1.200 €. Si el CAC es de 200 €, la relación LTV/CAC es positiva y el modelo es rentable.

¿Qué es la recurrencia media?

La recurrencia media mide la frecuencia con la que un cliente vuelve a comprar en un periodo determinado. Es una métrica clave para entender el comportamiento del cliente y la salud del negocio, ya que impacta directamente en el LTV y en la rentabilidad global del proyecto.

Una recurrencia elevada suele indicar una buena experiencia de usuario, una propuesta de valor sólida y estrategias efectivas de fidelización. Además (Como decíamos antes) cuanto mayor es la recurrencia, menor es la dependencia de la captación constante de nuevos clientes, lo que reduce la presión sobre el CAC y mejora la eficiencia de la inversión en marketing.

Si un cliente realiza de media 6 compras al año frente a otro que solo compra una vez, el primero tendrá un mayor LTV y permitirá amortizar mejor el coste de adquisición.

¿Qué es la tasa de conversión?

La tasa de conversión indica el porcentaje de usuarios que realizan una acción deseada dentro de un canal o campaña, como una compra, un registro o una solicitud de contacto.

Es una de las métricas más relevantes para medir la eficacia de una estrategia, ya que permite evaluar el rendimiento sin necesidad de aumentar la inversión en tráfico.

Optimizar la tasa de conversión implica trabajar sobre factores como la experiencia de usuario, el mensaje, la propuesta de valor, el diseño o el proceso de compra. Pequeñas mejoras en este indicador pueden tener un impacto significativo en los ingresos y en la eficiencia global del marketing, especialmente cuando el volumen de tráfico es elevado.

Si una landing page recibe 10.000 visitas y convierte 300 usuarios, la tasa de conversión es del 3 %. Mejorar ese ratio al 4 % supondría 100 conversiones adicionales sin incrementar el gasto en captación.

¿Qué es el ticket medio?

El ticket medio indica el importe promedio que un cliente gasta en cada compra. Es una métrica clave para analizar el rendimiento comercial, ya que impacta directamente en los ingresos y en la rentabilidad del negocio sin necesidad de aumentar el volumen de clientes.

Incrementar el ticket medio suele estar relacionado con estrategias como upselling, cross-selling, packs de producto, o incentivos como envíos gratuitos a partir de un determinado importe.

Trabajar este indicador permite maximizar el valor de cada transacción y mejorar métricas como el LTV.

Si un ecommerce genera 50.000 € a partir de 1.000 pedidos, el ticket medio es de 50 €. Aumentarlo a 60 € supondría un incremento directo de ingresos sin aumentar el tráfico.

Como indicaba al principio, la mayoría de estos conceptos solo intentan reflejar una serie de datos que son útiles para determinar el rumbo que están siguiendo nuestras acciones y estrategias.

El conocerlos marcará la diferencia entre ir a ciegas y tomar decisiones fundamentadas.

Se que hay muchos otros conceptos que utilizáis en vuestro día a día y que quizás me he dejado por el camino, así que os leo en comentarios y los añado a este listado!

Los clientes, cuando un producto queda sin stock, lo desactivan (pasa a ser un 404), lo redireccionan hacia su categoría predeterminada o incluso nos piden devolver un 403.

Sin embargo, existen muchas casuísticas diferentes y cada una debe tratarse de forma distinta. En este post intentaré abordar todas ellas para ofrecer una pequeña “guía” y que sepáis cómo actuar de cara al SEO según vuestro tipo de catálogo, la disponibilidad de los productos y su recurrencia.

Tipos de catálogo en e-commerce de cara al SEO

A nivel de e-commerce, existen diferentes tipos de catálogos y, aunque puede haber muchos más tipos, vamos a definir los principales en los siguientes:

Catálogo de productos estándar

Llamemos a este catálogo estándar. Un catálogo que cada X se suben nuevos productos, otros se quedan sin stock, otros se descatalogan porque son antiguos/no interesan a nivel de negocio o cualquier otro caso… Etc. Un catálogo que fluctúa en el tiempo.

Catálogos con productos permanentes

Este tipo de catálogos suele ser el más sencillo de trabajar aunque no suele ser muy común. Al no tener mucha fluctuación en stock, su mantenimiento es muy fácil. Optimizamos fichas de producto, trabajamos titles, enlazado interno, una buena categorización SEO y a hacer lo mismo con los nuevos productos. No tendremos que hacer redirecciones ni dejar sin stock productos.

Catálogos con productos estacionales

Catálogos centrados en rebajas, diferentes campañas (Black Friday, Navidad, Vuelta al cole…).

Diferentes tipos de catálogo y diferentes casos. No todos son iguales ni todos pueden tratarse igual, y obviamente como todo en SEO cada caso puede ser diferente por el proyecto que se trabaja, pero intentaremos dar unas directrices para cada tipo de acción en el catálogo.

Diferencia entre sin stock y producto descatalogado

Aunque en muchas ocasiones se utilizan como sinónimos, un producto sin stock y un producto descatalogado no son lo mismo, ni a nivel de negocio ni, sobre todo, a nivel SEO.

Un producto sin stock es aquel que, en un momento determinado, no puede venderse porque no hay unidades disponibles, pero cuya reposición es posible o incluso probable. Puede tratarse de una rotura puntual, de un proveedor con retrasos o de un producto estacional que volverá a estar disponible en el futuro. Desde el punto de vista del buscador, sigue siendo un producto válido y relevante, ya que mantiene su intención de búsqueda y puede volver a ser comercializable.

Por el contrario, un producto descatalogado es aquel que no va a volver a venderse. Ya sea porque ha quedado obsoleto, se ha sustituido por otro modelo, no interesa a nivel de negocio o ha dejado de fabricarse, su ciclo de vida ha terminado. En este caso, la URL pierde su función comercial y, dependiendo del contexto, también puede perder su valor SEO.

Diferenciar correctamente entre ambos escenarios es clave, ya que una mala decisión en este punto puede provocar pérdida de tráfico orgánico, enlaces rotos o una mala experiencia de usuario.

Factores a tener en cuenta antes de decidir qué hacer con un producto

Antes de tomar cualquier decisión sobre un producto sin stock o descatalogado, es importante analizar una serie de factores. No todos los productos deben tratarse igual, incluso aunque se encuentren en la misma situación de disponibilidad.

Algunos de los factores más importantes a tener en cuenta son:

• Tipo de catálogo: no se gestiona igual un catálogo permanente que uno estacional o uno con alta rotación de productos.
• Recurrencia del producto: si el producto suele volver a estar disponible o no.
• Histórico de tráfico orgánico: si la ficha ha recibido tráfico desde buscadores y en qué volumen.
• Posicionamiento de la URL: keywords posicionadas y visibilidad SEO.
• Enlaces externos: si la ficha de producto tiene backlinks.
• Intención de búsqueda: si el usuario busca información, comparación o compra directa.
• Relación con otros productos: existencia de productos equivalentes, sustitutos o versiones más nuevas.
• Experiencia de usuario: qué se va a encontrar el usuario cuando acceda a esa URL.

Analizar estos factores permite tomar decisiones basadas en datos y no únicamente en criterios de negocio o automatismos del CMS.

Qué hacer en cada caso según el estado del producto

Una vez diferenciados los tipos de producto y analizados los factores anteriores, ya podemos definir qué acciones son más adecuadas en cada escenario.

Producto sin stock (temporal)

Cuando un producto está sin stock, pero existe la posibilidad de que vuelva a estar disponible, lo más recomendable suele ser mantener la URL activa.

En estos casos, la ficha sigue teniendo valor SEO y puede seguir posicionando para sus palabras clave. Además, eliminarla o redireccionarla prematuramente puede provocar una pérdida innecesaria de visibilidad.

Algunas buenas prácticas en este escenario son:

• Indicar claramente que el producto no está disponible temporalmente.
• Ofrecer productos alternativos o relacionados.
• Permitir avisos de reposición si es posible.
• Mantener el contenido optimizado de la ficha.

Producto descatalogado sin sustituto claro

Cuando un producto está descatalogado y no existe un sustituto directo o equivalente, la decisión dependerá en gran medida de su valor SEO.

Si la URL no tiene tráfico, no posiciona y no cuenta con enlaces relevantes, puede tener sentido eliminarla correctamente, devolviendo el código de estado adecuado.

Si, por el contrario, la ficha tiene tráfico o enlaces, conviene valorar otras opciones antes de eliminarla para no perder ese valor acumulado. En este caso, la opción más viable es redireccionar a uno lo más similar posible. Si no existiese, como última opción y solo si encaja, a una categoría.

Producto descatalogado con sustituto o versión nueva

Este es uno de los escenarios más habituales. Un producto deja de venderse porque ha sido reemplazado por una versión más nueva o por un producto muy similar.

En estos casos, suele ser recomendable redirigir la URL antigua hacia el nuevo producto, siempre que la intención de búsqueda sea equivalente. De esta forma, se conserva gran parte del valor SEO y se mejora la experiencia del usuario.

Catálogos estacionales

En catálogos estacionales, la gestión cambia ligeramente. Muchos productos desaparecen durante meses para volver a estar disponibles en la siguiente campaña.

Aquí suele ser más interesante mantener las URLs activas fuera de temporada, adaptando el contenido a un enfoque más informativo o de anticipación, en lugar de eliminar o redireccionar sistemáticamente las fichas.

No siempre todo es X ni todo es Y, pero si podéis guiaros un poco si necesitáis ayuda en alguno de estos casos con vuestro catálogo. Recordad que una URL de producto puede ser la entrada de muchísimos usuarios, y quien entra a un producto va a comprar, ya que una URL no puede ser más transaccional.

Si necesitáis ayuda con la gestión de vuestro catálogo a nivel SEO o cualquier gestión relacionada con vuestro e-commerce, contactad con nosotros y estaremos encantados de trabajar con vosotros.

Si buscas mejorar el rendimiento, detectar cuellos de botella o resolver errores críticos, esta guía te ayudará a analizar cualquier instalación de PrestaShop paso a paso.

1. Activar el Modo Debug en PrestaShop: el primer paso para encontrar errores

El Modo Debug es la herramienta esencial para detectar errores en PrestaShop. Cuando está activo, la plataforma deja de ocultar fallos y muestra información detallada como:

• Errores PHP
• Excepciones de Symfony
• Variables sin definir
• Avisos de módulos y plantillas Smarty

Cómo activar el modo debug

Desde el back office:

Parámetros avanzados → Rendimiento → Modo debug

Si la tienda no carga, puedes activarlo manualmente editando defines.inc.php:

if (!defined('_PS_MODE_DEV_')) {
    define('_PS_MODE_DEV_', true);
}

Es la forma más rápida de detectar errores críticos que afectan al funcionamiento de la tienda o al rendimiento.

2. Profiler de PrestaShop: analiza el rendimiento y localiza cuellos de botella

El profiler es la herramienta más completa para analizar el rendimiento de PrestaShop. Muestra datos técnicos que permiten saber qué está ralentizando las páginas o qué módulos están consumiendo demasiados recursos.

Qué información ofrece el profiler

• Número de consultas SQL por página
• Tiempo de ejecución total
• Memoria utilizada
• Hooks ejecutados
• Módulos activos en cada punto
• Plantillas y componentes cargados

Cómo activarlo

if (!defined('_PS_DEBUG_PROFILING_')) {
    define('_PS_DEBUG_PROFILING_', true);
}

El profiler es ideal para encontrar consultas lentas, detectar módulos mal optimizados y analizar qué causa la lentitud general de la tienda.

3. Logs de Symfony: errores ocultos que afectan al rendimiento

Desde PrestaShop 1.7, Symfony gestiona gran parte del núcleo de la plataforma, y sus logs contienen información valiosa que no aparece en pantalla ni en el modo debug.

Ubicación de los logs

/var/logs/dev.log
/var/logs/prod.log

En ellos encontrarás:

• Errores silenciosos que no se muestran en el front
• Excepciones internas
• Problemas de compilación de servicios
• Deprecaciones que anticipan fallos futuros

Son imprescindibles para diagnosticar fallos profundos en PrestaShop.

4. Logs del servidor: Apache, Nginx y PHP

Muchos problemas en PrestaShop provienen del servidor, no del código. Los logs del servidor revelan errores de PHP, fallos de permisos, problemas de memoria y errores 502/504.

Ubicaciones más frecuentes

/var/log/apache2/error.log
/var/log/nginx/error.log
/var/log/php8.x-fpm.log

Son especialmente útiles cuando la tienda muestra páginas en blanco, errores 500 o lentitud extrema.

5. Logs internos de PrestaShop: errores funcionales del día a día

PrestaShop incorpora un sistema de logs accesible desde:

Back Office → Parámetros avanzados → Logs

Se utilizan para detectar:

• Errores en el proceso de compra
• Problemas de módulos
• Fallas en controladores del BO
• Excepciones funcionales

Son la mejor herramienta para rastrear errores relacionados con pedidos, clientes o carritos.

6. Auditoría selectiva de módulos: una metodología más eficiente que desactivar todo

A menudo se dice que más del 70% de los problemas en PrestaShop provienen de módulos de terceros. Aunque es cierto, desactivar todos los módulos no siempre es una opción viable, especialmente en tiendas grandes donde cada módulo cumple una función crítica y su desactivación puede afectar a ventas, SEO o funcionalidades clave.

Por eso, en lugar de desactivar indiscriminadamente, la técnica correcta es realizar una auditoría selectiva y ordenada de módulos siguiendo criterios técnicos.

Método profesional para identificar el módulo problemático

En vez de apagar toda la tienda, sigue esta estrategia:

• 1. Revisar el profiler primero: te indica qué módulos están ejecutando más consultas, ocupan más memoria o cargan más hooks.
• 2. Analizar los hooks implicados: si el error ocurre en la ficha de producto, céntrate en los módulos enganchados a displayProductAdditionalInfo, header, productFooter, etc.
• 3. Comprobar overrides cargados: muchos fallos provienen de un override que sigue activo aunque desactives el módulo. Revisa /override/ o el panel de “Modos de depuración”.
• 4. Desactivar solo los módulos relacionados con la zona del fallo:
  • problemas en checkout → módulos de pago, transportistas, OPC, validaciones
  • problemas en producto → módulos de personalización, precios, variaciones, sliders
  • problemas de velocidad → módulos con muchos hooks, analítica, búsqueda, facetas
• 5. Priorizar módulos recientes o recién actualizados: el 90% de errores aparece tras:
  • una actualización de módulo
  • una actualización de PrestaShop
  • una instalación reciente
• 6. Revisar los logs antes de desactivar nada: muchas veces el log indica el nombre del módulo directamente.
• 7. Probar primero desactivar módulos “no críticos”: analítica, banners, popups, integraciones externas, módulos visuales, etc.

¿Qué problemas permite detectar esta técnica?

• Overrides que interfieren con el Core o entre módulos.
• Módulos que añaden demasiadas consultas SQL en cada página.
• Scripts o CSS que rompen el checkout o el comportamiento de los botones.
• Hooks ejecutándose en momentos incorrectos, cargando lógica cuando no debería.
• Módulos duplicados o obsoletos instalados desde PS 1.6.

Este método evita romper la tienda, reduce tiempos de diagnóstico y permite encontrar el origen del problema sin riesgos ni pruebas innecesarias.

7. Inspector del navegador: detecta errores de JavaScript y CSS

El inspector del navegador (Chrome, Firefox) es imprescindible para analizar el front-end de PrestaShop. Permite encontrar:

• Errores JavaScript
• CSS que modifica el layout
• Petición fallidas
• Recursos externos lentos
• Problemas de caché o CORS

Especialmente útiles las pestañas:

• Console: para errores JS
• Network: para peticiones lentas
• Performance: para medir bloqueos
• Lighthouse: para auditar rendimiento

8. EXPLAIN en MySQL: analiza consultas lentas

Si el profiler muestra que una consulta SQL tarda demasiado, puedes analizarla con:

EXPLAIN SELECT ...

Esto te ayuda a detectar:

• Falta de índices
• Joins pesados
• Full scans innecesarios
• Problemas en tablas grandes

9. Herramientas del hosting y del servidor: el último nivel del diagnóstico

A veces el problema no es PrestaShop, sino el servidor. Las herramientas del hosting permiten revisar:

• Consumo de CPU
• Memoria disponible
• Procesos saturados
• Limitaciones de PHP
• Problemas de firewall or CDN

Estos datos son clave para diagnosticar lentitud, errores masivos o caídas del sitio.

Conclusión: la clave para encontrar errores en PrestaShop es usar todas las herramientas

La combinación correcta de estas herramientas permite identificar cualquier error o problema de rendimiento en PrestaShop:

• Debug para ver el error en pantalla
• Profiler para analizar rendimiento
• Logs para errores ocultos
• MySQL para consultas lentas
• Inspector para fallos de front-end
• Servidor para problemas de infraestructura

Con esta metodología, cualquier fallo por complejo que sea se puede diagnosticar de forma rápida y profesional. Si aún con esto necesitas ayuda adicional, no dudes en contactar con nosotros y te ayudaremos a arreglar tu problema en PrestaShop.