Blog4 de noviembre de 2026

Cómo subir una página web a internet: guía paso a paso

Por el equipo creativo de Virtalio, una agencia creativa con más de 15 años construyendo sitios y piezas de marca para empresas de Latinoamérica. Última revisión: noviembre de 2026.

Subir una página web a internet significa mover los archivos terminados al servidor de un hosting y apuntar el dominio hacia ese servidor con un registro DNS. Son cinco pasos: elegir dónde vive el sitio, subir la carpeta correcta, crear el registro A o CNAME, esperar a que se emita el certificado y comprobar que la URL carga por HTTPS. Casi todos los problemas nacen en el mismo punto: se sube la carpeta del proyecto en lugar de los archivos compilados, o se edita el DNS en el registrador cuando los nameservers del dominio apuntan a otro proveedor. Abajo está el orden exacto, los datos que conviene tener a mano y las verificaciones que separan un sitio publicado de uno que existe pero nadie encuentra.

Un sitio publicado son cuatro capas

Antes de tocar cualquier panel, conviene separar lo que se está conectando. Un sitio en producción tiene cuatro piezas distintas y cada una falla de forma diferente. Si el vocabulario todavía no está claro, conviene empezar por qué es una página web y qué la compone.

Los archivos. HTML, CSS, JavaScript, imágenes y fuentes. Es lo único que se mueve en el paso 2.
El servidor. Una máquina con un servidor web (Apache, Nginx o una plataforma que lo administra por ti) que entrega esos archivos cuando alguien pide una ruta.
El DNS. La libreta pública que traduce tudominio.com a la dirección del servidor. Sin este paso el sitio existe, pero en una dirección IP que nadie recuerda.
El certificado. Lo que permite HTTPS y evita que el navegador marque el sitio como no seguro.

Cuando algo no carga, la pregunta útil no es "¿subí el sitio?" sino cuál de las cuatro capas está rota. Esa distinción ahorra horas: un DNS mal apuntado y una carpeta mal subida se ven igual desde el navegador y se arreglan en lugares opuestos.

Lo que hay que tener resuelto antes de empezar

Publicar toma minutos si los accesos están listos y toma días si hay que recuperarlos a mitad del proceso. Esta es la lista mínima.

Acceso al dominio. Usuario y contraseña del registrador donde se compró, no solo la factura. Sin eso no se puede cambiar ningún registro.
Acceso al hosting. IP del servidor o nombre del host, usuario, contraseña y puerto SFTP. En hostings administrados suele haber además un panel con administrador de archivos.
Los archivos finales. La carpeta que sale del build (dist, out o public, según la herramienta), no la carpeta con el código fuente ni la que contiene node_modules.
Un archivo index.html en la raíz. Es la puerta de entrada y casi siempre es también la portada. Si el sitio tiene varias secciones, el orden en que se enlazan conviene haberlo decidido antes: lo cubre esta guía de estructura de una página web. Si index.html queda dentro de una subcarpeta, el dominio mostrará un listado vacío o un error.
Claridad sobre el correo. Si el dominio se usa para correo, hay registros MX que no se deben borrar. Cambiar los nameservers sin recrearlos deja a la empresa sin recepción de mensajes.
Una copia del sitio anterior, si existe, y una ventana de baja para hacer el cambio.

Paso 1: decidir dónde va a vivir el sitio

La elección cambia el resto del procedimiento, así que se resuelve primero.

Hosting compartido o panel tipo cPanel. El sitio se sube a una carpeta pública, casi siempre public_html o www. Sirve para sitios estáticos y para instalaciones con base de datos administradas por el panel. La ruta exacta importa: si el dominio apunta a public_html, los archivos deben estar ahí y no en public_html/sitio.

Plataforma estática conectada a un repositorio. Se conecta la cuenta de Git, se declara el comando de build y la carpeta de salida. La plataforma compila y publica en cada push, y el manejo del certificado suele ser automático. Es el camino más limpio cuando el sitio se genera con un framework o con ayuda de IA, como en el flujo de crear una página web con IA.

Servidor propio (VPS). Hay que instalar el servidor web, declarar la raíz del sitio, configurar el certificado y mantener el sistema. Da control total y exige más cuidado: un root mal configurado apunta a la carpeta equivocada y el sitio aparece en blanco sin ningún error visible.

Un detalle que define la decisión: si el sitio procesa formularios, cobra o consulta una base de datos, necesita un entorno con ejecución en servidor. Una carpeta de archivos estáticos no hace eso sola; los formularios hay que conectarlos a un servicio o a un backend.

Paso 2: subir los archivos

Con el acceso listo, hay tres formas de mover los archivos: SFTP con un cliente como FileZilla o Cyberduck, el administrador de archivos del panel, o un despliegue desde Git. Las tres hacen lo mismo; cambia cuánto margen de error permiten.

