Cómo crear un sitio web paso a paso

Crear un sitio web corporativo implica doce decisiones: objetivo, audiencia, alcance, arquitectura, contenido, tecnología, dominio y hosting, diseño de interfaz, implementación, medición, pruebas y mantenimiento. Un creador o un CMS resuelve solo una parte técnica. No decidirá qué debe conseguir el sitio ni cómo debe utilizarlo el cliente.

Esta guía conduce de la idea a una publicación estable. Puedes usarla para crear por tu cuenta un sitio sencillo, preparar un brief para un proveedor o controlar un proyecto llevado por el equipo interno.

Paso 1. Define para qué se crea el sitio

Empieza por un problema de negocio, no por elegir una plantilla. Un sitio puede captar consultas, vender, ofrecer documentación, atender clientes, reclutar u ordenar la imagen de marca. Cada objetivo requiere contenido y funciones distintos.

Escribe una frase: «El sitio debe ayudar a [un grupo concreto] a realizar [una tarea], para que la empresa consiga [un resultado]». Añade después una métrica y un valor inicial. Por ejemplo: «Debe ayudar a responsables de producción a evaluar si la solución es compatible con su línea, para aumentar el número de consultas con datos técnicos completos».

No intentes perseguir todos los objetivos con la misma fuerza en la página de inicio. Elige un resultado principal y algunos recorridos complementarios. Así, la persona diseñadora sabe qué destacar, quien edita sabe qué explicar y quien analiza sabe qué medir.

Paso 2. Elige el tipo de solución adecuado

No toda idea necesita un sitio amplio. Decide primero qué trabajo debe realizar la solución:

Tipo	Cuándo basta	Qué suele ser más importante
Landing page	Una campaña, oferta o registro con un objetivo claro.	Una promesa, prueba, formulario y medición de origen.
Sitio corporativo	Varias ofertas, grupos de audiencia y presencia informativa estable.	Navegación, contenido de oferta, confianza y edición autónoma.
Sitio de contenidos	Publicación de conocimiento, documentación o un catálogo amplio de información.	Búsqueda, taxonomía, flujo editorial y rendimiento.
Tienda online	Catálogo, carrito, pago, entrega y gestión de pedidos.	Datos de producto, condiciones, integraciones y operación posterior a la compra.
Aplicación web	La persona inicia sesión y realiza procesos repetidos sobre datos.	Roles, estados, seguridad, lógica de negocio y soporte.

A veces la solución correcta será una combinación, por ejemplo un sitio de marketing conectado a una aplicación separada. No llames «página con varios formularios» a una aplicación: reducirías el alcance de análisis, pruebas y mantenimiento.

Si vendes, lee también qué es e-commerce y cómo elegir un modelo. Una tienda estándar en una plataforma preparada puede ser mejor que código a medida si el proceso de pedido no requiere reglas no estándar.

Paso 3. Conoce a la audiencia y sus tareas

Recoge preguntas de ventas, soporte, buscador, formularios y analítica existente. Busca situaciones y criterios de decisión, no solo datos demográficos. Quien compra por primera vez necesita otra explicación que un especialista que compara parámetros con una especificación interna.

Para cada grupo importante describe:

• el problema y el momento en que empieza a buscar una solución;
• conocimientos, lenguaje y malentendidos frecuentes;
• información necesaria para comparar variantes;
• preocupaciones sobre precio, riesgo, implementación o cambio de proveedor;
• dispositivo, contexto y posibles necesidades de accesibilidad;
• la acción que debe realizar en el sitio y fuera de él.

Si existe un sitio actual, observa a usuarios que realizan dos o tres tareas clave. Unas pocas conversaciones no dan un resultado representativo de todo el mercado, pero revelan pronto problemas de lenguaje, navegación y proceso. Combina ese conocimiento con datos cuantitativos en vez de elegir una sola fuente.

Paso 4. Construye el mapa del sitio y el alcance de la primera versión

El mapa del sitio muestra las relaciones entre contenidos. Debe surgir de las preguntas de la audiencia y la estructura de la oferta, no copiar los departamentos de la organización. Empieza por los recorridos: entrada desde una pregunta concreta, elección de categoría, evaluación del servicio, prueba, contacto o compra.

