Controle de acesso no WordPress significa liberar para cada cliente só a capability que ele precisa, nunca a função Administrador inteira. Segundo a WordPress Developer Docs (2024), o núcleo define 6 funções e mais de 60 capabilities granulares. O erro comum é dar Editor onde caberia uma role customizada. Comece mapeando tarefa por tarefa antes de criar qualquer usuário.

O controle de acesso é o conjunto de regras que decide qual usuário enxerga e altera cada parte do WordPress. Em vez de entregar a senha de Administrador para o cliente mexer no próprio site, você define funções e capabilities que limitam a ação ao mínimo necessário. Isso reduz o risco de uma alteração derrubar o site e mantém o rastro de quem fez o quê. Quem cuida de vários sites precisa de controle de acesso centralizado, e é aí que a gestão de sites WordPress da FULL entra como camada acima do wp-admin. Este guia mostra o caminho do mapeamento à plataforma.

Primeiros passos: Visão geral do controle de acesso

O controle de acesso no WordPress se apoia em 2 camadas: 6 funções padrão (Administrador, Editor, Autor, Colaborador, Assinante, Super Admin no multisite) e mais de 60 capabilities que cada função carrega. A regra prática vale mais que decorar a lista: a função certa é a que falha por falta, não por excesso de poder.

A tabela abaixo resume o que cada função libera e onde ela vaza permissão demais quando entregue a um cliente sem ajuste. A maioria dos tickets de gestão que chegam ao suporte da FULL começa com um cliente que recebeu Administrador “para resolver mais rápido” e acabou alterando o que não devia. Mapeie a tarefa antes da função, porque o controle de acesso sobra quando você concede por intuição.

Por que entregar a função administrador ao cliente é o erro mais caro

Entregar a função Administrador a um cliente abre acesso às 60+ capabilities de uma vez, incluindo edit_plugins, switch_themes e delete_users. Em WordPress 6.x com o editor de arquivos habilitado, a capability edit_plugins ativa permite reescrever o functions.php direto pelo painel e derrubar o site sem deixar rastro de quem alterou.

O prejuízo não é só técnico: você perde a trilha de auditoria. Em sites com mais de 3 clientes ativos no mesmo WordPress, dar Administrador a cada um gera conflito de plugins, porque dois admins desativam extensões um do outro. A saída é uma role customizada sem manage_options somada a gestão centralizada fora do wp-admin. O controle de acesso bem feito parte da pergunta “qual a menor permissão que resolve?”, e não “qual função entrega tudo de uma vez?”. Essa inversão de pergunta é o que separa um site gerenciável de um site refém do cliente.

Passo a passo: Como configurar o controle de acesso por cliente

Configurar o controle de acesso leva 5 passos, do mapeamento de tarefas à validação em ambiente isolado. O tempo médio para um site com 2 a 3 clientes fica em torno de 30 a 40 minutos na primeira vez, e cai pela metade quando você reaproveita a role customizada em outros sites.

Faça um backup do WordPress antes de mexer em permissões, porque uma capability removida da função errada pode trancar o próprio acesso.

Passo 1: Mapeie a tarefa de cada cliente

Liste por escrito o que cada cliente precisa fazer: publicar post, editar produto, ver relatório, trocar banner. Em torno de 8 tarefas distintas cobrem a maioria dos casos de site comercial. Esse mapa vira a base das capabilities que você vai conceder. Sem ele, você concede por intuição e quase sempre concede demais.

Passo 2: Escolha entre função padrão e role customizada

Compare a tarefa mapeada com as 6 funções padrão do WordPress. Se nenhuma função encaixa sem sobra de permissão, crie uma role customizada. Um cliente que só atualiza banners não é Editor: é uma role com edit_pages e nada mais. A função padrão serve em menos da metade dos casos reais de cliente.

Passo 3: Crie a role com user role editor ou members

Instale o User Role Editor ou o plugin Members para criar a role e marcar capability por capability. Os dois listam as 60+ capabilities com checkbox. Veja o comportamento exato de cada capability na documentação oficial antes de marcar, porque o nome nem sempre revela o alcance: unfiltered_html, por exemplo, libera scripts no conteúdo.

