WooCommerce redirige a otra web: pago previsto, configuración o malware

WooCommerce debería llevar al cliente por el recorrido que habéis previsto

Si WooCommerce envía a un cliente a otra web sin una razón prevista, localiza en qué momento ocurre antes de editar la tienda. Una página del proveedor de pagos configurado, una regla incorrecta y una redirección maliciosa son casos distintos. El destino, el punto del recorrido y las condiciones que activan el salto ayudan a separarlos.

Una tienda puede parecer normal a su propietario y ofrecer otro resultado a un visitante. Eso no identifica la causa por sí solo. Sí significa que comprobar únicamente la portada desde el ordenador habitual del administrador deja la investigación incompleta.

Esta guía ayuda a decidir qué registrar, qué proteger y qué debería investigar un especialista. No diagnostica una infección de tu tienda ni representa una prueba de seguridad o de pago ya ejecutada.

Distingue una salida prevista de un destino inesperado

Una dirección con aspecto seguro o un logotipo conocido no acreditan el recorrido de pago. Compáralo con la documentación fiable del proveedor y la configuración autorizada de la tienda. No decidas siguiendo instrucciones que aparezcan en un destino inesperado.

Si el problema consiste en volver al mismo formulario de cuenta, empieza por la guía del acceso de clientes que vuelve al formulario WooCommerce. Un bucle de sesión dentro de la propia web no debe etiquetarse automáticamente como malware.

Una redirección de pago puede ser legítima, pero debe corresponder a la integración

Las interfaces de pago varían. Por ejemplo, Stripe documenta opciones de Checkout alojado y embebido —en inglés—. Esto confirma que una página alojada por el proveedor puede formar parte del recorrido; no determina cómo está configurada tu extensión WooCommerce.

Aclara qué integración está instalada, qué método se eligió y qué destino debería utilizar. Revisa inicio y retorno con quien mantiene esa configuración. Así evitas convertir un salto normal en una limpieza de malware o justificar un destino ajeno solo porque aparece durante el checkout.

No introduzcas credenciales ni datos de pago en una página inesperada para comprobar qué pasa. Un especialista puede acordar una investigación controlada y, por separado, las pruebas posteriores que correspondan al proveedor de pagos.

Registra el disparador sin recopilar secretos de clientes

Anota URL pública inicial, hora aproximada y zona horaria, dominio de destino visible y punto del recorrido. ¿Ocurre al visitar un producto, añadirlo, abrir el carrito o volver del proveedor? Añade dispositivo, navegador y si la visita llegó desde Google o directamente.

Separa observaciones y conclusiones. «Una visita móvil desde buscador salió hacia otra web» aporta información útil. «El plugin de pagos está hackeado» necesita investigación que lo respalde. Las políticas de spam de Google —documentación en inglés— describen redirecciones engañosas diferentes según dispositivo; el patrón es pertinente, pero no diagnostica cualquier fallo móvil.

Para una primera valoración, comparte capturas revisadas o una descripción breve. Las URLs completas, grabaciones y exportaciones de red pueden contener identificadores de sesión, claves de pedido o información personal. No las publiques ni envíes datos de pago del cliente junto a la consulta.

Protege el estado actual antes de elegir una restauración

La prioridad es conservar un estado recuperable y acordar una contención adecuada al riesgo observado. Coordina esa decisión con el propietario y el hosting. Puede afectar a una ruta concreta o requerir una interrupción más amplia; no todos los incidentes necesitan la misma respuesta.

No sobrescribas la base actual con una copia antigua solo porque su portada se ve mejor. Identifica la fecha de la copia y la actividad posterior: pedidos, cuentas, devoluciones y otros cambios pertinentes. La documentación de restauración de WooCommerce —en inglés— explica riesgos del intervalo, incluidos registros ausentes y efectos sobre suscripciones cuando esa extensión se utiliza.

Acordad cómo se conserva el estado actual y cómo se concilian los registros del negocio antes de restaurar. Un archivo de páginas públicas no sustituye a los archivos de la tienda y sus datos operativos.

Pide evidencia que distinga servidor y navegador

El técnico puede comparar la respuesta inicial con lo que hace después el navegador. La guía de redirecciones de MDN —en inglés— distingue mecanismos HTTP, HTML y JavaScript. Una petición que no ejecuta scripts no permite establecer todos los resultados que experimenta un comprador.

Pide que se registre qué respuesta o recurso inicia la salida y qué demuestra la evidencia. Una captura de la barra de direcciones muestra un destino, pero puede omitir un paso intermedio. A la inversa, una traza sin las condiciones pertinentes puede no recoger el comportamiento comunicado por el cliente.

Separa la nota compartible de la exportación técnica detallada. La nota puede identificar ruta, momento, etapa observada y dominio de destino. Una exportación completa puede requerir acceso restringido y eliminación de cookies, valores de autorización, datos personales y parámetros de pedido antes de salir del equipo de diagnóstico.

Etiqueta también el entorno. Emular móvil en escritorio, utilizar un teléfono real, navegar con sesión o hacer una visita pública nueva son observaciones distintas. Deja indicado cuál se utilizó y qué sigue pendiente. Así el siguiente técnico tiene algo concreto que reproducir, sin convertir un recorrido en representación de todos los clientes.

Un ejemplo breve aclara el siguiente paso

Imagina que un comprador abre un producto desde Google en el móvil y acaba en un dominio ajeno antes de añadir nada al carrito. El propietario visita ese producto directamente desde escritorio y no observa el problema. Las dos observaciones justifican comparar origen y condiciones del navegador; no demuestran que el proveedor de pagos haya provocado el salto.

