Qué resuelvo
Lo que llega, dónde está la causa y cómo lo resuelvo
Problemas que resuelvo en webs de agencias. Trabajo en marca blanca y con confidencialidad, así que los cuento sin datos que permitan identificar a ninguna empresa ni a su cliente.
Especialidad
Mostrando 13 de 13 problemas
«Las conversiones de Ads se han duplicado desde que cambiamos el formulario»
«Las conversiones de Ads se han duplicado desde que cambiamos el formulario»
Dónde suele estar la causa
La conversión se dispara en el envío y otra vez en la página de gracias, o GTM está cargado dos veces: desde un plugin y desde el código del tema.
Cómo lo resuelvo
Dejo una sola fuente de verdad: un evento en el dataLayer tras la respuesta correcta del servidor, con un identificador para deduplicar en Google Ads.
Cómo lo compruebo
GTM Preview y Tag Assistant: un envío correcto produce una conversión; un envío fallido, ninguna.
«Desde que pusimos el banner, GA4 ha perdido la mitad de los usuarios»
«Desde que pusimos el banner, GA4 ha perdido la mitad de los usuarios»
Dónde suele estar la causa
El estado de consentimiento por defecto se declara después de que carguen las etiquetas, o el banner no envía la actualización cuando el usuario acepta.
Cómo lo resuelvo
Orden correcto (default antes de GTM), update desde el callback del banner y revisión de los cuatro parámetros. Separo la caída legítima, la de quienes rechazan, de la que es un error de implementación.
Cómo lo compruebo
Pestaña Consent de Tag Assistant al aceptar, al rechazar y con aceptación parcial.
«El selector de fechas se abre detrás de la ventana modal o fuera de sitio»
«El selector de fechas se abre detrás de la ventana modal o fuera de sitio»
Dónde suele estar la causa
Un contenedor padre con transform, filter u overflow crea un contexto de apilamiento nuevo y cambia la referencia de posición del componente. Subir el z-index no lo arregla.
Cómo lo resuelvo
Localizo el ancestro que lo provoca. Hago que la librería pinte el componente en el body, si tiene esa opción; si no, corrijo la estructura en lugar de forzar el z-index.
Cómo lo compruebo
Dentro y fuera de la modal, con scroll y en móvil.
«Actualizamos dependencias, compila sin errores, pero un componente ha dejado de funcionar»
«Actualizamos dependencias, compila sin errores, pero un componente ha dejado de funcionar»
Dónde suele estar la causa
Un cambio incompatible dentro de una versión menor, o una dependencia de una dependencia que se actualizó con el lockfile.
Cómo lo resuelvo
Acoto el paquete y la versión culpables comparando lockfiles y con git bisect. Adapto el código a la nueva API o fijo la versión, y lo documento para la próxima actualización.
Qué entrego
El componente funcionando, la versión fijada o corregida y una prueba que avisa si vuelve a romperse.
«Después de navegar un rato por la aplicación, todo va cada vez más lento»
«Después de navegar un rato por la aplicación, todo va cada vez más lento»
Dónde suele estar la causa
Suscripciones y listeners que no se cancelan al destruir el componente y se acumulan en cada visita.
Cómo lo resuelvo
Comparo instantáneas de memoria antes y después de repetir la navegación. Cancelo las suscripciones al destruir el componente: takeUntilDestroyed en Angular 16 o posterior; unsubscribe en versiones anteriores.
Cómo lo compruebo
La memoria se estabiliza al repetir el mismo recorrido.
«Search Console marca el INP en rojo en las fichas de producto»
«Search Console marca el INP en rojo en las fichas de producto»
Dónde suele estar la causa
Un widget de terceros (chat, reseñas) o un script que hace trabajo largo y síncrono al interactuar.
Cómo lo resuelvo
Localizo la interacción lenta en una traza de rendimiento, divido o aplazo ese trabajo y cargo el widget solo cuando hace falta.
Cómo lo compruebo
Trazas antes y después sobre la misma interacción. Los datos de campo de Search Console tardan unas cuatro semanas en reflejarlo.
«Los pedidos han dejado de llegar al ERP y la tienda no muestra ningún error»
«Los pedidos han dejado de llegar al ERP y la tienda no muestra ningún error»
Dónde suele estar la causa
Un webhook que WooCommerce desactivó tras varios fallos de entrega seguidos, o credenciales de la API rotadas sin actualizar en el otro extremo.
Cómo lo resuelvo
Restablezco la conexión, reenvío los pedidos afectados y añado un aviso para cuando vuelva a fallar.
Qué entrego
La lista de pedidos afectados y cómo se reenvió cada uno.
«Al subir la versión de PHP, la web se queda en blanco»
«Al subir la versión de PHP, la web se queda en blanco»
Dónde suele estar la causa
Funciones eliminadas en PHP 8 dentro de un tema antiguo o de un plugin abandonado.
Cómo lo resuelvo
Entorno de pruebas con la versión de destino, análisis de compatibilidad y correcciones en el tema hijo o en un mu-plugin, sin tocar el núcleo. Sustituyo los plugins que ya no se mantienen.
Qué entrego
La web en la nueva versión de PHP y la lista de cambios, con cómo revertir cada uno.
«El formulario no avisa de los errores a quien usa lector de pantalla»
«El formulario no avisa de los errores a quien usa lector de pantalla»
Dónde suele estar la causa
Los mensajes de error solo se muestran visualmente y no están asociados al campo.
Cómo lo resuelvo
Asocio cada mensaje a su campo, marco los campos no válidos y llevo el foco al primer error o a un resumen de errores.
Cómo lo compruebo
Con teclado, NVDA y VoiceOver, en el formulario real.
«Tenemos el informe de accesibilidad. ¿Quién corrige ahora el código?»
«Tenemos el informe de accesibilidad. ¿Quién corrige ahora el código?»
Dónde suele estar la causa
Decenas de incumplimientos que en realidad salen de unos pocos componentes. Si se corrigen página por página, reaparecen en la siguiente.
Cómo lo resuelvo
- HTML
- Cada campo con su label asociado e instrucciones visibles (1.3.1, 3.3.2)
- Botones e iconos con nombre accesible que coincide con el texto visible (4.1.2, 2.5.3)
- Encabezados y regiones con estructura real (1.3.1)
- Textos alternativos con sentido (1.1.1) e idioma de la página declarado (3.1.1)
- CSS
- Contraste del texto (1.4.3) y de bordes, iconos y estados (1.4.11)
- Foco siempre visible (2.4.7)
- Zoom al 200 % sin perder contenido (1.4.4)
- Reajuste a 320 px sin scroll horizontal (1.4.10) y espaciado de texto (1.4.12)
- JavaScript
- Todo se puede usar con teclado (2.1.1) y el foco nunca queda atrapado (2.1.2)
- Orden de tabulación lógico, sin tabindex positivos (2.4.3)
- Menús, acordeones y pestañas con su estado actualizado (4.1.2)
- Mensajes de estado que el lector de pantalla anuncia (4.1.3)
Prioridad: Primero lo que impide usar la web (teclado, formularios, controles sin nombre); después, lo que la dificulta.
Cómo lo compruebo
Cada corrección contra el criterio del informe, con teclado, NVDA y VoiceOver, zoom y reajuste. Las herramientas automáticas sirven de apoyo, no de prueba.
Qué entrego
Una tabla con criterio, componente, cambio y cómo revertirlo. No es una certificación: el cumplimiento lo confirma una nueva revisión del informe.
«Hay que cambiar de hosting y de dominio a la vez sin perder correo, posicionamiento ni pedidos»
«Hay que cambiar de hosting y de dominio a la vez sin perder correo, posicionamiento ni pedidos»
Dónde suele estar la causa
Lo que suele salir mal: URLs del dominio antiguo guardadas en datos serializados (un reemplazo directo en SQL los corrompe), TTL alto en el DNS, correo sin migrar, otra versión de PHP en el servidor nuevo y tareas programadas que no se trasladan.
Cómo lo resuelvo
Copia completa en el servidor nuevo, probada antes de cambiar el DNS. Reemplazo de URLs con WP-CLI respetando la serialización, TTL reducido con antelación, buzones y registros MX, SPF y DKIM migrados, 301 de URL a URL y cambio de dirección en Search Console. Igual entre paneles distintos, por ejemplo de Ferozo a cPanel.
Cómo lo compruebo
Rastreo del dominio antiguo, envío y recepción de correo, y un pedido o formulario de prueba completo.
«Nos han hackeado la web: no hay administrador, los plugins están desactivados y el servidor envía spam»
«Nos han hackeado la web: no hay administrador, los plugins están desactivados y el servidor envía spam»
Dónde suele estar la causa
Un plugin vulnerable sin actualizar y, casi siempre, puertas traseras que siguen ahí aunque se arregle lo visible.
Cómo lo resuelvo
Aíslo la web y cambio todas las credenciales (base de datos, FTP/SSH, panel y claves de seguridad de WordPress). Reinstalo núcleo y plugins desde fuentes oficiales, reviso el tema archivo a archivo, elimino los PHP de las subidas y bloqueo su ejecución. Limpio usuarios, opciones y contenido inyectado en la base de datos, y reviso las cuentas de correo y la cola de envío.
Cómo lo compruebo
wp core verify-checksums y wp plugin verify-checksums, registros del servidor, informe de seguridad de Search Console y listas negras de correo.
Encargos pequeños que resuelvo
- Menú o maquetación descolocados en móvil
- Plugin incompatible tras una actualización
- Saltos de contenido al cargar (CLS) por imágenes o fuentes
- Etiqueta de GTM que deja de dispararse tras cambiar el HTML de un botón
- Correos de formularios que llegan a spam (SMTP, SPF, DKIM)
- Errores 404 después de cambiar la estructura de URLs
- Foco invisible en enlaces y botones (2.4.7)
- Avisos de PHP obsoleto en el log tras una actualización