La guía definitiva para el desarrollo web de empresas en el Reino Unido

Para quién es esta guía

Esto no es un tutorial. Está escrito para la persona que aprueba el sitio web: qué decidir, qué exigir y qué sabiduría recibida ignorar.

Cómo elegir una plataforma

La mayoría de los debates sobre plataformas son tribales. La decisión en realidad es bastante mecánica y se basa en una pregunta: ¿con qué frecuencia las personas no técnicas necesitan cambiar cosas?

WordPress

Sigue siendo la respuesta pragmática para una gran parte de las empresas del Reino Unido. Su responsable de marketing puede añadir una página de servicios, publicar un caso de estudio o cambiar un titular sin abrir un ticket. En doce meses, esa autonomía suele importar más que cualquier ventaja técnica, porque la frecuencia de publicación es el mayor factor de contenido que tienen la mayoría de las empresas.

Su punto débil no es WordPress en sí, sino lo que se acumula encima. Un constructor de páginas apilado sobre un tema con su propio constructor, más veinte plugins, produce cargas de cuatro segundos y una base de código que nadie quiere tocar. Si usa WordPress, úselo con intención: un constructor, pocos plugins y una disciplina real de actualizaciones.

Una construcción personalizada (Next.js o similar)

Justo cuando necesita lógica de aplicación, velocidad genuina o control preciso sobre el SEO técnico. Obtiene HTML renderizado en servidor, un techo de rendimiento muy por encima de una pila de plugins y una superficie de ataque más pequeña.

El coste es la flexibilidad editorial. A menos que también construya un modelo de contenido y una interfaz de administración adecuados —que es trabajo real—, cada nueva página de aterrizaje se convertirá en una tarea de desarrollo. Presupuéstelo o terminará con un sitio rápido que nadie puede actualizar.

La prueba honesta

Si su respuesta a "¿quién añade una nueva página?" es "nuestra persona de marketing, semanalmente", inclínese por WordPress. Si es "añadimos páginas dos veces al año y necesitamos que el sitio sea rápido y haga cosas", inclínese por la opción personalizada.

Qué afecta realmente a los rankings

Excluyendo la calidad del contenido, que es lo más importante, los fundamentos técnicos son poco glamurosos y a menudo están completamente ausentes:

• Un título y una meta descripción únicos por página, dentro de los límites aproximados de 60 y 160 caracteres, escritos para la consulta en lugar de empezar con el nombre de la empresa
• Un único H1 por página que describa la página — sorprendentemente, muchos sitios no tienen ninguno
• URLs canónicas, para que el mismo contenido en varias direcciones no compita consigo mismo
• Datos estructurados como un grafo interconectado: Organization, WebSite, Service, FAQ, Article, Breadcrumb
• Etiquetas Open Graph y Twitter card, o cada compartición en WhatsApp y LinkedIn aparecerá en blanco
• Un mapa del sitio limpio que excluya archivos de autor y otras páginas sin valor de búsqueda
• Enlaces internos, seguidos, organizados en clústeres temáticos

Ese último punto merece especial énfasis porque circula ampliamente el consejo contrario. No apliques rel="nofollow" a tus enlaces internos. El PageRank se divide entre los enlaces de una página, y la parte asignada a un enlace con nofollow se descarta en lugar de redistribuirse. Aplicar nofollow a tus propios enlaces no acumula autoridad; la destruye. Puedes aplicar nofollow a enlaces externos si lo deseas, pero los enlaces internos siempre deben ser seguidos.

Rendimiento, en términos que importan

Las Core Web Vitals son la medida de Google sobre la experiencia, pero la razón de negocio es más sencilla: los sitios lentos pierden consultas.

Tres cifras para exigir a tu desarrollador:

• Largest Contentful Paint inferior a 2,5 segundos en un teléfono de gama media con 4G — no en tu escritorio
• Interaction to Next Paint inferior a 200 milisegundos
• Cumulative Layout Shift inferior a 0,1 — nada debe moverse mientras se carga la página

