Cómo eliminar “wordpress” de la URL de tu sitio (Guía técnica completa)

Cuando WordPress se instala en un subdirectorio llamado /wordpress, cada URL pública lleva ese segmento de ruta — yourdomain.com/wordpress/about, yourdomain.com/wordpress/shop — lo que perjudica la credibilidad de la marca y diluye el valor SEO. La solución es una migración de archivos controlada combinada con actualizaciones de URL en la base de datos: mueves todos los archivos principales de WordPress desde el subdirectorio a la raíz de documentos del servidor (public_html), actualizas la configuración de WordPress Address y Site Address, regeneras las reglas de reescritura y emites redirecciones 301 para cualquier URL heredada indexada. No se requiere reinstalación.

Esta guía cubre cada capa técnica de ese proceso — operaciones del sistema de archivos, reemplazo de cadenas en la base de datos, lógica de reescritura de .htaccess, estrategia de redirección y validación posterior a la migración — incluyendo casos extremos que causan fallos silenciosos en la mayoría de los tutoriales.

Por qué WordPress termina en un subdirectorio

Comprender la causa raíz evita que el mismo problema se repita. Los escenarios más comunes son:

• Valores predeterminados del instalador: Muchos instaladores de un clic (Softaculous, Installatron) utilizan por defecto una ruta de subdirectorio si el usuario no establece explícitamente la ruta de instalación en /.
• Promoción de entorno de pruebas a producción: Un desarrollador instala WordPress en /wordpress para pruebas y el sitio se pone en producción sin corregir la ruta.
• Planificación de múltiples sitios que nunca se materializó: Alguien anticipó ejecutar múltiples CMS bajo un dominio y asignó WordPress a su propia carpeta.
• Peculiaridades del instalador automático de cPanel: En entornos de VPS con cPanel, el instalador a veces añade el nombre de la aplicación como subdirectorio a menos que se anule.

Independientemente del origen, el procedimiento de migración es idéntico.

Lista de verificación previa a la migración

Antes de tocar un solo archivo, completa cada elemento de esta lista. Omitir cualquiera de ellos es la principal causa de tiempo de inactividad durante esta operación.

• Copia de seguridad completa del sitio: Archiva tanto el sistema de archivos como la base de datos MySQL. Plugins como UpdraftPlus o Duplicator funcionan bien; también lo hace una instantánea a nivel de servidor si tu proveedor de VPS Hosting lo admite.
• Credenciales de la base de datos a mano: Las necesitarás si se requiere una edición manual de wp-config.php.
• Modo de mantenimiento activo: Usa un plugin o añade define('WP_MAINTENANCE_MODE', true); temporalmente para evitar escrituras durante la ventana de migración.
• Registro de errores PHP habilitado: Establece WP_DEBUG_LOG en true en wp-config.php para que cualquier error posterior a la migración se escriba en /wp-content/debug.log en lugar de aparecer en pantalla.
• TTL de DNS anotado: Si también hay un cambio de DNS involucrado, reduce el TTL a 300 segundos al menos una hora antes de comenzar.

Paso 1: Mover los archivos de WordPress a la raíz de documentos

El objetivo es copiar todo lo que hay dentro de /public_html/wordpress/ directamente en /public_html/ — no la carpeta en sí, sino su contenido.

Usando un cliente FTP (FileZilla)

1. Conéctate a tu servidor mediante SFTP (puerto 22) en lugar de FTP simple para evitar la interceptación de credenciales.
2. Navega a public_html/wordpress/.
3. Selecciona todos los archivos y carpetas incluyendo los archivos ocultos. En FileZilla, habilita Ver > Mostrar archivos ocultos para exponer .htaccess y cualquier archivo .env.
4. Arrastra la selección un nivel de directorio hacia arriba, dentro de public_html/.
5. Cuando se te solicite sobrescribir index.php (si existe un marcador de posición en la raíz), confirma la sobreescritura.

Usando la línea de comandos (recomendado para VPS)

Si tienes acceso SSH — que deberías tener en cualquier entorno de VPS Hosting o Servidor Dedicado correctamente configurado — el enfoque de línea de comandos es más rápido y evita problemas de tiempo de espera de FTP en instalaciones grandes:

# Navigate to the document root
cd /var/www/html/public_html

