Tu web recibe visitas, pero no contactos: qué revisar primero

Una web puede tener un problema muy sencillo que un cambio visual no resolverá: el formulario muestra una confirmación, pero el mensaje no llega a quien debe responder. También puede haber un teléfono incorrecto o un botón que solo abre una aplicación de correo sin completar el envío.

Haz una prueba con datos de prueba identificados, desde un móvil y un ordenador. Comprueba el proceso completo: abrir, rellenar, enviar y recibir. Después confirma quién ve la consulta y qué sucede si esa persona no está disponible. No basta con comprobar que el botón se puede pulsar.

• ¿El teléfono visible y el enlace marcan el mismo número?
• ¿El formulario explica los errores y conserva lo ya escrito?
• ¿La confirmación describe lo que ha ocurrido realmente?
• ¿La consulta llega al destino correcto?
• ¿Hay una forma alternativa de contactar si falla el formulario?

Si detectas un fallo, corrígelo y repite la prueba. Así separas un problema funcional de uno de captación.

El total de visitas puede esconder situaciones muy diferentes. Un artículo informativo puede recibir lectores de lugares donde no trabajas; una página de servicio puede recibir pocas visitas, pero de personas que sí tienen una necesidad. No conviene valorar ambas con el mismo criterio.

Si tienes Search Console, revisa consultas y páginas de entrada desde Google. Esa información se refiere a la búsqueda orgánica y no representa por sí sola todo el tráfico ni todos los contactos. La guía de Google sobre Search Console y Analytics explica que ambas herramientas ofrecen perspectivas diferentes.

Con publicidad, comprueba además que cada anuncio dirige a una página relacionada con lo que promete. Si alguien busca una instalación específica y llega a una portada con diez servicios, tendrá que hacer trabajo adicional para encontrar la respuesta.

La empresa conoce sus servicios de memoria; el visitante, no. Una página debería permitir entender qué haces, para quién, en qué zona y qué puede pedirte. Las frases genéricas sobre calidad o compromiso no sustituyen esa información.

Imagina una empresa de instalaciones que quiere captar proyectos de renovación. Si la web habla principalmente de urgencias, puede estar preparando expectativas distintas de las que necesita el negocio. El problema no se arregla haciendo más grande el botón de contacto: primero hay que alinear la oferta.

En Eléctrica Levante, el proyecto documentado separa servicios eléctricos y localidades. Esa arquitectura permite presentar necesidades diferentes con más detalle. Es un ejemplo de organización de la información, no una demostración de que cualquier página adicional vaya a generar clientes.

• Nombra el servicio con palabras que entienda el comprador.
• Explica qué incluye y qué necesitas para valorarlo.
• Indica la cobertura real.
• Muestra un trabajo relacionado cuando exista.
• Describe qué pasará después del contacto.

Las fotografías y capturas aportan valor cuando explican algo. Un proyecto con contexto permite entender el tipo de trabajo, el papel de la empresa y la solución aplicada. Una galería sin explicación puede resultar atractiva y aun así dejar sin resolver las dudas del cliente.

En un catálogo técnico como el de Confrio, conviene distinguir entre explorar productos y solicitar asesoramiento. Quien conoce lo que busca puede avanzar por el catálogo; quien necesita confirmar una solución requiere una vía de consulta clara. No todos los visitantes están listos para dar el mismo paso.

Utiliza hechos que puedas sostener: proyectos reales, equipo, condiciones, proceso y opiniones auténticas. Si publicas una cifra, explica a qué periodo y trabajo corresponde. Si no hay datos suficientes, mostrar lo construido es más útil que presentar una mejora supuesta.

Abre la página con el teléfono y recorre el proceso como alguien que no conoce tu empresa. Comprueba si el texto se lee, si los botones se distinguen, si un elemento tapa el formulario y si puedes volver atrás sin perder el contexto.

Revisa también lo que pides. Para una primera consulta quizá baste con nombre, vía de contacto, servicio y zona. Otros datos pueden ser necesarios para una valoración técnica. Cada campo debe tener una razón; quitar todos tampoco es una buena solución si después el equipo no puede clasificar la solicitud.

Prepara una lista corta de problemas observados, su consecuencia y una acción. «El formulario no llega al buzón» es una observación. «La web es antigua» es una impresión que necesita más contexto para convertirse en prioridad.

Corrige primero los bloqueos funcionales y de comprensión. Después revisa si la plataforma permite mantener contenidos, ampliar servicios y atender las necesidades del negocio. Una reconstrucción tiene sentido cuando la base limita esas mejoras o hace inviable mantenerla; no debería ser la respuesta automática a cualquier falta de contactos.

Anota cuándo aplicas cada cambio y revisa qué ocurre con datos comparables. Si el volumen es pequeño, combina los números con preguntas reales de los clientes y pruebas de uso. El objetivo es aprender qué ayuda a decidir, no atribuir a un cambio de diseño todas las variaciones posteriores.