La mayoría de los fallos provienen de cuatro causas: imágenes no optimizadas, fuentes que bloquean el renderizado, scripts de terceros (widgets de chat, gestores de etiquetas, rastreadores) y JavaScript incluido para funciones que la página no utiliza.

Acordad un presupuesto de rendimiento antes de que empiece el diseño. Retroajustar la velocidad a un diseño que asume cuatro vídeos de portada es mucho más caro que diseñar dentro de un presupuesto desde el principio.

El cambio de la era de la IA que merece la pena entender

Algo ha cambiado realmente, y afecta a una decisión arquitectónica.

Los rastreadores de IA —GPTBot, ClaudeBot, PerplexityBot, CCBot— suelen obtener HTML sin procesar y no ejecutan JavaScript. Google sí puede renderizar JavaScript, pero lo hace más lento y de forma menos fiable que sirviendo HTML plano.

La consecuencia: una aplicación de una sola página renderizada en el cliente es casi invisible para los sistemas que cada vez más responden a las preguntas de tus clientes. Si te importa ser citado por asistentes de IA, tu contenido debe estar presente en la respuesta HTML inicial —lo que significa renderizado en servidor o generación estática, no una aplicación React que lo cargue todo después.

La buena noticia es que esto no requiere una nueva disciplina. El HTML semántico renderizado en servidor, los datos estructurados precisos y la información empresarial consistente son las mismas cosas que siempre ha querido el buen SEO.

¿Reconstruir o reparar?

Reconstruir suele ser la respuesta equivocada, y las agencias tienen un incentivo obvio para no decirlo.

Repara cuando el contenido y la estructura sean broadly correctos y los problemas sean técnicos —carga lenta, metadatos ausentes, falta de schema, saturación de plugins—. Estos problemas se solucionan por una fracción del coste de una reconstrucción, normalmente en semanas, sin riesgo alguno de migración.

Reconstruye cuando la arquitectura de la información sea realmente incorrecta, la plataforma bloquee lo que necesitas o la base de código sea inmanejable. Incluso entonces, conserva todas las URLs indexadas que puedas.

Pregunta a cualquier agencia que recomiende una reconstrucción cuánto costaría reparar el sitio actual. La respuesta, y lo rápido que llegue, te dice mucho.

Migración sin perder posicionamiento

Si decides reconstruir, la migración es donde los sitios se resienten. Lo esencial:

1. Haz un inventario de todas las URLs indexadas desde Search Console y tu mapa del sitio, antes de nada.
2. Conserva en lugar de redirigir siempre que sea posible. Mantener una URL exactamente igual —incluyendo la barra final— conlleva cero riesgo. Una redirección 301 transmite la mayoría de la señal, pero "la mayoría" no es "toda".
3. Cuando una redirección sea inevitable, hazla de un solo salto. Las cadenas diluyen y desperdician el presupuesto de rastreo.
4. Transfiere títulos, descripciones y datos estructurados. Mejorarlos está bien; perderlos, no.
5. No lances el sitio más lento que el anterior. Compara antes y después.
6. Supervisa Search Console a diario durante el primer mes, para detectar errores de cobertura en días, no en trimestres.

Espera fluctuaciones menores durante una o dos semanas. Una migración bien ejecutada no produce un precipicio.

Qué exigir

• Precio fijo con un alcance por escrito
• Propiedad total del código, incluido el repositorio
• Un presupuesto de rendimiento acordado antes del diseño
• Todas las URLs indexadas contabilizadas, por escrito
• Datos estructurados en cada plantilla de página
• Formación para que tu equipo pueda publicar sin ti

Próximos pasos

Si estás decidiendo entre arreglar lo que tienes o empezar de nuevo, merece la pena hablarlo antes que enviar una propuesta. Estamos dispuestos a decirte que la opción más barata es la correcta, y lo hacemos con frecuencia.