Asigna a cada dirección una intención principal. Una página de servicio debe ayudar a evaluar alcance y condiciones; un artículo, responder una pregunta; y un case study, mostrar problema, decisiones y resultado. Si dos direcciones previstas hacen lo mismo, únelas antes de escribir contenido.

Divide el alcance de la primera versión en:

• elementos imprescindibles sin los que no se alcanza el objetivo;
• mejoras importantes con una solución temporal;
• hipótesis que se comprobarán tras publicar;
• cosas excluidas conscientemente del proyecto.

Para cada función añade un escenario y un criterio de finalización. «Formulario de contacto» debería definir campos, validación, consentimiento, destinatario del mensaje, confirmación, registro en CRM, comportamiento ante error y método de prueba. Esta precisión reduce diferencias entre presupuestos.

Paso 5. Prepara el contenido antes de pulir los wireframes

El contenido no rellena un layout terminado. Explica la oferta, responde objeciones y define la jerarquía de la pantalla. Prepara al menos una versión de trabajo de las páginas clave antes de aprobar el diseño visual.

Para cada página anota:

1. la pregunta de la audiencia y una respuesta directa;
2. la promesa y las condiciones en que es verdadera;
3. pruebas: proceso, datos, ejemplo, opiniones o documentación;
4. alcance, limitaciones y excepciones relevantes;
5. el siguiente paso e información sobre qué ocurrirá después del clic.

Evita lemas generales como «soluciones innovadoras de máxima calidad». Se pueden atribuir a cualquier empresa. Lo concreto es, por ejemplo, describir la implementación, formatos admitidos, tiempo de respuesta establecido por contrato o una decisión de proyecto con su justificación.

Planifica una persona responsable de cada contenido, el modo de aprobación y la fecha de revisión posterior. Las cifras, precios, nombres, normativa y capturas de interfaz envejecen más rápido que las explicaciones básicas. Sin responsabilidad, el sitio nuevo empezará a quedar desactualizado tras el lanzamiento.

Paso 6. Planifica SEO y la estructura de respuestas

El SEO comienza en la arquitectura, no después de publicar. Investiga el lenguaje que usa la audiencia para describir el problema y asigna intenciones importantes a las direcciones correctas. No crees varias páginas casi idénticas para variantes de la misma frase.

Los fundamentos incluyen:

• URL descriptivas y estables;
• un tema claro y una jerarquía lógica de encabezados en cada página;
• título y descripción únicos que atraigan a la audiencia adecuada;
• enlaces internos que nazcan de la siguiente pregunta;
• respuestas en texto, incluso si el contenido también es vídeo o gráfico;
• datos estructurados solo cuando corresponden al contenido visible;
• mapa del sitio, reglas de indexación correctas y direcciones canónicas;
• redirecciones desde URL antiguas durante una renovación.

No existe una «densidad» de palabra clave exigida ni un número mínimo de palabras. Google recomienda contenido creado ante todo para personas, con valor original y una fuente de conocimiento clara. Un buen punto de control son los fundamentos de SEO de Google.

Las mismas reglas ayudan a la visibilidad en respuestas generadas por IA: conceptos inequívocos, respuesta directa, fuentes fiables y conexiones lógicas. No hace falta crear una versión artificial distinta «para GEO».

Paso 7. Elige el modo de construcción y la tecnología

La tecnología se selecciona según proceso, datos, equipo y mantenimiento. Los modelos más comunes implican distintos compromisos:

Modelo	Ventaja	Limitación que comprobar
Creador alojado	Inicio rápido, hosting y edición en una suscripción.	Exportación de datos, funciones propias, coste al escalar y dependencia del proveedor.
CMS con plantilla	Amplia elección de extensiones y publicación autónoma.	Actualizaciones, calidad de complementos, seguridad y complejidad creciente.
CMS con frontend individual	Interfaz flexible y flujo de contenidos independiente.	Más elementos que desplegar, integrar y mantener.
Plataforma e-commerce	Mecanismos preparados para catálogo, carrito y pedidos.	Precios no estándar, proceso B2B, integraciones, comisiones y límites del plan.
Solución a medida	Adaptación a un proceso y datos específicos.	Mayor coste de análisis, construcción, pruebas y responsabilidad a largo plazo.