# Copy all contents (including hidden files) from the subdirectory to the root
cp -a wordpress/. .

# Verify the copy succeeded before deleting anything
ls -la | head -30

No elimines el directorio /wordpress todavía. Déjalo intacto hasta que la migración esté completamente validada. Puedes eliminarlo en el paso final de limpieza.

Caso extremo crítico: Symlinks y rutas absolutas en plugins

Algunos plugins (particularmente los de copia de seguridad y seguridad) almacenan rutas de archivo absolutas en la base de datos — por ejemplo, /var/www/html/public_html/wordpress/wp-content/uploads/2024/01/image.jpg. Estas fallarán silenciosamente después del traslado. La búsqueda y reemplazo en la base de datos del Paso 5 se encarga de esto, pero debes incluir la tabla wp_options y cualquier tabla personalizada de plugins en el alcance del reemplazo.

Paso 2: Actualizar WordPress Address y Site Address

WordPress almacena dos valores de URL críticos en la tabla wp_options: siteurl (el WordPress Address, que apunta a donde viven los archivos principales de WordPress) y home (el Site Address, la URL que los visitantes usan para acceder al sitio). Ambos deben actualizarse.

Método A: Panel de control de WordPress

1. Inicia sesión en yourdomain.com/wordpress/wp-admin — esto sigue funcionando porque los archivos todavía están en ambas ubicaciones en este punto.
2. Ve a Ajustes > Generales.
3. Actualiza ambos campos:

• WordPress Address (URL): https://yourdomain.com
• Site Address (URL): https://yourdomain.com

1. Haz clic en Guardar cambios.

Método B: Edición directa de la base de datos (cuando el panel de control no es accesible)

Si el panel de control ya no es accesible, usa WP-CLI o phpMyAdmin:

# Using WP-CLI from the document root
wp option update siteurl 'https://yourdomain.com'
wp option update home 'https://yourdomain.com'

O en phpMyAdmin, ejecuta:

UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'home';

Reemplaza wp_ con tu prefijo de tabla real si fue cambiado durante la instalación.

Método C: Anulación temporal en wp-config.php

Si tanto el panel de control como la base de datos son temporalmente inaccesibles, añade estas dos líneas a wp-config.php como anulación de arranque:

define('WP_HOME', 'https://yourdomain.com');
define('WP_SITEURL', 'https://yourdomain.com');

Esto anula lo que esté almacenado en la base de datos. Elimina estas líneas después de confirmar que el panel de control es accesible y que los valores de la base de datos se han actualizado permanentemente.

Paso 3: Verificar y actualizar el archivo .htaccess

El archivo .htaccess en la raíz de documentos controla la reescritura de URL de Apache para WordPress. Después de mover los archivos, este archivo ya debería estar en public_html/ — pero su directiva RewriteBase debe reflejar la nueva instalación a nivel raíz.

Abre public_html/.htaccess y asegúrate de que contenga exactamente el siguiente bloque de reescritura de WordPress:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

El cambio clave respecto a una instalación en subdirectorio es RewriteBase / en lugar de RewriteBase /wordpress/. Si esta línea es incorrecta, todos los enlaces permanentes devuelven errores 404 mientras la página de inicio carga correctamente — una firma diagnóstica clásica de un RewriteBase mal configurado.

Usuarios de Nginx: WordPress no usa .htaccess. Actualiza la directiva try_files del bloque de servidor en su lugar:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Paso 4: Vaciar la estructura de enlaces permanentes

WordPress almacena en caché las reglas de reescritura en la base de datos. Después de cambiar la URL del sitio, esas reglas en caché hacen referencia a la estructura de ruta antigua y deben regenerarse.

1. Ve a Ajustes > Enlaces permanentes en el panel de control de WordPress.
2. Sin modificar la estructura de enlaces permanentes seleccionada, haz clic en Guardar cambios.

Esto obliga a WordPress a reconstruir y almacenar en caché las reglas de reescritura contra la nueva ruta a nivel raíz. Alternativamente, usa WP-CLI:

wp rewrite flush --hard

El indicador --hard regenera el archivo .htaccess además de vaciar la caché de la base de datos — útil si no estás seguro de si el .htaccess es correcto.

Paso 5: Reemplazo de URL en toda la base de datos

