Dirección de WordPress vs Dirección del Sitio: Diferencias Técnicas, Configuración y Errores Comunes

WordPress Address (URL) y Site Address (URL) son dos parámetros de configuración distintos que controlan, respectivamente, dónde residen los archivos principales de WordPress en el servidor y qué URL utiliza el público para acceder al front end de su sitio. En la mayoría de las instalaciones estándar ambos valores son idénticos, pero pueden — y a veces deben — divergir cuando se alojan los archivos de WordPress en un subdirectorio mientras se sirve el sitio desde el dominio raíz.

Tener estos dos valores incorrectos, incluso por un solo carácter, puede bloquearte el acceso al panel de administración, generar advertencias de contenido mixto, romper los endpoints de la REST API y corromper las cadenas de redirección. Las secciones siguientes explican la lógica arquitectónica detrás de cada configuración, todos los escenarios legítimos para cambiarlos y los métodos exactos para hacerlo de forma segura.

La Lógica Arquitectónica Detrás de los Dos Parámetros de URL

WordPress almacena su configuración de URL en dos lugares simultáneamente: la tabla de base de datos wp_options (filas siteurl y home) y, opcionalmente, el archivo wp-config.php mediante constantes PHP. Comprender qué fuente tiene prioridad es esencial antes de modificar cualquier cosa.

Orden de prioridad (de mayor a menor):

1. Constantes definidas en wp-config.php (WP_SITEURL, WP_HOME)
2. Valores almacenados en la tabla wp_options
3. Valores introducidos en Ajustes > General en el panel de administración

Cuando se define una constante en wp-config.php, el campo correspondiente en Ajustes > General pasa a ser de solo lectura y aparece en gris. Esto es intencional — evita sobrescrituras accidentales a través de la interfaz mientras permite el control programático.

WordPress Address (URL) — WP_SITEURL

La WordPress Address corresponde a la opción siteurl en wp_options y a la constante WP_SITEURL en wp-config.php. Le indica a WordPress dónde residen físicamente sus archivos PHP principales, el directorio wp-admin y el directorio wp-includes. WordPress utiliza este valor para construir todas las referencias de rutas de archivos internas, incluida la URL de inicio de sesión del administrador, los endpoints AJAX (/wp-admin/admin-ajax.php) y la base de la REST API (/wp-json/).

Ejemplo: si tu instalación de WordPress se encuentra en https://example.com/wordpress, entonces WP_SITEURL debe ser https://example.com/wordpress. Navegar a https://example.com/wordpress/wp-admin llevará al panel de administración.

Site Address (URL) — WP_HOME

La Site Address corresponde a la opción home en wp_options y a la constante WP_HOME en wp-config.php. Define la URL pública canónica — la dirección que los usuarios escriben en sus navegadores y la base desde la cual WordPress genera todas las estructuras de permalinks del front end.

Ejemplo: incluso si los archivos principales se encuentran en https://example.com/wordpress, puedes establecer WP_HOME como https://example.com para que la página de inicio, las entradas y las páginas se sirvan desde el dominio raíz. Esto requiere un archivo index.php adicional y una regla .htaccess en la raíz (explicado más adelante).

Comparación: WordPress Address vs Site Address

Cuándo Estos Dos Valores Deben Diferir

La razón legítima más común para separar WP_SITEURL y WP_HOME es el patrón de instalación en subdirectorio: se desea tener los archivos de WordPress aislados en un subdirectorio limpio (p. ej., /wordpress o /cms) mientras el sitio público se resuelve en el dominio raíz. Esta es una elección arquitectónica deliberada, no una solución provisional.

Otros escenarios que requieren actualizar uno o ambos valores:

• Migración de dominio — pasar de http://old-domain.com a https://new-domain.com requiere actualizar ambos valores simultáneamente.
• Actualización de HTTP a HTTPS — añadir un certificado SSL implica cambiar el prefijo de protocolo en ambas configuraciones de http:// a https://. Actualizar solo uno produce errores de contenido mixto.
• Promoción de staging a producción — un entorno de staging normalmente se ejecuta en un subdominio o en un dominio diferente; ambos valores deben reescribirse durante el despliegue.
• Proxy inverso o descarga mediante CDN — cuando un balanceador de carga o CDN termina el SSL y reenvía el tráfico a un servidor backend, la configuración de URL de WordPress debe reflejar el dominio público, no la dirección interna del servidor.
• Reconfiguración de red Multisite — en WordPress Multisite, WP_SITEURL y WP_HOME interactúan con las constantes DOMAIN_CURRENT_SITE y PATH_CURRENT_SITE, lo que hace que la configuración correcta sea aún más crítica.