No elijas una herramienta solo por una demostración drag and drop. Comprueba el trabajo con contenido real, permisos, historial de cambios, idiomas, integraciones, rendimiento, accesibilidad, copias de seguridad y posibilidad de migración. Un inicio gratuito puede conducir a una limitación cara, pero una plataforma a medida también puede ser un coste injustificado.

Antes de decidir, realiza una pequeña prueba técnica sobre el fragmento más difícil, no sobre la página «Sobre nosotros». Añade un producto real con variantes, un artículo largo con tabla, un proceso de aprobación o una conexión de prueba con el sistema de la empresa. Comprueba también la exportación: si recibes contenido completo, medios, relaciones e identificadores, o solo una hoja simplificada. Este prototipo no garantiza el éxito de toda la implementación, pero revela límites antes de comprar un plan anual o construir decenas de plantillas.

Evalúa el coste a varios años: suscripciones, comisiones, actualizaciones, trabajo editorial, soporte y migración futura. Una herramienta barata que exige sortear manualmente sus carencias puede costar más que un sistema mejor ajustado. Del mismo modo, código propio sin equipo de mantenimiento se convierte pronto en dependencia de una sola persona.

Al elegir proveedor, evalúa proceso, responsabilidad y entrega del proyecto, no solo portfolio. Ayuda la guía cómo elegir a un diseñador de sitios.

Paso 8. Protege dominio, DNS, hosting y correo

El dominio es la dirección, el hosting publica el sitio, DNS une el nombre con los servicios y el correo puede funcionar con otro proveedor. Estos elementos están relacionados, pero no son lo mismo. La empresa debe ser titular del dominio y propietaria de las cuentas, incluso si el proveedor gestiona la configuración.

Al elegir un dominio, prioriza facilidad de escritura, pronunciación y recuerdo. Una palabra clave en la dirección no sustituye a la marca ni a un buen contenido. Registra variantes defensivas solo si existe un riesgo real de confusión; mantener decenas de dominios sin objetivo complica la gestión.

Configura:

• renovación automática y un contacto adicional de titularidad;
• autenticación multifactor en registrador y hosting;
• certificado TLS y redirección a una única versión HTTPS;
• registros de correo y mecanismos de autenticación de mensajes;
• un entorno de prueba separado sin indexación pública;
• monitorización de disponibilidad y errores;
• copias de seguridad con pruebas periódicas de restauración.

No traslades registros DNS sin un inventario completo. Un cambio aparentemente pequeño puede dejar fuera de servicio el correo, una herramienta de envío o la verificación de un servicio externo.

Adapta el hosting a arquitectura, ubicación de la audiencia y riesgo. Importan estabilidad, tiempo de respuesta de soporte, escalado, logs, región de procesamiento, plan de contingencia y quién responde tras una alerta. El uptime declarado no garantiza que la aplicación y todas sus integraciones funcionen correctamente.

Paso 9. Diseña una interfaz útil y accesible

Diseña primero tareas y estados; solo después afina la estética. La persona usuaria debe saber dónde está, qué puede hacer y cuál será el efecto de actuar. Navegación, etiquetas, formularios y mensajes influyen más en la usabilidad que una animación de moda.

Diseña desde el principio para distintos anchos, modos de control y cantidades de contenido. La respuesta adaptativa no significa reducir un diseño de escritorio. A veces hay que cambiar el orden, simplificar una tabla, presentar la navegación de otra forma y ampliar zonas de interacción.

Cuida:

• foco visible y manejo completo por teclado;
• orden correcto de encabezados y etiquetas semánticas;
• contraste e información que no dependa solo del color;
• texto alternativo para imágenes que aportan significado;
• errores de formulario claros y posibilidad de corregirlos;
• ampliación de texto sin perder funciones;
• reducción de movimiento para quien la necesite.