Lo que se sube es el contenido de la carpeta de salida, no la carpeta. Si el build generó dist/index.html, dist/assets/ y dist/favicon.ico, al servidor llegan esos tres elementos colgando de la raíz pública. Subir dist completo produce la ruta tudominio.com/dist/ y deja la portada vacía.

Dos comprobaciones que evitan la mayoría de los errores de este paso:

Mayúsculas. Windows y macOS no distinguen Hero.jpg de hero.jpg; el servidor Linux sí. Un enlace escrito a mano con una mayúscula de más funciona en la computadora de quien lo hizo y devuelve 404 en producción.
Rutas relativas. Si el sitio se sirve en la raíz del dominio, las rutas deben empezar en /, no en ./sitio/. Un sitio que se ve perfecto en local y pierde estilos al publicarse casi siempre viene de aquí.

Los permisos habituales son 644 para archivos y 755 para carpetas. Si el hosting usa otro esquema, el panel lo indica; no conviene improvisar con 777 para "que funcione", porque abre escritura a cualquiera.

Paso 3: apuntar el dominio

Este es el paso donde se pierde más tiempo. La regla es simple: el dominio tiene un solo lugar donde se administra el DNS, y ahí se hacen los cambios. Puede ser el registrador, el hosting o un proveedor externo como Cloudflare, pero solo uno. Editar registros en el registrador mientras los nameservers apuntan a Cloudflare no cambia nada, y es la causa más común de un cambio "que no se aplicó".

Los registros que se usan para publicar son tres:

A apunta un nombre a una dirección IPv4. AAAA hace lo mismo con IPv6. Es lo que se usa en el dominio raíz, tudominio.com, cuando el hosting entrega una IP fija.
CNAME apunta un nombre a otro nombre, no a una IP. Es el registro natural para www: www.tudominio.com pasa a ser un alias de tudominio.com o del host que indica la plataforma.
Nameservers delegan todo el DNS a un proveedor. Se cambian en el registrador y sustituyen a los registros individuales.

El dominio raíz no admite un CNAME en el DNS clásico. Por eso los proveedores que lo necesitan usan un mecanismo propio: Cloudflare lo resuelve con CNAME flattening, que entrega la dirección final en el registro del apex. Si la plataforma pide un CNAME para el dominio raíz, hay que revisar si el proveedor de DNS lo soporta o si conviene mover los nameservers a uno que sí.

Sobre los tiempos: el TTL de cada registro decide cuánto puede tardar un cambio en propagarse, porque los resolutores guardan la respuesta anterior. Los valores habituales van de 300 segundos a 24 horas. Antes de una migración se baja el TTL a 300, se hace el cambio y se vuelve a subir cuando todo funciona. Esperar frente al panel no acelera nada; verificar con dig tudominio.com +short o con una herramienta de DNS público sí dice en qué estado está.

Paso 4: el certificado y HTTPS

Un sitio sin certificado muestra "No seguro" en la barra del navegador y pierde confianza antes de que el visitante lea la primera línea. La mayoría de los hostings emiten uno gratuito con Let's Encrypt en cuanto el dominio resuelve hacia el servidor.

El orden importa. La validación por HTTP comprueba el control del dominio pidiendo un archivo en http://tudominio.com/, y ese paso no puede hacerse por HTTPS porque el certificado todavía no existe. Si el DNS aún apunta a otro servidor, la validación falla y el certificado no se emite. La alternativa es la validación por DNS, que publica un registro TXT con el valor que entrega la autoridad.

Cuando el sitio está detrás de un proxy como el de Cloudflare, hay dos certificados en juego: el del borde y el del servidor de origen. El modo de SSL debe ser "Full" o "Full (strict)". El modo "Flexible" produce un bucle de redirección cuando la aplicación fuerza HTTPS, porque el proxy habla HTTP con el origen.

Al final conviene elegir una sola versión canónica del dominio —con www o sin ella— y redirigir la otra con un 301. Tener las dos activas sin redirección reparte enlaces y confunde a los buscadores.

Paso 5: comprobar que quedó bien

La página carga no es una verificación suficiente. Estas pruebas toman diez minutos y detectan casi todo; si el sitio es grande o viene de una migración, la revisión de inspeccionar una página web añade el resto de los puntos.