Método 1: Actualizar desde el Panel de Administración de WordPress

Este es el método adecuado cuando aún tienes acceso de administrador y el cambio es sencillo (p. ej., de HTTP a HTTPS en el mismo dominio).

1. Inicia sesión en https://yourdomain.com/wp-admin.
2. Navega a Ajustes > General.
3. Localiza los campos WordPress Address (URL) y Site Address (URL).
4. Actualiza ambos valores según sea necesario.
5. Haz clic en Guardar cambios.

WordPress te redirigirá inmediatamente a la URL de administración actualizada. Si cambiaste el dominio, tu navegador seguirá la redirección a la nueva dirección. Si el nuevo dominio aún no está resolviendo al servidor, perderás acceso al panel de administración — planifica la propagación DNS en consecuencia.

Método 2: Definir Constantes en wp-config.php

Este método es preferible en servidores de producción porque evita cambios accidentales desde la interfaz, funciona incluso cuando la base de datos no está disponible temporalmente y se puede gestionar fácilmente con control de versiones. En un entorno de VPS Hosting con acceso SSH root, este es el enfoque más fiable.

Abre wp-config.php en tu editor preferido:

nano /var/www/html/wp-config.php

Añade las siguientes dos líneas encima del comentario /* That's all, stop editing! */:

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

Para el patrón de instalación en subdirectorio donde los archivos principales están en /wordpress pero el sitio se sirve desde la raíz:

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

Guarda y cierra el archivo. Los campos del panel de administración ahora serán de solo lectura, lo cual es el comportamiento esperado.

Instalación en Subdirectorio: Los Pasos Necesarios para .htaccess e index.php

Cuando WP_HOME y WP_SITEURL difieren, WordPress por sí solo no puede enrutar las solicitudes del dominio raíz a los archivos principales en el subdirectorio. Debes colocar un index.php modificado y un archivo .htaccess en la raíz del documento.

Paso 1: Copia index.php desde el subdirectorio de WordPress a la raíz:

cp /var/www/html/wordpress/index.php /var/www/html/index.php

Paso 2: Edita el /var/www/html/index.php copiado para que apunte al subdirectorio:

<?php
// WordPress view bootstrapper
define( 'WP_USE_THEMES', true );

/** Loads the WordPress Environment and Template */
require __DIR__ . '/wordpress/wp-blog-header.php';

Paso 3: Asegúrate de que tu .htaccess raíz contiene el bloque de reescritura estándar 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

No copies el .htaccess del subdirectorio — contendrá RewriteBase /wordpress/ lo que romperá el enrutamiento del dominio raíz.

Método 3: Actualización Directa de la Base de Datos mediante WP-CLI

Cuando el panel de administración es inaccesible y prefieres no modificar wp-config.php de forma permanente, WP-CLI ofrece una solución limpia y automatizable. Esto es especialmente útil en Servidores Dedicados que ejecutan pipelines de despliegue automatizados.

wp option update siteurl 'https://example.com' --path=/var/www/html
wp option update home 'https://example.com' --path=/var/www/html

Para verificar que el cambio se aplicó correctamente:

wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

WP-CLI respeta las constantes de wp-config.php — si WP_SITEURL o WP_HOME ya están definidas allí, el comando wp option update no las sobreescribirá. Debes actualizar las constantes directamente en el archivo.

Método 4: Actualización Directa en MySQL (Último Recurso)

Utiliza esto solo cuando el acceso SSH está disponible pero WP-CLI no está instalado y el panel de administración está bloqueado. Identifica primero el prefijo de tu tabla (comprueba $table_prefix en wp-config.php, habitualmente wp_).

mysql -u db_user -p db_name

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

Confirma la actualización:

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

Sal de MySQL y limpia cualquier caché de objetos (Redis, Memcached u OPcache) antes de probar el sitio.

Configuración SSL y Actualizaciones de URL

