O WordPress e quase todos os Plugins guardam as suas definições num local único do teu servidor chamado “base de dados”. Os dados guardados na base de dados estão organizados nas chamadas “tabelas”. Este artigo vai explicar em detalhe o significado de todos os campos disponíveis da estrutura predefinida da base de dados WordPress.
Resumo: O WordPress armazena a maior parte dos dados do site numa base de dados MySQL ou MariaDB. Uma instalação WordPress de site único padrão usa atualmente 12 tabelas predefinidas com um prefixo configurável, normalmente
wp_. Estas tabelas armazenam publicações, páginas, utilizadores, definições, comentários, termos de taxonomia e metadados, enquanto Plugins, Themes, WooCommerce e instalações Multisite podem adicionar mais tabelas.
Nota: Para inspecionar a tua base de dados WordPress em segurança, faz Backup do teu site ou cria um ambiente de Staging com o WP STAGING. Depois usa uma ferramenta de gestão de base de dados, como o phpMyAdmin ou o Adminer, para aceder e modificar a base de dados sem impacto no site em produção.
Contents
- Tabelas da base de dados WordPress em síntese
- Como são as tabelas da base de dados?
- Lista de tabelas do núcleo do WordPress
- wp_options
- wp_users,wp_usermeta
- wp_posts,wp_postmeta
- wp_terms,wp_term_relationships,wp_term_taxonomy, wp_termmeta
- wp_comments,wp_commentmeta
- wp_links
- Próxima tabela do WordPress 7.0: wp_collaboration
- Estrutura gráfica da base de dados WordPress
- Problemas comuns da base de dados WordPress e as tabelas por trás deles
- Artigos relacionados
Tabelas da base de dados WordPress em síntese
Uma instalação WordPress de site único padrão usa atualmente 12 tabelas predefinidas. A tabela abaixo resume o que cada tabela armazena, onde o WordPress a usa e o que pode partir se a tabela faltar ou estiver corrompida.
| Tabela | Armazena | Usada para | O que parte se faltar ou estiver corrompida |
|---|---|---|---|
wp_options | URL do site, Plugins ativos, definições de Theme, transients, regras de rewrite, dados de cron | Bootstrap do WordPress, definições de Plugins, configuração do site | Redirecionamentos para URL errado, definições em falta, falhas de Plugins, cron partido, options autoload lentos |
wp_posts | Publicações, páginas, anexos, revisões, menus, tipos de conteúdo personalizados | Conteúdo, biblioteca de media, menus de navegação, muitos tipos de dados de Plugins | Páginas/publicações/media em falta, menus partidos, entradas de tipos de conteúdo personalizados em falta |
wp_postmeta | Metadados de publicações, páginas, anexos, produtos, page builders, Plugins SEO | Imagens destacadas, dados de produto, campos SEO, layouts de builders | Imagens em falta, layouts partidos, dados de produto em falta, metadados SEO incompletos |
wp_users | Contas de utilizador, logins, hashes de palavra-passe, emails, nomes de exibição | Autenticação e autoria | Utilizadores não conseguem iniciar sessão, autores desaparecem |
wp_usermeta | Funções de utilizador, capabilities, campos de perfil, definições de utilizador de Plugins | Permissões e definições por utilizador | Administrador perde permissões, funções desaparecem, definições de utilizador partem |
wp_comments | Comentários, pingbacks, trackbacks, avaliações | Sistemas de comentários e avaliações | Comentários ou avaliações desaparecem |
wp_commentmeta | Metadados de comentários e avaliações | Estado de spam, ratings, dados de Plugins em comentários | Metadados de avaliações, dados de spam ou de Plugins em comentários perdem-se |
wp_terms | Nomes e slugs de termos | Categorias, etiquetas, categorias de links, termos de taxonomia personalizada | Nomes de categorias e etiquetas desaparecem |
wp_termmeta | Metadados para termos de taxonomia | Imagens de termos, metadados SEO, campos personalizados de termos | Metadados de categorias/etiquetas desaparecem |
wp_term_taxonomy | Tipo de taxonomia, relação parental, contagens de termos | Distingue categoria vs etiqueta vs taxonomia personalizada | Categorias/etiquetas ficam mal mapeadas ou perdem a hierarquia |
wp_term_relationships | Relações entre conteúdo e termos de taxonomia | Atribui publicações/produtos/páginas a categorias e etiquetas | Publicações perdem categorias/etiquetas, menus e relações de taxonomia partem |
wp_links | Dados legados do blogroll/gestor de links | Funcionalidade Links Manager deprecada e Plugins antigos | Normalmente nada em sites modernos, a menos que um Plugin antigo ainda use |
Como são as tabelas da base de dados?
Imagina uma folha do Excel com uma linha de cabeçalho e valores na linha abaixo.
Por exemplo, podes ver uma pequena secção da tabela aqui. wp_options:

Vamos falar sobre essas tabelas com mais profundidade para perceber porque é essencial saber qual a tabela responsável pelo conteúdo de um site WordPress.
Compreender a estrutura das tabelas vai ajudar-te a saber qual a tabela que precisas de incluir ou excluir se planeias sincronizar ou mover dados de um site de Staging para o site em produção, ou vice-versa, com o WP STAGING. Também é útil se planeias atualizar o site de Staging.
Isto torna-se ainda mais importante com o WordPress 7.0 e posteriores. A tabela planeada wp_collaboration armazena dados de colaboração do editor em tempo real, que normalmente são temporários e específicos do ambiente. Ao enviar um site de Staging para o site em produção, evita sobrescrever o estado de colaboração ativo do site em produção, a menos que pretendas intencionalmente substituir toda a base de dados.
Lista de tabelas do núcleo do WordPress
A tabela acima dá uma visão geral rápida. A secção seguinte explica as tabelas do núcleo do WordPress em mais detalhe para programadores, proprietários de sites e qualquer pessoa a diagnosticar migrações, Backups ou problemas de base de dados.
- wp_options
- wp_users,
- wp_usermeta
- wp_posts
- wp_postmeta
- wp_terms
- wp_term_relationships
- wp_term_taxonomy
- wp_termmeta
- wp_comments
- wp_commentmeta
- wp_links
O WordPress pode adicionar novas tabelas ao núcleo em lançamentos importantes. Por exemplo, o WordPress 7.0 está planeado para introduzir `wp_collaboration` para dados de colaboração em tempo real no editor.
Outras tabelas na tua base de dados são criadas por Plugins ou Themes e nem sempre são necessárias para o site funcionar.
wp_options
A tabela wp_options é uma das tabelas da base de dados WordPress mais essenciais e armazena todas as definições de um site WordPress, como o URL, o título, Plugins instalados, etc! A maioria dos Plugins também armazena definições nesta tabela.
Todas as definições no painel do WordPress são armazenadas nesta tabela.
wp_users,
wp_usermeta
wp_users armazena todos os utilizadores registados num site WordPress. Contém informação básica sobre um utilizador, como nome de utilizador e palavra-passe encriptada, email, hora de registo, nome de exibição, estado e mais alguns campos.
wp_usermeta armazena os metadados (‘dados adicionais‘) dos utilizadores. Estende a tabela wp_users com mais dados. Por exemplo, o primeiro nome de um utilizador é armazenado na tabela wp_usermeta em vez de na tabela wp_users.
Há dois campos necessários nesta tabela. Os Plugins podem armazenar dados personalizados em wp_usermeta apenas adicionando um novo valor no campo meta_key.
wp_posts,
wp_postmeta
A tabela wp_posts armazena todos os dados de conteúdo de um site WordPress. Todas as publicações, páginas e respetivas revisões estão disponíveis na tabela wp_posts. Pode não ser claro, mas o WordPress armazena muito mais nessa tabela.
Esta tabela também contém itens de menu de navegação, ficheiros de media e anexos como imagens e dados de conteúdo usados por Plugins.
Em wp_posts existe uma coluna post_type que segmenta esses tipos diferentes de dados para que uma query à base de dados possa pedir tipos específicos. post_type é a coluna mais crítica desta tabela.
Nas imagens abaixo, podes ver dois post_types diferentes,revision e attachment, que são guardados na mesma tabela wp_posts:


A tabela wp_postmeta, tal como wp_usermeta, estende a tabela wp_posts com mais dados, que também podem ser usados por outros Plugins.
Por exemplo, o popular Plugin Yoast SEO guarda tags Open Graph personalizadas, publicações e dados de URL nesta tabela.
wp_terms,
wp_term_relationships,
wp_term_taxonomy,
wp_termmeta
A tabela wp_terms armazena categorias e etiquetas para publicações, páginas e links.
Uma das colunas desta tabela é ‘slug’. Um slug é um termo que reflete uma etiqueta de uma publicação em particular. No WordPress, podes usar etiquetas para ligar publicações, páginas e links.
wp_term_relationships é a conjunção e liga essas etiquetas a publicações, páginas e links. É como um mapa entre os objetos de termos e os termos.
wp_term_taxonomy estende a tabela wp_terms com mais dados. É como metadados para a tabela wp_terms, com a diferença de que os Plugins não podem adicionar dados personalizados aqui. Esta tabela também contém uma relação entre menus e itens de menu.
A tabela wp_termmeta armazena metadados para termos de taxonomia. Funciona de forma semelhante a wp_postmeta, wp_usermeta e wp_commentmeta, mas para categorias, etiquetas e termos de taxonomia personalizada.
Plugins e Themes podem usar esta tabela para armazenar dados adicionais sobre termos, como imagens de categoria, metadados SEO, cores personalizadas, definições de apresentação ou outros campos específicos de taxonomia.
Se esta tabela faltar ou estiver incompleta após uma migração, as categorias e etiquetas podem ainda existir, mas os seus metadados adicionais podem perder-se.
wp_comments,
wp_commentmeta
wp_comments armazena comentários em publicações e páginas. Esta tabela também contém comentários não aprovados e informação de autor, juntamente com a hierarquia de comentários. A tabela wp_commentmeta contém metadados adicionais sobre os comentários.
wp_links
Esta tabela contém informação sobre links personalizados adicionados ao teu site. Foi deprecada e já não é usada. Há alguns Plugins mais antigos que ainda a usam, mas normalmente é uma tabela vazia.
Próxima tabela do WordPress 7.0: wp_collaboration
`wp_collaboration` é uma nova tabela do núcleo da base de dados WordPress planeada para o WordPress 7.0. Faz parte da funcionalidade de colaboração em tempo real no editor de blocos, que permite a vários utilizadores editar a mesma publicação ou página ao mesmo tempo.
As versões beta anteriores do WordPress 7.0 armazenavam dados de sincronização relacionados com colaboração no armazenamento de publicações e meta de publicações. Isto criou problemas de desempenho porque a atividade do editor em tempo real pode escrever dados com muita frequência. Cada atualização de post meta pode invalidar caches de objetos relacionados com publicações, o que pode reduzir a eficácia do cache persistente de objetos enquanto uma sessão de editor está aberta.
A nova tabela `wp_collaboration` separa os dados de colaboração de alta frequência das tabelas regulares de conteúdo como `wp_posts` e `wp_postmeta`. O seu propósito é armazenar dados temporários de sincronização usados pelo editor, como atualizações de edição colaborativa, identificadores de cliente/sessão, informação de sala e timestamps usados para limpeza.
Esta tabela **não** substitui `wp_posts`, `wp_postmeta` nem o sistema de revisões do WordPress. Publicações, páginas, anexos, tipos de conteúdo personalizados e revisões continuam a ser armazenados em `wp_posts`; os metadados específicos de publicações permanecem em `wp_postmeta`.
Para Backups e migrações, trata a `wp_collaboration` de forma diferente das tabelas de conteúdo permanente. Um Backup completo da base de dados deve incluí-la, mas ao enviar um site de Staging para produção, esta tabela normalmente não precisa de sobrescrever o site em produção, porque armazena dados de colaboração/sessão de curta duração em vez de conteúdo canónico do site. O WordPress consegue recriar o estado de colaboração à medida que os utilizadores editam conteúdo.
Importante: embora os dados sejam temporários, podem ainda conter payloads de sincronização do editor relacionados com conteúdo em curso. Não os trates como públicos ou descartáveis do ponto de vista da privacidade e segurança.
Nota: O schema final ainda pode mudar antes do lançamento do WordPress 7.0. Durante o desenvolvimento, as propostas públicas para `wp_collaboration` incluíram campos como um ID auto-incrementado, identificador de sala, identificadores de cliente/utilizador, um payload de dados e um timestamp GMT. Testes recentes também exploram armazenar dados de presença/awareness numa tabela separada `wp_presence`. Verifica o schema final da base de dados do WordPress 7.0 antes de publicares a lista exata de colunas.
Estrutura gráfica da base de dados WordPress
Este diagrama mostra como as tabelas do WordPress estão ligadas:
Abre a imagem em resolução total: botão direito -> abrir imagem em novo separador
Problemas comuns da base de dados WordPress e as tabelas por trás deles
| Problema | Tabela(s) mais relevante(s) | O que verificar |
|---|---|---|
| O site redireciona para o domínio errado após migração | wp_options | Verifica siteurl, home e options de Plugins serializadas |
| O utilizador admin existe mas não tem permissões de administrador | wp_usermeta | Verifica a chave capabilities, especialmente após mudança de prefixo de tabela |
| As publicações existem mas as categorias ou etiquetas estão em falta | wp_terms, wp_term_taxonomy, wp_term_relationships | Verifica se todas as tabelas de taxonomia foram migradas em conjunto |
| Entradas na biblioteca de media existem mas as imagens estão partidas | wp_posts, wp_postmeta, pasta uploads | Os anexos estão em wp_posts; caminhos de ficheiro frequentemente em _wp_attached_file em wp_postmeta |
| Os menus desaparecem após migração | wp_posts, wp_terms, wp_term_relationships, wp_postmeta | Os menus de navegação estão distribuídos por várias tabelas |
| Definições de Plugins desaparecem | wp_options, por vezes tabelas específicas de Plugins | Verifica se o Plugin guarda definições em wp_options ou em tabelas personalizadas |
| O site fica lento após migração | wp_options, wp_postmeta | Verifica options autoload e tabelas grandes de metadados |
| Comentários ou avaliações desaparecem | wp_comments, wp_commentmeta | Migra ambas as tabelas em conjunto |
| O WordPress diz que uma tabela não existe | wp-config.php, todas as tabelas com prefixo | Verifica $table_prefix e se todas as tabelas usam o mesmo prefixo |
Artigos relacionados
- Dados serializados, o que significa e porque é tão importante?
- Como fundir o site de Staging com o de produção e manter publicações e conteúdo gerado pelos utilizadores
- Actions e filtros
- Como fazer Backup do teu Theme WordPress em segurança
- Onde são guardados os produtos WooCommerce na base de dados?
- Aumentar o tamanho max_allowed_packet