Mover archivos y actualizar siteurl/home no es suficiente. WordPress almacena cadenas de URL serializadas en toda la base de datos — en el contenido de entradas, postmeta, configuración de widgets, opciones de temas y tablas de configuración de plugins. Cualquier referencia de ruta /wordpress restante producirá imágenes rotas, etiquetas canónicas incorrectas y funciones de plugins que no funcionan correctamente.

Usando el plugin Better Search Replace

1. Instala y activa el plugin Better Search Replace.
2. Ve a Herramientas > Better Search Replace.
3. Configura el reemplazo:

• Buscar: https://yourdomain.com/wordpress
• Reemplazar con: https://yourdomain.com

1. Selecciona todas las tablas de la base de datos.
2. Desmarca ¿Ejecutar como prueba? solo después de confirmar que la prueba muestra el número esperado de reemplazos.
3. Haz clic en Ejecutar búsqueda/reemplazo.

También ejecuta una segunda pasada para la ruta absoluta del servidor:

• Buscar: /public_html/wordpress
• Reemplazar con: /public_html

Usando WP-CLI (preferido para producción)

El comando search-replace de WP-CLI maneja correctamente los datos serializados, lo que la función SQL REPLACE() simple no hace:

wp search-replace 'https://yourdomain.com/wordpress' 'https://yourdomain.com' --all-tables --precise --report-changed-only

Ejecuta una segunda pasada para las rutas absolutas del sistema de archivos:

wp search-replace '/public_html/wordpress' '/public_html' --all-tables --precise --report-changed-only

El indicador --precise usa el reemplazo con reconocimiento de serialización de PHP en lugar de regex, lo que evita corromper los arrays serializados almacenados en la base de datos.

Paso 6: Implementar redirecciones 301 para la continuidad SEO

Si el sitio ha sido públicamente accesible en URLs /wordpress — y especialmente si esas URLs han sido indexadas por Google o enlazadas desde fuentes externas — las redirecciones permanentes son obligatorias, no opcionales. Sin ellas, cada URL indexada se convierte en un 404 y se pierde todo el valor de enlace acumulado.

Añade la siguiente regla de redirección a public_html/.htaccess, por encima del bloque de reescritura de WordPress:

# Redirect legacy /wordpress/ URLs to root
RewriteEngine On
RewriteRule ^wordpress/(.*)$ /$1 [R=301,L]

Esta regla captura cualquier solicitud que comience con wordpress/ y la redirige a la ruta equivalente a nivel raíz. Por ejemplo:

• yourdomain.com/wordpress/about/ → yourdomain.com/about/
• yourdomain.com/wordpress/wp-admin/ → yourdomain.com/wp-admin/

Nota importante sobre la ubicación: Este bloque de redirección debe aparecer antes del comentario # BEGIN WordPress. Las propias reglas de reescritura de WordPress interceptarán la solicitud primero si la redirección se coloca después de ellas.

Para Nginx, añade esto al bloque del servidor:

rewrite ^/wordpress/(.*)$ /$1 permanent;

Paso 7: Validación posterior a la migración

Las pruebas sistemáticas evitan que los fallos silenciosos pasen desapercibidos en producción.

Comprobaciones funcionales

Validación por línea de comandos

# Verify the homepage returns 200
curl -I https://yourdomain.com

# Verify the legacy URL issues a 301
curl -I https://yourdomain.com/wordpress/

# Check that wp-admin is reachable
curl -I https://yourdomain.com/wp-admin/

Google Search Console

Envía el mapa del sitio actualizado en Google Search Console inmediatamente después de la validación. Usa la herramienta de Inspección de URL para solicitar la reindexación de la página de inicio. Supervisa el informe de Cobertura durante las siguientes 48–72 horas para detectar cualquier aumento en errores 404, lo que indicaría reemplazos de URL omitidos.

Paso 8: Limpieza y refuerzo final

Una vez que el sitio haya funcionado establemente en la URL raíz durante 24–48 horas:

1. Elimina el subdirectorio /wordpress del servidor. Dejarlo en su lugar crea un riesgo de contenido duplicado y expone un punto de entrada secundario a la instalación de WordPress.

rm -rf /var/www/html/public_html/wordpress