El estándar actual del W3C es WCAG 2.2. La conformidad no surge de un único escáner automático: hacen falta pruebas de código, teclado, lector de pantalla y escenarios reales. Los requisitos legales dependen de la organización y servicio, por lo que el alcance debe establecerse por separado.

Paso 10. Implementa el sitio como un sistema, no como un conjunto de pantallas

En vez de programar cada subpágina por separado, crea componentes y reglas: encabezados, botones, formularios, tarjetas, espacios, colores y estados. Así los contenidos siguientes mantendrán coherencia y una mejora de accesibilidad o estilo abarcará todo el sitio.

En desarrollo, establece estándares de código, revisión de cambios, entornos, pruebas automáticas y modo de despliegue. Los secretos y claves no deben llegar al repositorio. Los accesos han de ser individuales y limitados al rol necesario.

Trata el rendimiento como parte de la experiencia. Optimiza imágenes y fuentes, limita scripts externos, carga el código necesario en cada página y controla el comportamiento del diseño durante la carga. Las métricas actuales de Core Web Vitals son LCP, INP y CLS, evaluadas sobre datos reales en el percentil 75; web.dev describe los umbrales y la medición oficial.

No instales un complemento para cada necesidad pequeña sin evaluar calidad y mantenimiento. Toda dependencia implica actualizaciones, posibles conflictos, riesgo de seguridad e impacto en velocidad.

Paso 11. Configura medición, privacidad y operaciones

La analítica debe responder a las preguntas del proyecto. Define eventos para pasos relevantes: elegir servicio, iniciar formulario, error, envío, descarga de documento o paso a un socio. Nómbralos en el plan de medición y pruébalos antes de publicar.

No recojas datos «por si acaso». Define propósito, propietario, periodo de conservación y personas con acceso. Evalúa con la persona responsable de cumplimiento la configuración de consentimientos, cookies, formularios, herramientas publicitarias y transferencias de datos. Un banner por sí solo no garantiza que los scripts se comporten según la elección de la persona usuaria.

Conecta el formulario a un proceso de atención real. Determina:

• a qué sistema y equipo llega la consulta;
• quién recibe el aviso y en qué plazo responde;
• qué ve la persona usuaria tras un envío correcto;
• cómo reconocer un duplicado, spam o fallo de integración;
• dónde se monitorizan errores y eventos perdidos.

Un sitio que envía un formulario bonito a una bandeja no usada no cumple el objetivo, aunque su interfaz sea correcta.

Paso 12. Prueba antes de publicar

Las pruebas deben surgir del riesgo y de los escenarios, no solo de una lista de navegadores. Recorre todo el proceso como usuario y como la persona que trata los datos al otro lado.

Contenido y navegación

• comprueba títulos, encabezados, precios, datos de contacto y mensajes;
• encuentra páginas huérfanas y enlaces que no llevan a ningún sitio;
• usa nombres largos, resultados vacíos y contenido en cada idioma;
• verifica archivos descargables y derechos de imágenes y fuentes.

Funciones e integraciones

• envía un formulario correcto y uno erróneo;
• prueba pago, entrega, mensajes y registro en el sistema;
• simula falta de respuesta de una integración y el reintento de operación;
• comprueba roles, inicio de sesión, restablecimiento de contraseña y cierre de sesión en otros dispositivos.

Dispositivos, accesibilidad y rendimiento

• usa teléfono, monitor grande, teclado y lector de pantalla;
• amplía el texto y activa la preferencia de reducir movimiento;
• comprueba contraste, foco, etiquetas de campos y mensajes de error;
• evalúa la carga con conexión lenta y dispositivo real.

SEO y medición

• verifica indexabilidad, dirección canónica, mapa del sitio y robots.txt;
• comprueba títulos, descripciones, datos estructurados y enlaces internos;
• confirma las redirecciones desde direcciones antiguas;
• prueba eventos analíticos y comportamiento dependiente del consentimiento.

Registra cada error con dirección, dispositivo, pasos para reproducir, resultado esperado y evidencia. «No funciona en el móvil» no basta a un desarrollador para diagnosticarlo.

Cómo publicar un sitio con seguridad

