Las decisiones que más cuesta cambiar de una web nueva se toman antes de la primera línea de código

El diseño decide cómo se ve la web y cómo se entiende: composición, jerarquía, colores y recorrido. El desarrollo la construye para que funcione: estructura de direcciones, plataforma, velocidad, seguridad, formularios, medición e indexación. En un proyecto real van juntos, pero responden preguntas diferentes y a menudo los llevan personas diferentes. La confusión sale cara cuando el presupuesto solo habla del primero y el segundo se da por descontado. Antes de firmar, vale la pena pedir que las dos partes consten por escrito.

Ninguno, por sí solo. Lo que cuenta es que el contenido importante llegue dentro del HTML que recibe el buscador y no dependa de un script para aparecer. La guía de Google sobre JavaScript explica que lo procesa en tres fases —rastreo, renderizado e indexación— y recuerda que renderizar en el servidor o prerrenderizar sigue siendo buena idea, porque no todos los robots pueden ejecutar JavaScript. Con esta condición cumplida, la elección depende más de quién mantendrá la web que del posicionamiento.

Depende de cuatro cosas más que de la fama de cada plataforma: el tamaño y la complejidad del catálogo, quién gestionará los pedidos, con qué programas se tiene que conectar y quién la mantendrá. Una plataforma instalada en tu servidor da control y pide mantenimiento continuo; un servicio alojado pide menos y te ata a sus reglas y extensiones. Ninguna de las dos es mejor en abstracto. Si alguien te recomienda una sin haberte hecho estas preguntas, vale la pena preguntarle por qué.

Porque raramente presupuestan lo mismo. Uno puede incluir solo la maqueta y la publicación; el otro, el entorno de pruebas, la medición configurada, la revisión de indexación antes de estrenar y la documentación para que otro equipo pueda mantenerla. Para compararlos, pide una lista de lo que incluye cada uno y, sobre todo, de lo que no incluye. En Daimatics el precio y las condiciones se hablan en la reunión, una vez entendido qué tiene que hacer la web.

Como mínimo, cinco cosas. Que se haya retirado la orden de no indexar que suele llevar el entorno de pruebas. Que el robots.txt no bloquee secciones que se tienen que encontrar. Que cada página tenga título y URL canónica propios. Que el mapa del sitio esté enviado a Search Console, en una propiedad a tu nombre. Y, si la web sustituye a otra, que todas las direcciones antiguas redirijan a la nueva equivalente. La última es la que más posicionamiento hace perder cuando se olvida.

La referencia más útil son las Core Web Vitals de Google. Según web.dev, para ofrecer una buena experiencia el contenido principal debería cargar en 2,5 segundos o menos, la página debería responder a una interacción en 200 milisegundos o menos y el desplazamiento visual acumulado debería quedar en 0,1 o menos, medido sobre el 75 % de las cargas, en móvil y en ordenador. En una web nueva, estos valores se fijan como límite antes de diseñar.

De la empresa que la paga. El dominio, Analytics, Search Console, la ficha de Google y las cuentas publicitarias deberían ser del negocio, y el proveedor debería entrar con usuarios y permisos propios. Si el titular es la agencia, el día que quieras cambiar de equipo dependerás de su buena voluntad. En Daimatics la web y las cuentas quedan a nombre del cliente, y no hay permanencias que aten: para dejarlo, basta con avisar unos quince días antes.

Igual que para que la lea bien una persona. Google dice que para sus funciones de IA no hacen falta archivos de texto especiales ni ningún marcado concreto, y que se basan en el ranking de siempre. Su guía también explica que los agentes de navegador pueden leer capturas, el código y el árbol de accesibilidad: por eso cuentan el texto real en lugar de imágenes con letras, los botones con nombre y los formularios con etiqueta. Y hay que vigilar que ninguna plantilla lleve nosnippet o noindex donde no toca.

Depende de qué falla. Si la web se entiende, se encuentra y convierte, pero se ve anticuada, suele bastar con un cambio de diseño. Si va lenta o se rompe con cada actualización, primero hay que saber por qué: puede ser un problema de mantenimiento, no de construcción. Tiene sentido hacerla de nuevo cuando lo que no sirve son los cimientos: la plataforma, la estructura o los idiomas. Y si se hace, la web antigua no se tira: se migra, con las redirecciones de todas las direcciones que ya reciben visitas.