Dónde guarda WordPress las URLs y páginas en la base de datos

Estás cambiando el dominio de una web, buscas la dirección antigua en la base de datos y empiezan a aparecer coincidencias por todas partes: wp_options, wp_posts, wp_postmeta, tablas de plugins y una columna llamada guid que tiene toda la pinta de ser justo lo que estabas buscando.

Es entonces cuando surge la pregunta: ¿en qué tabla guarda WordPress las URLs y las páginas?

La respuesta rápida es que WordPress no guarda todas las URLs en un único lugar. La dirección principal suele estar en wp_options; las páginas y entradas se almacenan en wp_posts; los slugs aparecen en post_name; y otras direcciones pueden quedar dentro del contenido, los metadatos, los ajustes o las tablas creadas por plugins.

Esto importa especialmente cuando vas a migrar una web, cambiar de dominio, corregir enlaces antiguos o localizar una dirección que sigue apareciendo después de haber modificado la configuración.

Tabla rápida: dónde guarda WordPress cada URL

Esta tabla sirve como mapa inicial. El prefijo wp_ es el habitual, pero puede haberse cambiado durante la instalación.

Dato	Ubicación habitual	Campo o referencia
Dirección pública de la web	wp_options	home
Dirección donde está instalado WordPress	wp_options	siteurl
Páginas, entradas y otros contenidos	wp_posts	Varias columnas
Slug de una página o entrada	wp_posts	post_name
Contenido con enlaces o imágenes	wp_posts	post_content
Metadatos de páginas y plugins	wp_postmeta	meta_value
Ajustes generales y de plugins	wp_options	option_value
Slug de categorías y etiquetas	wp_terms	slug
URL del perfil de un usuario	wp_users	user_url
Enlaces del antiguo blogroll	wp_links	link_url
URL definida manualmente	wp-config.php	WP_HOME y WP_SITEURL

Dónde se guardan las páginas de WordPress

Las páginas de WordPress se guardan principalmente en la tabla:

wp_posts

El nombre puede despistar. wp_posts no contiene únicamente entradas del blog. También puede almacenar:

• Páginas.
• Entradas.
• Archivos adjuntos.
• Revisiones.
• Elementos de menú.
• Tipos de contenido personalizados.
• Productos de WooCommerce.
• Plantillas o bloques registrados por determinados plugins.

La columna post_type indica qué clase de contenido representa cada fila.

Una página normal suele aparecer como:

post_type = page

Una entrada del blog utiliza:

post_type = post

Y un producto de WooCommerce suele utilizar:

post_type = product

Campos importantes de wp_posts

Campo	Qué contiene
ID	Identificador interno del contenido.
post_title	Título de la página o entrada.
post_content	Contenido principal.
post_excerpt	Extracto, cuando existe.
post_status	Estado: publicada, borrador, privada, papelera, etc.
post_name	Slug del contenido.
post_type	Tipo de contenido.
post_parent	ID del contenido superior, si existe jerarquía.
guid	Identificador global del elemento.

La documentación de WordPress explica que la base de datos almacena páginas, entradas, comentarios, usuarios y opciones del sitio. Puedes ampliar esta información en la guía oficial sobre
la base de datos de WordPress
.

Dónde se guarda el slug de una página

El slug de una página o entrada suele guardarse en:

wp_posts.post_name

Por ejemplo, en esta dirección:

https://ejemplo.com/servicios/diseno-web/

El post_name de la página final podría ser:

diseno-web

Pero eso no significa que la URL completa esté almacenada en esa columna.

El permalink final puede depender de:

• El dominio configurado.
• La estructura de enlaces permanentes.
• El tipo de contenido.
• La página superior.
• La categoría o taxonomía.
• Las reglas de reescritura.
• El idioma.
• Plugins que modifican URLs.

Ejemplo de una página hija

Imaginemos esta dirección:

https://ejemplo.com/servicios/diseno-web/

La página Diseño web puede tener:

post_name = diseno-web

Y su página superior Servicios:

post_name = servicios

La relación se mantiene mediante post_parent. WordPress combina los datos para construir la ruta pública.

La estructura de enlaces permanentes también cuenta

Las entradas del blog pueden utilizar estructuras como:

/%postname%/

O:

/%category%/%postname%/

Esa configuración suele almacenarse en wp_options, mediante opciones relacionadas con los enlaces permanentes.