Prepara una lista de lanzamiento y una persona que pueda decidir «publicamos» o «volvemos atrás». Haz una copia del sitio y datos actuales, congela cambios de contenido durante la migración, baja el TTL de DNS con la antelación adecuada si hace falta y establece la ventana de menor riesgo.

Al renovar, prepara un mapa de cada dirección antigua hacia el contenido nuevo más cercano. La página de un servicio retirado puede llevar a su equivalente vigente, pero no redirijas todas las URL a la página de inicio. Conserva la dirección si tema e intención siguen siendo los mismos.

Después del despliegue:

1. comprueba el sitio desde una conexión externa y en varios dispositivos;
2. prueba formularios, compra, correo, inicio de sesión e integraciones;
3. confirma el certificado, direcciones canónicas y ausencia de bloqueo de indexación;
4. envía el mapa del sitio en Search Console y observa informes de indexación;
5. monitoriza errores de servidor y aplicación, rendimiento y caídas inusuales de tráfico;
6. mantén el equipo disponible durante el periodo de estabilización acordado.

Google suele encontrar páginas mediante enlaces y el mapa del sitio ayuda a transmitir información de direcciones; el mero envío no garantiza indexación inmediata. Los métodos oficiales para pedir a Google una nueva revisión están en la documentación de indexación.

No elimines el entorno anterior el día de lanzamiento. Consérvalo durante el tiempo acordado de forma inaccesible para buscadores y personas no autorizadas, para poder comparar datos o restaurar un elemento que falte.

Mantenimiento del sitio después de lanzarlo

Un sitio es un servicio, no un archivo de una sola vez. Necesita propietario, actualizaciones, monitorización, copias y edición regular. Ya en el contrato o plan interno, fija quién responde de:

• renovación de dominio, certificados, hosting y licencias;
• actualizaciones de sistema, bibliotecas, temas y complementos;
• vulnerabilidades, alertas, logs y respuesta a incidentes;
• prueba de copia de seguridad y procedimiento de restauración;
• cambios de oferta, precios, equipo, condiciones y datos de contacto;
• control de enlaces, formularios, integraciones y medición;
• evolución basada en resultados y preguntas de la audiencia.

Tras las primeras semanas, compara el resultado con el valor inicial, pero considera temporada, campañas y el tiempo que necesita el buscador. No interpretes cada fluctuación como efecto del rediseño. Combina datos cuantitativos con conversaciones y observación de tareas.

¿Cuánto cuesta y cuánto tarda crear un sitio?

No hay un precio ni plazo universal honesto sin conocer el alcance. El coste depende del número de tipos de página únicos, calidad del contenido preparado, integraciones, migración, idiomas, requisitos de accesibilidad, datos, pruebas y modelo de mantenimiento. Diez subpáginas basadas en una plantilla pueden ser más simples que una calculadora con reglas de negocio.

Divide el presupuesto entre descubrimiento del problema, contenido, diseño, desarrollo, infraestructura, pruebas, migración y mantenimiento. Añade el coste del trabajo de tu propio equipo. El cuello de botella a menudo no es el código, sino decisiones tardías, falta de imágenes, textos sin aprobar o una integración sin documentación.

Construye el calendario a partir de dependencias. Define cuándo deben estar listos datos, acceso al dominio, contenidos y decisiones legales. Una reserva no sirve para esconder un alcance desconocido: primero nombra el riesgo y luego estima su impacto.

¿Cuándo crear un sitio por cuenta propia y cuándo con un proveedor?

Un creador autónomo es razonable cuando el objetivo es sencillo, el contenido breve, no hay integraciones importantes y el riesgo de error es bajo. Permite validar rápido una oferta o lanzar una página de evento. Aun así hay que cuidar dominio, contenido, accesibilidad, medición y copia de datos.

La ayuda especializada está justificada cuando:

• varios grupos de audiencia necesitan recorridos distintos;
• el sitio atiende ventas, datos sensibles o un proceso crítico;
• hay que migrar mucho contenido y conservar visibilidad;
• existen integraciones no estándar o roles de usuario;
• la marca necesita un sistema visual individual;
• el equipo no tiene competencias para un mantenimiento seguro.