Estado y redirecciones. curl -I https://tudominio.com debe devolver 200. Si devuelve 301 o 302, hay que seguir la cadena y confirmar que termina en el destino correcto y por HTTPS.
Navegación real. Abrir el sitio en una ventana privada, en el teléfono y con datos móviles. La ventana privada evita la copia en caché; los datos móviles evitan la red de la oficina.
Rutas que no existen. Pedir una URL inventada debe devolver 404. Si devuelve la portada con estado 200, el servidor está reescribiendo todo y los buscadores pueden indexar direcciones vacías.
Formularios. Enviar una prueba real y confirmar que el correo llega a la bandeja correcta y no a spam. Un formulario que responde "gracias" y no entrega nada es el defecto más caro de este listado.
Recursos externos. Revisar la consola del navegador: imágenes o scripts por http:// dentro de una página HTTPS bloquean el candado y a veces ni se ven.
Buscadores. Añadir la propiedad en Search Console, verificar la propiedad por DNS o por archivo, enviar el sitemap y pedir la indexación de la portada. El sitemap debe estar declarado también en robots.txt.

Los cinco errores que dejan la página subida pero invisible

El index.html quedó en una subcarpeta. El dominio carga un listado o un 403. Se resuelve moviendo el contenido un nivel arriba.
El DNS se editó en el lugar equivocado. Los nameservers apuntan a otro proveedor y los registros nuevos no se leen. Se confirma con dig NS tudominio.com.
Se subieron los archivos fuente. El servidor entrega un package.json y una carpeta src, no un sitio. Hay que publicar la salida del build.
Hay una protección activa. Modo mantenimiento, contraseña de staging o una etiqueta noindex heredada del entorno de pruebas. El sitio responde 200 y no aparece en Google.
El certificado no se emitió. El DNS ya apunta al servidor pero la validación quedó a medias. Se vuelve a lanzar la emisión con el dominio ya resolviendo.

Qué revisar antes de anunciarla

Publicar es el principio de la vida útil del sitio, no el final del proyecto. Antes de mandar el enlace a clientes conviene cerrar cuatro frentes.

Enlaces viejos. Si el sitio anterior tenía URLs indexadas, cada una necesita un 301 a su equivalente nuevo. Google trata un 301 y un 308 como permanentes y usa el destino como canónico; un 302 le dice que el cambio es temporal y mantiene la URL antigua en los resultados.

Medición. Analítica instalada, un evento de conversión que corresponda a algo real (envío de formulario, clic a WhatsApp, compra) y una prueba propia que se vea en el panel. Sin eso, el primer mes de tráfico no se puede interpretar.

Apariencia al compartir. Título, descripción e imagen Open Graph. La mayoría de los enlaces a un sitio se abren primero en WhatsApp o LinkedIn, y ahí se ve la tarjeta, no la página.

Continuidad. Copia de seguridad, accesos documentados y quién puede renovar el dominio y el hosting. Un sitio que funciona y cuyo dominio vence en tres semanas es un problema aplazado.

Cuándo conviene que lo haga otro equipo

Un sitio de una página con archivos estáticos se publica en una tarde con esta guía. La cosa cambia cuando hay migración de dominio, decenas de URLs con historial, formularios conectados a un CRM, pagos, o varias marcas bajo el mismo dominio. Ahí el trabajo real no es subir archivos: es el mapa de redirecciones, la verificación de que nada del sitio anterior se rompió y la comprobación en dispositivos reales.

En nuestro servicio de landing pages y sitios web ese cierre forma parte de la entrega: estructura, textos, maquetado, publicación y las pruebas de las que habla esta guía. La primera entrega de la mayoría de las piezas sale en menos de 48 horas, las revisiones están incluidas y no se firma contrato de permanencia.

Preguntas frecuentes

¿Cuánto tarda en verse el cambio de DNS?

Depende del TTL del registro anterior. Con un TTL de 300 segundos el cambio suele verse en minutos; con uno de 24 horas puede tardar hasta un día en todos los resolutores. Durante ese lapso algunas personas ven el sitio nuevo y otras el anterior, y eso es normal.

¿Necesito hosting si ya compré el dominio?

Sí. El dominio es el nombre; el hosting es el espacio donde viven los archivos. Son dos servicios distintos y pueden estar en proveedores distintos. Lo que los conecta es el registro DNS.

¿Puedo publicar sin saber programar?

Puedes publicar un sitio ya exportado como archivos estáticos: se sube la carpeta y se apuntan los registros. Lo que no se resuelve sin conocimientos técnicos es una instalación que necesite build, base de datos o configuración de servidor.

¿Qué pasa con el correo cuando cambio los nameservers?

Si el DNS se muda a otro proveedor, los registros MX tienen que recrearse allí antes del cambio. Si no, el correo deja de entrar aunque el sitio siga funcionando. Es la razón por la que este paso se hace con la lista de registros a la vista y no de memoria.

Fuentes

Cloudflare. DNS record types.
Cloudflare. Manage DNS records.
Let's Encrypt. How It Works.
Google Search Central. Redirects and Google Search.
Google Search Central. Build and submit a sitemap.
Google Search Console Help. Add a website property to Search Console.