Por eso dos instalaciones pueden tener el mismo contenido y el mismo post_name, pero generar direcciones diferentes.

Después de una migración o de modificar reglas de URL, a veces es necesario entrar en:

Ajustes → Enlaces permanentes

y guardar de nuevo la configuración para regenerar las reglas.

El campo guid parece una URL, pero no es el permalink

Dentro de wp_posts existe una columna llamada guid. Sus valores suelen tener forma de URL:

https://dominio-antiguo.com/?p=123

O incluso:

https://dominio-antiguo.com/nombre-de-la-pagina/

Esto lleva a pensar que guid contiene la dirección pública que debemos actualizar durante una migración.

No debe tratarse así.

GUID significa Globally Unique Identifier. Su función es identificar de manera estable el elemento, no actuar como permalink público.

Por eso, en sus ejemplos oficiales de búsqueda y reemplazo, WP-CLI muestra cómo omitir esta columna:

wp search-replace 'https://antiguo.com' 'https://nuevo.com' --skip-columns=guid

Puedes consultar las opciones en la documentación de
wp search-replace
.

wp_options: diferencia entre home y siteurl

La tabla wp_options contiene ajustes generales de WordPress y datos guardados por temas y plugins.

Entre sus opciones más importantes están:

home
siteurl

Qué es home

home representa normalmente la dirección pública desde la que se visita la web.

Ejemplo:

https://ejemplo.com

Qué es siteurl

siteurl indica dónde se encuentran los archivos principales de WordPress.

En una instalación normal puede coincidir con home:

home:    https://ejemplo.com
siteurl: https://ejemplo.com

Pero pueden ser diferentes si WordPress está instalado en una subcarpeta:

home:    https://ejemplo.com
siteurl: https://ejemplo.com/wordpress

WordPress explica esta diferencia en su documentación sobre
migraciones y cambios de dirección
.

Consulta orientativa en phpMyAdmin

Para localizar ambas opciones se puede utilizar una consulta de lectura:

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

Recuerda adaptar el prefijo si la tabla no se llama wp_options.

WP_HOME y WP_SITEURL pueden sobrescribir la base de datos

Aunque home y siteurl estén guardados en wp_options, pueden existir constantes en wp-config.php que sustituyan esos valores durante la ejecución:

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

Si estas constantes están definidas, modificar únicamente la tabla puede no producir el resultado esperado.

También puede ocurrir lo contrario: la web funciona mientras las constantes existen y vuelve a utilizar los valores antiguos al eliminarlas, porque la base de datos nunca llegó a actualizarse.

La documentación oficial confirma que WP_SITEURL puede sobrescribir el valor almacenado en wp_options sin cambiarlo realmente. :contentReference[oaicite:1]{index=1}

URLs guardadas dentro de post_content

La columna wp_posts.post_content puede contener direcciones completas dentro del contenido.

Por ejemplo:

• Enlaces internos.
• Imágenes.
• Botones.
• Vídeos incrustados.
• Iframes.
• Shortcodes.
• Bloques de Gutenberg.
• Contenido generado por maquetadores.

Un enlace podría estar almacenado así:

<a href="https://dominio-antiguo.com/contacto/">
  Contactar
</a>

Y una imagen:

<img src="https://dominio-antiguo.com/wp-content/uploads/imagen.jpg"
     alt="Ejemplo">

Esto explica por qué cambiar solamente home y siteurl no siempre elimina las referencias al dominio anterior.

wp_postmeta: URLs, IDs y datos de plugins

wp_postmeta almacena información adicional asociada a páginas, entradas, productos y otros contenidos.

Puede contener datos generados por:

• Divi.
• Elementor.
• WooCommerce.
• Plugins SEO.
• Campos personalizados.
• Galerías.
• Sliders.
• Sistemas de reservas.
• Plugins de idiomas.

No siempre encontrarás una URL completa. El valor puede ser:

• Un ID.
• Una ruta.
• Una URL absoluta.
• Un array serializado.
• Una cadena JSON.
• Una configuración propia del plugin.

La imagen destacada suele guardar un ID

WordPress suele relacionar la imagen destacada mediante la clave:

_thumbnail_id

Su valor habitual es el ID del archivo adjunto, no la dirección completa de la imagen.

Después WordPress consulta el adjunto correspondiente en wp_posts y sus datos adicionales en wp_postmeta.

wp_options también puede contener URLs de plugins

Además de home y siteurl, wp_options puede almacenar:

• Opciones del tema.
• Widgets.
• Configuraciones de plugins.
• Logotipos.
• Redirecciones.
• URLs de integraciones.
• Datos serializados.
• Transients y cachés.

Algunos registros pueden ser muy extensos. Un maquetador o tema puede guardar buena parte de su configuración en una sola opción.

Dónde se guardan categorías, etiquetas y taxonomías

WordPress reparte la información de categorías, etiquetas y otras taxonomías entre varias tablas:

• wp_terms
• wp_term_taxonomy
• wp_term_relationships
• wp_termmeta

wp_terms

Contiene el nombre y el slug del término.

Ejemplo:

name = Diseño web
slug = diseno-web

wp_term_taxonomy

Indica si el término pertenece a una categoría, una etiqueta o una taxonomía personalizada.

wp_term_relationships

Relaciona los términos con entradas, productos u otros objetos.

wp_termmeta

Almacena datos adicionales asociados a los términos.

De nuevo, el slug no representa necesariamente la URL completa. WordPress combina el término, la taxonomía, las bases configuradas y las reglas de enlaces permanentes.

Qué es wp_links

La tabla wp_links pertenece al antiguo sistema de enlaces o blogroll de WordPress.

Podía almacenar información como:

• URL del enlace.
• Nombre.
• Descripción.
• Relación.
• Visibilidad.
• Orden.

La columna principal para la dirección era:

link_url

En una web actual, wp_links no es la tabla general donde WordPress guarda los enlaces internos de las páginas.

Puede seguir existiendo por compatibilidad o porque se haya utilizado el antiguo gestor de enlaces, pero normalmente tendrá poca o ninguna actividad.

Dónde se guarda la URL de un usuario

El campo web del perfil de un usuario se guarda normalmente en:

wp_users.user_url

La tabla wp_usermeta contiene otros datos relacionados con los usuarios, como preferencias y configuraciones adicionales.

Un plugin puede guardar perfiles sociales o direcciones personalizadas en wp_usermeta, pero la ubicación estándar del campo “Web” es user_url dentro de wp_users.

Los plugins pueden crear sus propias tablas

No toda la información tiene que estar en las tablas estándar de WordPress.

Algunos plugins crean tablas específicas para almacenar:

• Pedidos.
• Redirecciones.
• Formularios.
• Registros.
• Estadísticas.
• Caché.
• Reservas.
• URLs rastreadas.
• Datos SEO.

Por eso, una búsqueda limitada a wp_posts y wp_options puede no encontrar todas las apariciones de un dominio.

También es posible que una tabla permanezca después de eliminar el plugin que la creó. Antes de modificarla o borrarla conviene identificar su origen.

El problema de los datos serializados

WordPress y muchos plugins guardan arrays y objetos en formato serializado.

Un ejemplo simplificado podría parecerse a esto:

a:1:{s:3:"url";s:30:"https://dominio-antiguo.com";}

La cadena incluye información sobre la longitud de determinados valores. Si sustituyes el dominio por otro de diferente tamaño mediante un REPLACE() SQL simple, esa longitud puede dejar de coincidir.

El resultado puede ser:

• Widgets rotos.
• Opciones que dejan de cargarse.
• Configuraciones perdidas.
• Maquetadores que no interpretan sus datos.
• Errores difíciles de relacionar con el reemplazo.

Cómo buscar un dominio antiguo en WordPress

Antes de reemplazar nada, conviene localizar dónde aparece.

Con WP-CLI se puede realizar una búsqueda en las columnas de texto de las tablas registradas:

wp db search 'dominio-antiguo.com'

El comando oficial
wp db search
muestra las tablas y columnas donde encuentra coincidencias. En instalaciones multisitio, su alcance por defecto se limita a las tablas del sitio actual.

También se puede exportar la base de datos y buscar dentro del archivo, siempre que trabajes sobre una copia y no expongas información sensible.

Cómo cambiar URLs sin romper WordPress

El método correcto depende del motivo del cambio:

• Cambio de dominio.
• Migración de servidor.
• Paso de HTTP a HTTPS.
• Cambio de subcarpeta.
• Traslado de desarrollo a producción.
• Corrección de URLs incrustadas.

1. Haz una copia completa

Necesitas como mínimo una copia de la base de datos. En una migración seria también debes conservar:

• Archivos de WordPress.
• Temas.
• Plugins.
• Carpeta de medios.
• wp-config.php.
• Configuración del servidor cuando proceda.