Actualizar de HTTP a HTTPS es la razón más común para actualizar ambos parámetros de URL simultáneamente. Después de instalar un certificado SSL — ya sea mediante Let’s Encrypt a través de Certbot o un certificado comercial de un proveedor como los disponibles en Certificados SSL — debes actualizar tanto WP_HOME como WP_SITEURL para usar el prefijo https://.

No actualizar ambos, o actualizar solo uno, produce advertencias de contenido mixto: el navegador recibe una página HTTPS que hace referencia a recursos HTTP (scripts, hojas de estilo, imágenes). Los navegadores modernos bloquean completamente el contenido activo mixto, lo que rompe la funcionalidad de JavaScript y el panel de administración.

Después de actualizar las constantes de URL, ejecuta una búsqueda y reemplazo en la base de datos para actualizar todas las URL serializadas almacenadas en el contenido de entradas, postmeta y opciones:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

El indicador --all-tables garantiza que los datos serializados en tablas personalizadas (WooCommerce, constructores de páginas) también se actualicen. Realiza siempre una copia de seguridad de la base de datos antes de ejecutar este comando.

Configuración de URLs de WordPress con cPanel

Si gestionas WordPress en un VPS con cPanel, puedes usar el Administrador de Archivos de cPanel para editar wp-config.php sin necesidad de acceso SSH:

1. Inicia sesión en cPanel y abre el Administrador de Archivos.
2. Navega a la raíz del documento de WordPress (normalmente public_html o un subdirectorio).
3. Haz clic derecho en wp-config.php y selecciona Editar.
4. Añade las constantes WP_HOME y WP_SITEURL como se muestra en el Método 2.
5. Guarda el archivo.

Alternativamente, usa la herramienta phpMyAdmin en cPanel para ejecutar las sentencias SQL UPDATE del Método 4 directamente contra tu base de datos de WordPress.

Errores Críticos y Casos Especiales

Discrepancia de protocolo entre las dos configuraciones. Establecer WP_SITEURL como https://example.com y WP_HOME como http://example.com (o viceversa) crea un bucle de redirección. El navegador sigue la redirección HTTPS del servidor, pero WordPress genera enlaces HTTP en el front end, que el servidor vuelve a redirigir a HTTPS. Este bucle es invisible en el panel de administración pero devastador para los rastreadores y los usuarios.

Inconsistencia en la barra diagonal final. WordPress es sensible a las barras diagonales finales en estas constantes. https://example.com y https://example.com/ se tratan como valores diferentes. Omite siempre la barra diagonal final en ambas constantes para cumplir con las expectativas internas de WordPress.

Envenenamiento de la caché de objetos tras el cambio de URL. Si tu servidor ejecuta una caché de objetos persistente (Redis o Memcached), los valores de URL antiguos pueden estar almacenados en memoria incluso después de actualizar la base de datos. Vacía la caché de objetos inmediatamente después de cualquier cambio de URL:

wp cache flush --path=/var/www/html

Datos serializados en la base de datos. WordPress almacena muchos valores de opciones y metadatos de entradas como cadenas serializadas de PHP. Un reemplazo de cadenas sin control (p. ej., usando sed en un volcado de base de datos) corromperá los datos serializados al invalidar los prefijos de recuento de bytes. Utiliza siempre el comando search-replace de WP-CLI, que gestiona correctamente la serialización.

Consideraciones sobre redes Multisite. En una instalación de WordPress Multisite, WP_SITEURL se aplica al administrador de la red, no a los subsitios individuales. Cada subsitio tiene sus propias entradas siteurl y home en su respectiva tabla wp_X_options. Un cambio de URL a nivel de red requiere actualizar la tabla de opciones de cada subsitio, lo que WP-CLI gestiona con el indicador --network:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --network --path=/var/www/html

Confianza en las cabeceras del proxy inverso. En servidores detrás de un balanceador de carga o proxy inverso Nginx, WordPress puede detectar el protocolo incorrecto si el proxy no reenvía la cabecera X-Forwarded-Proto. Incluso con las constantes de URL correctas, los enlaces internos pueden revertir a HTTP. Añade lo siguiente a wp-config.php para forzar la detección de HTTPS:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Verificación de la Configuración Tras los Cambios

Después de actualizar cualquier parámetro de URL, realiza los siguientes pasos de verificación antes de considerar el cambio completo:

# Confirm wp_options values reflect the change
wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

# Check for mixed-content issues using curl
curl -sI https://example.com | grep -i location