Una consulta útil conserva ambos resultados y la hora aproximada. Aclara que el recorrido comunicado no había iniciado el pago, identifica la ruta pública y describe por separado cualquier cambio reciente. Este ejemplo ficticio sirve para organizar la solicitud, no representa un incidente que hayamos diagnosticado.

Investiga el origen del salto, no solo la dirección visible

La revisión técnica puede necesitar comparar respuestas del servidor, comportamiento del navegador, ajustes de la tienda, scripts externos y capas de entrega. Una redirección del servidor y un script que cambia la ubicación después de cargar plantean investigaciones distintas.

Compara archivos y datos pertinentes con fuentes fiables y con su función prevista. Encontrar una etiqueta de script, un dominio desconocido o una cadena codificada no justifica por sí solo borrar un registro. Las extensiones e integraciones legítimas también contienen código que debe interpretarse.

Incluye los componentes de uso obligatorio cuando corresponda. La documentación de must-use plugins de WordPress —en inglés— distingue archivos PHP cargados directamente, subdirectorios y listado administrativo separado. Retirar plugins ordinarios no describe toda la aplicación.

Un diagnóstico útil identifica comportamiento implicado, evidencia y corrección propuesta. Debe diferenciar la causa demostrada de las partes que siguen sin examinarse.

Mantén visible el recorrido de compra esperado

Un mapa sencillo de carrito, datos del cliente, pago, revisión y confirmación ayuda a localizar una salida inesperada. La referencia de diseño siguiente hace tangibles esas etapas. No identifica dominios maliciosos ni verifica una integración de pago real.

Sobre un esquema de tu tienda, marca entrada permitida, salida al proveedor y retorno. Una referencia cuidada muestra estructura de interfaz; la configuración fiable y la investigación establecen qué debe hacer la implementación.

Compara contextos de cliente y respuestas de caché con cuidado

Acordad una muestra pequeña que represente el síntoma: ruta pública afectada, llegada directa y desde buscador si corresponde, y condiciones reales de dispositivo o navegador. Un administrador conectado puede recibir una respuesta distinta de la de un comprador nuevo.

Si la evidencia apunta a una respuesta afectada en caché, identifica capa y entradas que deban invalidarse después de corregir el origen. Borrar todas las sesiones de clientes o modificar todas las cuentas no sustituye a localizar esa capa.

Repite el caso que fallaba y registra el resultado. Superarlo establece lo ocurrido en esas condiciones. No demuestra que se hayan examinado todos los disparadores posibles, mecanismos de persistencia o pantallas ajenas al alcance.

Separa los pedidos anteriores de la corrección de la redirección

Un cliente puede haber salido de la tienda después de iniciar el pago mientras el pedido queda pendiente o su confirmación resulta confusa. No deduzcas el cobro a partir de la página de retorno ni pidas pagar otra vez únicamente para diagnosticar el salto.

Si el incidente afecta a una operación anterior, el equipo autorizado debe contrastar los registros pertinentes de tienda y proveedor. Utiliza las referencias necesarias sin introducir datos de tarjeta en registros o capturas públicas. Reparar la navegación no determina si una operación debe capturarse, devolverse o ajustarse de otra manera.

La guía de entrega y conciliación de incidencias de pago WooCommerce separa funcionamiento nuevo y casos históricos pendientes. Sus ejemplos ilustrativos y de laboratorio tienen límites expresos; no son pruebas sobre tu cuenta de proveedor.

Un aviso del navegador o de Google tiene su propio seguimiento

Si Search Console informa de un problema de seguridad, conserva el informe y sus URLs de ejemplo dentro de la investigación. Google explica que la muestra no tiene por qué cubrir todas las páginas afectadas —documentación en inglés— y que la revisión se solicita después de corregir los problemas indicados.

La entrega debe separar el comportamiento observado de la tienda de un aviso externo o revisión pendiente. No prometas plazos de retirada, recuperación de posiciones ni aprobación de otra plataforma porque haya pasado una comprobación local.

Acordad qué demostrará la reparación

Antes de cambiar nada, concretad recorridos afectados, acceso de investigación autorizado, conservación del estado y comprobaciones de aceptación. Al terminar, pide un resumen de causa establecida, corrección, condiciones revisadas y limitaciones pendientes.

En una tienda, incluye las rutas pertinentes de producto, carrito y cliente sin convertir la navegación pública en prueba de un pago completado. Cualquier comprobación específica del proveedor necesita acuerdos propios. Las pruebas esenciales después de reparar WooCommerce ayudan a decidir qué otros recorridos entran en el alcance.

Deja identificado quién mantiene la observación posterior y los casos de clientes sin resolver. Una captura de portada y un «todo arreglado» son demasiado vagos para explicar con qué puede contar el negocio.

Pide una valoración alrededor del recorrido real del cliente

El servicio de eliminación de redirecciones maliciosas en ecommerce sirve para investigar salidas inesperadas de la tienda y definir una reparación. Aporta URL pública, síntoma visible, momento, dispositivo afectado y cambios recientes. Un ejemplo revisado resulta más útil que una carpeta de datos de clientes sin comprobar.

Acordamos investigación y presupuesto antes de intervenir, incluidas conservación pertinente de datos y condiciones de seguimiento. Solicita una valoración de la redirección de tu ecommerce sin enviar contraseñas, datos de pago ni claves de pedidos activos.