WordPress recomienda hacer copias periódicas y antes de cambios importantes. La copia de la base de datos no incluye por sí sola los archivos del sitio. :contentReference[oaicite:2]{index=2}

2. Comprueba home y siteurl

Revisa los valores actuales y confirma si están sobrescritos en wp-config.php.

3. Busca el dominio anterior

Localiza coincidencias antes de sustituirlas. Así sabrás si aparecen en contenido, metadatos, opciones o tablas propias.

4. Ejecuta una simulación

WP-CLI permite hacer una prueba sin guardar cambios:

wp search-replace \
'https://dominio-antiguo.com' \
'https://dominio-nuevo.com' \
--skip-columns=guid \
--dry-run

La opción --dry-run muestra qué se modificaría sin escribir todavía en la base de datos.

5. Revisa los resultados

Comprueba:

• Número de reemplazos.
• Tablas afectadas.
• Columnas encontradas.
• Coincidencias que no deberían cambiarse.
• Tablas antiguas o de copias.

6. Ejecuta el cambio real

Solo después de revisar la simulación:

wp search-replace \
'https://dominio-antiguo.com' \
'https://dominio-nuevo.com' \
--skip-columns=guid

WP-CLI procesa datos serializados y ofrece opciones para seleccionar tablas, columnas y alcance. Aun así, no sustituye una copia previa ni una revisión posterior.

7. Limpia cachés y regenera enlaces

Después del cambio puede ser necesario:

• Vaciar la caché de WordPress.
• Vaciar la caché del servidor.
• Limpiar CDN.
• Guardar enlaces permanentes.
• Regenerar CSS de un maquetador.
• Revisar imágenes y recursos.

8. Prueba la web de verdad

No basta con que cargue la portada.

Revisa:

• Acceso al administrador.
• Páginas interiores.
• Imágenes.
• Menús.
• Formularios.
• Carrito y pagos.
• Redirecciones.
• Canonicals.
• Sitemap.
• Enlaces internos.
• Recursos mixtos HTTP y HTTPS.

¿Se puede cambiar el dominio con phpMyAdmin?

Se puede modificar información desde phpMyAdmin, pero eso no significa que sea la mejor herramienta para reemplazar URLs en toda una instalación.

phpMyAdmin puede ser útil para:

• Consultar valores.
• Corregir home y siteurl si no puedes acceder.
• Revisar una fila concreta.
• Importar o exportar una base de datos.

El riesgo aparece cuando se ejecutan reemplazos globales sin contemplar datos serializados, columnas que no deben tocarse o tablas creadas por plugins.

Qué cambia en WordPress Multisite

Una instalación multisitio utiliza tablas globales y grupos de tablas asociados a cada sitio.

Puedes encontrar estructuras como:

wp_options
wp_2_options
wp_3_options
wp_2_posts
wp_3_posts

Además, existen tablas específicas de red.

Un reemplazo que solo actúe sobre las tablas del sitio principal puede dejar direcciones antiguas en otros sitios. Por el contrario, un reemplazo global mal planteado puede modificar información compartida que no debía tocarse.

WP-CLI dispone de opciones de ámbito y selección de tablas para trabajar con instalaciones multisitio. Antes de cambiar nada hay que identificar si el dominio se utiliza como dominio principal, subdominio, dominio mapeado o parte de una ruta.

Errores habituales al buscar o cambiar URLs

• Creer que todas las URLs están en wp_options.
• Confundir guid con el permalink.
• Modificar únicamente siteurl y olvidar home.
• No revisar constantes en wp-config.php.
• Suponer que el prefijo siempre es wp_.
• Ejecutar un REPLACE() sobre datos serializados.
• No realizar una simulación previa.
• No hacer copia de seguridad.
• Ignorar tablas creadas por plugins.
• Olvidar imágenes y enlaces dentro de post_content.
• No limpiar cachés después del cambio.
• No revisar redirecciones y canonicals.
• Probar únicamente la portada.
• Aplicar instrucciones de una instalación simple a un multisite.

Un ejemplo práctico: la web sigue cargando imágenes del dominio anterior

Imaginemos que has cambiado:

https://web-antigua.com

por:

https://web-nueva.com

Has actualizado home y siteurl, puedes entrar al administrador y la portada carga. Aun así, algunas imágenes siguen solicitándose desde el dominio anterior.

El motivo puede estar en:

• URLs absolutas dentro de post_content.
• Datos de un maquetador en wp_postmeta.
• Opciones del tema en wp_options.
• CSS generado y guardado en archivos.
• Caché del servidor o del CDN.
• Widgets serializados.

Modificar otra vez siteurl no resolverá esas referencias.

Lo razonable sería:

1. Buscar el dominio antiguo.
2. Identificar tablas y columnas.
3. Hacer una simulación del reemplazo.
4. Excluir guid.
5. Ejecutar el cambio con una herramienta compatible con datos serializados.
6. Regenerar archivos del maquetador.
7. Vaciar cachés.
8. Comprobar de nuevo la web.

Esta escena es bastante habitual. Cambiar la dirección principal arregla la puerta de entrada, pero no obliga a cada imagen, botón y configuración antigua a hacer las maletas.

Dónde guarda WordPress las URLs: la idea que debes conservar

WordPress no mantiene un listado central con todas las direcciones de la web.

Las páginas se guardan en wp_posts, pero la URL se construye utilizando el dominio, el slug, la jerarquía, el tipo de contenido y las reglas de enlaces permanentes.

Además, pueden existir direcciones completas en el contenido, los metadatos, las opciones, los perfiles de usuario y las tablas creadas por plugins.

Por eso un cambio de dominio no consiste únicamente en sustituir dos valores ni en ejecutar una consulta sobre toda la base de datos esperando que WordPress recomponga las piezas.

Si estás buscando estas tablas porque necesitas trasladar una web, en ideaWeb ofrecemos un servicio de
migración web
en el que revisamos archivos, base de datos, URLs, redirecciones y funcionamiento posterior.

Cuando la web ya se ha movido y aparecen errores, enlaces rotos, recursos antiguos o problemas de acceso, también podemos
reparar la web
y localizar dónde ha quedado guardada la configuración incorrecta.

Y si prefieres que estas operaciones no dependan de una intervención de urgencia cada vez que algo falla, el
mantenimiento WordPress
ayuda a trabajar con copias, revisiones y cambios controlados.

Preguntas frecuentes sobre las URLs de WordPress

¿Dónde se guardan las páginas de WordPress?

Las páginas se guardan principalmente en wp_posts. Se identifican mediante el valor page en la columna post_type.

¿Dónde guarda WordPress la URL principal?

Normalmente en wp_options. La opción home representa la dirección pública y siteurl indica dónde se encuentran los archivos de WordPress.

¿Dónde se guarda el slug de una página?

El slug suele almacenarse en wp_posts.post_name. La URL final también depende del dominio, la jerarquía y los enlaces permanentes.

¿El campo guid es la URL de la página?

No debe tratarse como el permalink público. Es un identificador global y normalmente se excluye de los reemplazos durante una migración.

¿Qué es la tabla wp_links?

Es una tabla del antiguo gestor de enlaces o blogroll de WordPress. No contiene todos los enlaces internos de una web moderna.

¿Dónde se guardan los enlaces incluidos en una página?

Los enlaces escritos dentro del contenido pueden aparecer en wp_posts.post_content. También pueden existir en metadatos, opciones o tablas de plugins.

¿Dónde se guardan las URLs de las imágenes?

Pueden aparecer dentro del contenido, en metadatos o en ajustes de plugins. La imagen destacada suele relacionarse mediante un ID guardado en _thumbnail_id.

¿Puedo cambiar el dominio modificando solo home y siteurl?

Eso cambia las direcciones principales, pero puede dejar referencias antiguas en contenidos, imágenes, opciones, widgets y configuraciones de plugins.

¿Puedo reemplazar URLs directamente con SQL?

Es arriesgado cuando existen datos serializados. Conviene utilizar una herramienta compatible con serialización, hacer copia previa y ejecutar primero una simulación.

¿Por qué WordPress sigue mostrando el dominio antiguo?

Puede permanecer en post_content, postmeta, opciones, archivos CSS generados, cachés, widgets o tablas propias de plugins.

¿WP_HOME y WP_SITEURL sustituyen los valores de la base de datos?

Sí, pueden sobrescribirlos durante la ejecución. Definirlos en wp-config.php no implica necesariamente que el valor almacenado en la base de datos haya cambiado.

¿Debo hacer una copia antes de cambiar URLs?

Sí. Como mínimo debes respaldar la base de datos y, para una recuperación completa, también los archivos, plugins, temas, medios y configuración.