1. Elimina la constante WP_MAINTENANCE_MODE de wp-config.php si la añadiste.
2. Elimina las definiciones temporales de WP_HOME/WP_SITEURL de wp-config.php si usaste el Método C en el Paso 2.
3. Verifica la cobertura SSL: Si tu Certificado SSL fue emitido para yourdomain.com/wordpress como alcance basado en ruta (poco común pero posible en algunas configuraciones), confirma que el certificado cubre correctamente el dominio apex.
4. Actualiza cualquier configuración externa de DNS o CDN que pueda haber almacenado en caché la estructura de ruta antigua.
5. Purga todas las capas de caché: Limpia la caché de página del lado del servidor, la caché de objetos (Redis/Memcached) y la caché de CDN. Las entradas de caché obsoletas para URLs /wordpress servirán contenido incorrecto incluso después de que la migración esté completa.

Comparación: métodos de migración de un vistazo

Para cualquier entorno con acceso SSH — incluyendo Servidores Dedicados e instancias VPS no administradas — el enfoque WP-CLI es la opción más confiable y menos propensa a errores.

Matriz de decisión técnica

Usa esta matriz para determinar qué pasos son obligatorios frente a situacionales para tu escenario específico:

Conclusiones clave

• La operación principal es: copiar archivos a la raíz de documentos, actualizar siteurl y home en la base de datos, corregir .htaccess RewriteBase, ejecutar búsqueda y reemplazo con reconocimiento de serialización, añadir redirecciones 301.
• Nunca uses un SQL REPLACE() simple en tablas de WordPress sin manejo de serialización — corromperá los valores de opciones y romperá plugins silenciosamente.
• La directiva .htaccess RewriteBase / es el elemento más comúnmente mal configurado en esta migración; un valor incorrecto produce errores 404 en todas las URLs basadas en enlaces permanentes mientras la página de inicio continúa cargando.
• Las redirecciones 301 no son cosméticas — transfieren el valor de enlace y evitan la fragmentación del índice. Son obligatorias para cualquier sitio con visibilidad de búsqueda existente.
• Elimina el directorio /wordpress original solo después de una ventana de observación estable de 24 horas.
• Si estás ejecutando WordPress en un VPS con cPanel, usa la opción Mostrar archivos ocultos del Administrador de archivos para asegurarte de que .htaccess esté incluido en la operación de copia.

Preguntas frecuentes

¿Eliminar /wordpress de la URL afectará mis posiciones en SEO?

A corto plazo, espera fluctuaciones menores en las posiciones mientras Googlebot vuelve a rastrear las nuevas URLs. Si las redirecciones 301 están correctamente implementadas, el valor de enlace se transfiere completamente y las posiciones típicamente se estabilizan en dos a cuatro semanas. Omitir las redirecciones 301 causa una pérdida permanente de posiciones para todas las páginas previamente indexadas.

¿Qué pasa si mi panel de control de WordPress no es accesible después de mover los archivos?

La causa más común es una discrepancia entre el valor siteurl en la base de datos y la ubicación real del archivo. Usa WP-CLI (wp option update siteurl) o añade define('WP_SITEURL', 'https://yourdomain.com'); a wp-config.php como anulación temporal para restaurar el acceso.

¿Necesito actualizar wp-config.php después de mover WordPress a la raíz?

En la mayoría de los casos, no. El archivo wp-config.php usa rutas relativas para la conexión a la base de datos y no codifica de forma fija la ruta de instalación. La excepción es si ABSPATH ha sido definido manualmente como una ruta absoluta que apunta al antiguo directorio /wordpress — en ese caso, actualiza o elimina esa línea.

¿Por qué las imágenes siguen rotas después de ejecutar Better Search Replace?

Esto generalmente significa que el plugin se ejecutó contra un subconjunto de tablas y omitió tablas personalizadas de plugins o la tabla wp_postmeta. Vuelve a ejecutar el reemplazo con todas las tablas seleccionadas, y también verifica las rutas absolutas del sistema de archivos (p. ej., /public_html/wordpress/wp-content/uploads/) además de las cadenas basadas en URL.

¿Cómo manejo esto en una instalación WordPress Multisite?

Multisite requiere constantes adicionales en wp-config.php (DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE) y las URLs del sitio de la red deben actualizarse tanto en las tablas wp_site como wp_blogs. El procedimiento estándar de sitio único es insuficiente — trátalo como una migración completa de red y prueba primero en un clon de entorno de pruebas.