Subir una web con FileZilla consiste en copiar el contenido de tu carpeta local dentro de la carpeta pública de tu alojamiento: public_html en cPanel, httpdocs en Plesk. Los dos fallos que arruinan el estreno son arrastrar la carpeta contenedora en vez de lo que hay dentro, y dejar los archivos donde nada se publica.
Esta guía va por ese orden: los datos que necesitas, cuál es la carpeta buena, qué subir y qué dejar en tu ordenador, y qué mirar cuando abres tu dominio y sale en blanco. Si aún no tienes el programa instalado, empieza por descargar FileZilla.
Los datos FTP: dónde te los da tu hosting
Son cinco y los da tu proveedor: dirección del servidor, usuario, contraseña, protocolo (FTP, FTPS o SFTP) y puerto. El atajo que casi todo el mundo olvida es el correo de alta del servicio: suele traerlos juntos. Si no lo conservas, están en la sección de cuentas FTP del panel, donde además se cambia la contraseña: no se consulta, se cambia.
Un aviso que ahorra media tarde: el usuario de FTP no es el del panel ni el de WordPress, aunque los crearas el mismo día. Y si tu proveedor te habla de «acceso SFTP» en lugar de FTP, no te has equivocado de sitio: es el mismo trámite con otro protocolo.
Meter esos datos en el programa, elegir el protocolo y resolver los errores de conexión es un tema en sí mismo, y lo tienes desarrollado en cómo configurar FileZilla. A partir de aquí damos por hecho que ya ves los archivos del servidor en el panel derecho.
¿En qué carpeta se sube la web? public_html, httpdocs o www
La carpeta pública es la que tu panel llama Document Root o «raíz del documento», y su nombre depende del panel, no de FileZilla. Estos son los cuatro que te vas a encontrar:
| Panel | Carpeta pública | Detalle |
|---|---|---|
| cPanel | public_html |
La documentación de cPanel la llama Web Root y admite que algunos la muestran como www: son la misma carpeta. La ruta completa es /home/tuusuario/public_html. |
| Plesk | httpdocs |
Es el Document Root por defecto de todos los dominios alojados, según su propio manual. |
| DirectAdmin | public_html, pero por dominio |
Cada dominio tiene la suya: /home/tuusuario/domains/tudominio.com/public_html. |
| Windows con IIS | wwwroot |
Poco común en alojamiento compartido español, pero existe. |
Si has leído por ahí que la carpeta se llama «httpd», bórralo: httpd es el nombre del programa servidor de Apache, no el de tu carpeta. Es un despiste que se copia de web en web y que hace perder un buen rato buscando algo que no está.
Y la regla que no falla, por encima de cualquier tabla: tu panel te lo dice. La lista de dominios de cPanel tiene una columna Document Root con la ruta exacta de cada uno, y Plesk lo enseña en los ajustes de alojamiento del dominio. Mirarlo cuesta diez segundos y te ahorra adivinar, que es especialmente importante si tienes varios dominios en la misma cuenta: el segundo casi nunca va en la misma carpeta que el primero.
Otra cosa que despista al conectar: lo primero que ves no suele ser la carpeta pública, sino tu carpeta personal, con mail, logs o cgi-bin al lado. Ese es el vestíbulo. Si sueltas ahí tu index.html no pasa nada malo: simplemente no se publica.
Qué se sube y qué se queda en tu ordenador
Lo que sube es el contenido de tu carpeta de proyecto, no la carpeta. Si tu web está en C:\proyectos\miweb\ y arrastras miweb entera, acabas con tudominio.com/miweb/ y la portada devolviendo un error: el index.html tiene que quedar suelto dentro de la carpeta pública, con las subcarpetas de estilos e imágenes a su lado. Es el fallo número uno y se arregla en treinta segundos, pero solo si sabes que es eso lo que pasa.
Tampoco viaja todo. Estas son las cosas que la gente sube sin pensar y no deberían estar en un servidor público:
- La carpeta de dependencias (
node_modulesy compañía): miles de archivos diminutos que tardan una eternidad en subir y que el navegador no usa. - Los archivos de trabajo:
.scss,.psd, ficheros de diseño, elpackage.json, la carpeta.gitcon todo tu historial. - Cualquier archivo con credenciales, empezando por un
.env. Si está dentro de la carpeta pública, es descargable. - La copia de seguridad en
.zipde la propia web. Es la manera más discreta de regalarle tu proyecto entero (y a veces tus contraseñas) a quien acierte el nombre del archivo. - La basura del sistema operativo:
.DS_Storeen Mac,Thumbs.dben Windows. Inofensivos, pero ensucian.
Si trabajas con un framework o un generador de sitios, lo que se sube es lo que produce la compilación, la carpeta dist o build, no el proyecto. Ese es justo el matiz que hace que una web «subida entera» no funcione: has subido el taller en vez del mueble.
Subir una web estática paso a paso
Con los dos paneles a la vista —«Sitio local:» a la izquierda, «Sitio remoto:» a la derecha—, el procedimiento es corto:
1. Colócate en las dos carpetas correctas. A la izquierda, dentro de tu proyecto, viendo el index.html. A la derecha, dentro de la carpeta pública que has identificado arriba. Este paso es el que decide si todo lo demás sale bien.
2. Sube primero las carpetas de recursos (estilos, scripts, imágenes) y deja el index.html para el final. Si la web ya está en producción, así nadie se encuentra la portada nueva pidiendo unos estilos que todavía no han llegado. En una web que estrenas da igual el orden, pero es una costumbre que sale gratis.
3. Arrastra del panel izquierdo al derecho. También funciona el clic derecho sobre lo seleccionado y «Subir», y el doble clic sobre un archivo suelto. Con carpetas, el doble clic no sube nada: solo entra en ellas. Lo que sueltes aparece en la cola de la parte inferior y se va vaciando conforme termina.
4. Vigila el registro de mensajes, el panel de texto de arriba. Ahí es donde el servidor dice que ha rechazado algo. Una subida a medias no avisa con un cartel: se nota semanas después, cuando falta una imagen.
Un detalle que no depende de FileZilla sino del protocolo: evita acentos, eñes y espacios en los nombres de archivo. El FTP se diseñó en 1985 para caracteres ingleses de 7 bits, y aunque la extensión moderna del estándar usa UTF-8, basta con que el servidor de tu hosting no la respete para que logotipo-café.png llegue con el nombre roto y la imagen deje de cargar. Guiones y minúsculas, y no vuelves a pensar en ello.
Cuando termine, abre tu dominio en una ventana privada. La normal te va a enseñar lo que tenía guardado.
Subir un WordPress: por qué el FTP no basta
Aquí es donde mucha gente se estrella, y no por torpeza: un WordPress no son solo archivos. Los textos de tus entradas, los usuarios, los ajustes y los menús viven en una base de datos MySQL, y el FTP no la toca. Si copias por FileZilla las carpetas wp-admin, wp-includes y wp-content a un servidor nuevo, has movido la mitad de la web.
La otra mitad va aparte: se exporta la base de datos desde phpMyAdmin en el hosting viejo, se importa en el nuevo, y se edita wp-config.php para que apunte a la base de datos nueva: nombre, usuario, contraseña y servidor. La documentación de WordPress añade un detalle de orden que evita un buen lío: las URLs del sitio se cambian antes de mover los archivos, no después, porque después ya no puedes entrar al escritorio para cambiarlas.
Y si lo que quieres es instalar un WordPress nuevo, mi consejo es que no lo hagas por FTP. Casi todos los paneles llevan un instalador que te lo deja montado con su base de datos en un par de clics. El FTP, para WordPress, brilla en otras tareas: subir un tema o un plugin cuyo .zip supera el límite del panel, o entrar a renombrar la carpeta de un plugin que ha dejado el sitio inaccesible. Renombrarla lo desactiva y te devuelve el acceso al escritorio.
Una trampa más de WordPress: el .htaccess, que es el archivo con el que gestiona los enlaces permanentes, empieza por punto y por eso FileZilla no lo muestra de entrada. Se activa en el menú Servidor, en la opción «Forzar ver archivos ocultos». Si has migrado un sitio y todas las páginas dan 404 menos la portada, ese archivo invisible es el primer sospechoso.
Permisos: 755 en carpetas, 644 en archivos
Los permisos deciden quién puede leer, escribir y ejecutar cada archivo en el servidor. WordPress recomienda 755 para las carpetas y 644 para los archivos, y para una web estática esos mismos números funcionan sin más discusión: el propietario escribe, el servidor lee, nadie más toca nada.
La excepción es wp-config.php, que guarda las credenciales de tu base de datos: la documentación oficial pide dejarlo en 400 o 440, para que solo lo lean tú y el servidor web.
Lo que circula por los foros como remedio universal es el 777, y casi nunca es la solución. Un 777 deja el archivo escribible por cualquier proceso de la máquina, incluido el de un vecino comprometido en un alojamiento compartido. Si algo no funciona con 755 y 644, el problema suele ser el propietario del archivo, no el permiso, y eso se resuelve preguntando al soporte.
Para cambiarlos no hace falta salir de FileZilla: con el botón derecho sobre el archivo o la carpeta en el panel del servidor tienes la opción de permisos, con casillas por grupo y un valor numérico. El gestor de archivos de tu panel hace exactamente lo mismo, por si prefieres verlo desde ahí.
La web sale en blanco o sin estilos: qué mirar
Casi todo lo que pasa después de una primera subida entra en esta lista, ordenada de lo más frecuente a lo menos:
Ves la página de bienvenida del hosting, o un listado de archivos. Estás en la carpeta equivocada o falta la portada. Apache busca por defecto un archivo llamado exactamente index.html: ni Index.html, ni index.htm. Si el listado que ves es el de tus propios archivos, la web está bien subida y solo le falta el nombre correcto del índice.
La web carga pero sin estilos ni imágenes. Mira el código fuente de la página en el navegador y busca las rutas. Si alguna empieza por C:\ o por file:///, tu editor las escribió apuntando a tu disco duro: en tu ordenador se veía perfecta y en el servidor no existe ese camino.
Falta un archivo suelto y juras que lo subiste. Comprueba las mayúsculas. El servidor distingue entre Estilo.CSS y estilo.css; Windows no. Apache tiene incluso un módulo cuya única función es «corregir URLs erróneas ignorando las mayúsculas», lo que dice bastante de la frecuencia del problema.
Una imagen concreta no aparece y su nombre lleva tilde o eñe. Es el asunto del párrafo de más arriba: renómbrala sin acentos, corrige la ruta en el HTML y vuelve a subir las dos cosas.
Pantalla completamente en blanco en un WordPress. Si el mensaje es «error al establecer una conexión con la base de datos», el wp-config.php tiene datos que no corresponden a este servidor. Si en cambio te redirige al dominio antiguo, lo que falta es cambiar las URLs del sitio en la base de datos.
Todo está bien subido y sigues viendo la web vieja. Antes de tocar nada más, prueba en una ventana privada y desde el móvil con datos móviles. Si ahí ya se ve la nueva, es caché, del navegador o del propio hosting, y se pasa. Si desde ninguna parte se ve, comprueba que el dominio apunte de verdad a este servidor: se puede subir una web impecable a un alojamiento al que nadie está mirando.