También es posible un modelo mixto: una persona especialista ordena estrategia, arquitectura y sistema, y el equipo desarrolla por sí mismo contenidos sobre componentes preparados. Es importante que el contrato indique propiedad de archivos, código, datos, cuentas y licencias, e incluya entrega de documentación.

¿Cómo aceptar un sitio de un proveedor?

La aceptación no debe consistir en mirar la página de inicio y pagar la última factura. Compara el resultado con el alcance y escenarios aceptados. Si una función debe enviar datos al CRM, comprueba un registro correcto, un duplicado, la falta de conexión y la información visible para el usuario, no solo el aspecto del formulario.

Pide la entrega de un paquete ordenado:

• lista de dominios, entornos, servicios externos y titulares de cuentas;
• repositorio de código con instrucciones de ejecución y despliegue;
• diseño fuente, biblioteca de componentes y fuentes usadas;
• exportación de contenido, datos y configuración necesaria para restaurar;
• documentación de integraciones, eventos analíticos y procedimientos de emergencia;
• mapa de redirecciones e informe de pruebas tras la migración;
• información de licencias, suscripciones, fechas de renovación y limitaciones;
• lista de problemas conocidos, deuda técnica e ideas aplazadas conscientemente;
• contacto y reglas de soporte durante el periodo de estabilización.

Transfiere accesos mediante un gestor de contraseñas o invitaciones a cuentas individuales. Al finalizar la colaboración, retira permisos innecesarios, cambia secretos compartidos y conserva al menos dos administradores por parte de la empresa. Un archivo con código no aporta independencia si solo el proveedor controla hosting, dominio o claves de integración.

Haz la formación con tareas reales: añadir una página, cambiar una imagen, corregir SEO, retirar una publicación y restaurar una versión. Graba el proceso o prepara instrucciones breves para operaciones poco frecuentes. Asegúrate de que quien edita no necesite privilegios de administrador para el trabajo diario.

Planifica la evolución sin reconstruir constantemente

Después del lanzamiento aparecerá una lista de deseos. No la realices por orden de solicitud ni por la voz más alta de un interesado. Describe cada idea como problema, grupo, efecto esperado, coste y riesgo. Compárala después con el objetivo del sitio y los datos.

Los experimentos pequeños son más seguros que rediseños frecuentes. Si los usuarios no encuentran la lista de precios, comprueba primero etiqueta, posición del enlace e información ausente en la página de servicio. Cambiar toda la navegación puede introducir nuevos problemas y dificultar la comparación del resultado.

Conserva el historial de decisiones: qué cambió, por qué, cuándo y cuál fue el resultado. Establece un ritmo de revisión de contenido, rendimiento, accesibilidad, seguridad y objetivos de negocio. Así el sitio evoluciona como producto, no como una serie de encargos de reparación independientes.

En las versiones de idioma evita la copia mecánica. La localización incluye moneda, datos de contacto, unidades, ejemplos, requisitos del mercado y palabras que usa la audiencia. Define qué versión es fuente, quién aprueba la traducción y cómo un cambio de oferta llega a los demás idiomas.

Errores más frecuentes al crear un sitio

El primero es empezar por la apariencia sin un objetivo acordado. Otros son elegir herramienta antes de requisitos, mantener texto de relleno hasta el final, no tener dueño de las decisiones y aplazar SEO, accesibilidad y analítica para «después del lanzamiento».

También son arriesgados:

• una cuenta de dominio que pertenece a un empleado o proveedor;
• una única pareja de usuario y contraseña compartida por todo el equipo;
• falta de posibilidad de exportar contenido y datos;
• añadir plugins sin un plan de actualizaciones;
• redirigir automáticamente todas las direcciones antiguas a la página de inicio;
• aceptar el sitio sin probar un formulario, pago o integración reales;
• borrar la versión anterior sin copia ni plan de reversión;
• considerar el estreno como el final de la responsabilidad.

Si todavía estás ordenando requisitos, empieza por la guía cómo planificar un proyecto web. Si el sitio existente contiene contenido y datos valiosos, no supongas automáticamente que hay que construir desde cero: comprueba cuándo es mejor una modernización del sitio.