# Verify the REST API is reachable at the correct base
curl -s https://example.com/wp-json/ | python3 -m json.tool | head -20

# Confirm no HTTP references remain in post content
wp search-replace --dry-run 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

El indicador --dry-run en el último comando informa cuántos reemplazos se realizarían sin modificar realmente los datos. Si el recuento es cero, la migración está limpia.

Para equipos que gestionan múltiples instancias de WordPress en entornos de Alojamiento Web Compartido o VPS, automatizar este paso de verificación en un script post-despliegue elimina el riesgo de lanzar un sitio con referencias de URL obsoletas.

Matriz de Decisión: Qué Método Utilizar

Lista de Verificación de Puntos Clave Técnicos

• Actualiza siempre WP_SITEURL y WP_HOME juntos a menos que necesites intencionalmente el patrón de subdirectorio.
• Define las constantes en wp-config.php en servidores de producción para evitar sobrescrituras accidentales desde la interfaz.
• Tras cualquier cambio de URL, vacía la caché de objetos y ejecuta wp search-replace con --all-tables para capturar datos serializados.
• Para migraciones de HTTP a HTTPS, actualiza primero las constantes de URL, luego ejecuta el search-replace y después verifica con curl para detectar contenido mixto.
• En instalaciones en subdirectorio, el index.php raíz debe hacer referencia a la ruta del subdirectorio, y .htaccess debe usar RewriteBase /.
• Nunca uses una barra diagonal final en las constantes WP_HOME o WP_SITEURL.
• En configuraciones con proxy inverso, añade la detección de HTTP_X_FORWARDED_PROTO a wp-config.php o WordPress generará referencias de protocolo incorrectas independientemente de la configuración de URL.
• En Multisite, la tabla wp_X_options de cada subsitio debe actualizarse de forma independiente; usa el indicador --network con WP-CLI.

Preguntas Frecuentes

¿Qué ocurre si WordPress Address y Site Address son diferentes sin la configuración de subdirectorio?

WordPress intentará cargar los archivos principales desde la ruta especificada en WP_SITEURL. Si no existe ninguna instalación de WordPress en esa ruta, todas las solicitudes de administración devolverán errores 404 o una pantalla en blanco. El front end puede seguir cargando si WP_HOME es correcto y las reglas de reescritura están intactas, pero cualquier solicitud AJAX, llamada a la REST API o acción de administración fallará.

¿Puedo establecer WP_HOME y WP_SITEURL con protocolos diferentes (uno HTTP, otro HTTPS)?

No. Mezclar protocolos entre las dos constantes crea un bucle de redirección que ni los navegadores ni los rastreadores pueden resolver. Ambas constantes deben usar el mismo protocolo. Si estás aplicando HTTPS a nivel de servidor (mediante Nginx o Apache), ambas constantes deben usar https://.

¿Por qué el campo WordPress Address aparece en gris en Ajustes > General?

El campo es de solo lectura porque WP_SITEURL (o WP_HOME) está definido como una constante PHP en wp-config.php. Las constantes definidas en el código tienen prioridad sobre los valores de la base de datos y no pueden sobreescribirse desde la interfaz. Para que el campo sea editable de nuevo, elimina o comenta la línea define() correspondiente en wp-config.php.

¿Afecta el cambio de Site Address a mi SEO y a los backlinks existentes?

Sí. Cambiar WP_HOME modifica la URL canónica base de cada página de tu sitio. Sin redirecciones 301 adecuadas desde la estructura de URL antigua a la nueva, los motores de búsqueda tratarán las URLs antiguas y nuevas como páginas separadas, dividiendo la autoridad de enlace y potencialmente generando penalizaciones por contenido duplicado. Configura siempre las redirecciones 301 a nivel de servidor antes o simultáneamente con el cambio de URL.

¿Cómo puedo recuperar el acceso si introduje la URL incorrecta y ahora estoy bloqueado en wp-admin?

Conéctate a tu servidor mediante SSH y define las constantes correctas en wp-config.php usando el Método 2, o usa WP-CLI para actualizar las opciones siteurl y home directamente mediante el Método 3. Si ninguna opción está disponible, usa phpMyAdmin o una conexión MySQL directa para ejecutar las sentencias UPDATE del Método 4. Una vez restaurado el acceso, elimina las constantes temporales si prefieres que el panel de administración gestione los valores en adelante.