Passo 4: Atribua a role ao usuário do cliente

Crie o usuário do WordPress do cliente e atribua a role customizada, nunca o Administrador. Confira no perfil que a função aplicada é a sua, não uma herdada. Um único usuário com função errada anula todo o controle de acesso que você desenhou nos passos anteriores.

Passo 5: Valide em staging antes de liberar

Teste a role logando como o cliente em um ambiente de staging. Verifique que ele faz a tarefa e que os menus proibidos somem. Validar em produção é arriscado: se a capability estiver larga, o cliente já enxerga o que não devia antes de você perceber.

Ferramentas de controle de acesso: O que cada uma resolve

O ecossistema de controle de acesso no WordPress tem 4 categorias de ferramenta, e escolher errado custa horas de retrabalho. Plugins de role como o User Role Editor e o Members criam e editam funções; plugins de área restrita controlam o que o cliente vê no front-end.

Plugins de segurança de login adicionam autenticação de dois fatores, e plataformas de gestão externa como o MainWP e a plataforma FULL sobem o controle de acesso para fora do wp-admin, centralizando vários sites em um painel. Para áreas restritas no front-end, vale ver o passo a passo de como criar áreas de login personalizadas. A combinação muda conforme o cenário: um único site pede plugin de role; uma carteira de clientes pede plataforma de gestão por cima do WordPress.

Controle de acesso sem entregar o wp-admin: A camada de gestão

A maior lacuna do controle de acesso nativo é que tudo vive dentro do wp-admin: para o cliente fazer qualquer coisa, ele precisa entrar no painel. Uma plataforma de gestão resolve isso colocando o acesso acima do site, liberando ações pontuais sem a senha de Administrador.

Com a gestão de sites WordPress da FULL e ferramentas como o MainWP para gerenciar vários sites, você libera tarefas como atualizar plugin, ver relatório ou publicar conteúdo aprovado sem entregar o wp-admin de cada WordPress. Isso resolve o gap que motiva boa parte dos tickets de gestão: o cliente quer autonomia, mas o controle de acesso nativo só oferece autonomia total ou nenhuma. A camada externa cria o meio-termo que o WordPress não tem nativamente, e mantém a trilha de quem fez cada ação.

Acelere a gestão de acesso de vários clientes com a FULL

Quando o controle de acesso deixa de ser 1 site e vira uma carteira, centralizar vale o investimento. O plano PRO da FULL custa R$849,90 e cobre 10 sites, o que dá R$85 por site, com os 17 plugins do bundle inclusos, incluindo os de segurança e gestão de usuários.

Em vez de licenciar User Role Editor, plugin de 2FA e ferramenta de backup site a site, você concentra tudo em um painel e gerencia o acesso de todos os clientes do mesmo lugar. A gente vê no suporte que agência que centraliza o controle de acesso para de perder tempo entrando em 10 wp-admin diferentes e reduz erro de permissão. Conheça os planos da FULL e o argumento de R$85 por site antes de licenciar plugin por plugin em cada cliente.

Perguntas frequentes sobre controle de acesso

Próximos passos para um acesso seguro por cliente

O controle de acesso por cliente bem feito é menos sobre o plugin e mais sobre o método: mapear a tarefa, conceder a menor permissão, validar em staging e centralizar quando a carteira cresce. Comece por uma role customizada em vez da função Administrador e suba para uma plataforma de gestão quando passar de um punhado de sites. Para aprofundar em funções específicas, veja o guia de como adicionar usuários com funções específicas e o de configuração de acesso de nível de autor. Quem cuida da segurança em paralelo encontra mais contexto nas 25 dicas de segurança WordPress e no guia do painel administrativo. Para continuar aprendendo WordPress, o FULL Academy reúne tutoriais, guias e reviews em um só lugar: FULL Academy.

Legenda: a tela de capabilities mostra por que o controle de acesso fino vive no nível da permissão, não da função.