Desativação do XML-RPC do WordPress: O Caminho Mais Rápido para Evitar Ataques de Força Bruta

A desativação do XML-RPC do WordPress é o processo de impedir que o arquivo xmlrpc.php do seu site receba solicitações remotas, reduzindo rapidamente as tentativas de força bruta, abusos de pingback e tráfego desnecessário de bots. Se você não estiver utilizando o Jetpack, o aplicativo móvel do WordPress, ferramentas antigas de publicação remota ou uma integração personalizada que utilize XML-RPC, desativar o XML-RPC é uma etapa de segurança segura e prática para a maioria dos sites WordPress. O método mais eficaz é bloquear a solicitação no nível do servidor antes que o WordPress seja carregado; ou seja, cortar o acesso ao xmlrpc.php por meio de regras do Apache, LiteSpeed, Nginx ou WAF geralmente é mais eficiente do que desativá-lo por meio de plugins.

Neste guia, você encontrará passo a passo por que deve desativar o XML-RPC do WordPress, em quais situações é melhor mantê-lo ativo e como implementá-lo com segurança em diferentes ambientes de servidor. Não importa se você está operando na infraestrutura da Hostragons ou em outro ambiente de hospedagem; o objetivo é reduzir a superfície de ataque sem comprometer o seu site, diminuir o consumo desnecessário de recursos e estabelecer um padrão de segurança gerenciável. Se você está em busca de uma base rápida e segura para hospedar seu site WordPress, a escolha de Hospedagem WordPress também é uma parte importante desse processo.

O Que é XML-RPC e Qual a Sua Função no WordPress?

XML-RPC é um antigo protocolo de comunicação remota que permite que sistemas diferentes se comuniquem enviando dados em formato XML sobre HTTP. No WordPress, essa funcionalidade geralmente é gerenciada através do arquivo xmlrpc.php localizado no diretório raiz. Historicamente, este arquivo foi utilizado para publicar posts através do aplicativo móvel do WordPress, gerenciar comentários remotamente, pingbacks e interações de alguns serviços de terceiros com o site.

No ecossistema moderno do WordPress, a REST API se tornou muito mais comum, diminuindo a importância do XML-RPC. No entanto, o arquivo ainda está acessível em muitas instalações. Isso significa que, para os atacantes, ele é facilmente descoberto, tem um caminho padrão e pode ser alvo de automação. Bots que varrem faixas de IP aleatórias podem tentar acessar o xmlrpc.php em minutos, mesmo que seu domínio tenha sido recém-registrado. Portanto, ao lançar um novo domínio, é importante considerar a segurança desde o início com Consulta de domínio.

Quando o XML-RPC Pode Ser Necessário?

O XML-RPC não é desnecessário para todos os sites. Algumas funcionalidades antigas do Jetpack, certas operações do aplicativo móvel do WordPress, alguns serviços de automação ou editores de blog de desktop mais antigos podem precisar do XML-RPC. Além disso, integrações personalizadas podem usar xmlrpc.php para enviar conteúdo ou receber dados remotamente. Portanto, é importante verificar o fluxo de trabalho do seu site antes de desativá-lo.

Um controle prático é: se você insere conteúdo apenas pelo painel wp-admin, não usa o Jetpack, não publica via aplicativo móvel e seu desenvolvedor não configurou uma integração personalizada com XML-RPC, é muito provável que você não precise do XML-RPC. A maioria de sites institucionais, blogs, sites de catálogo, sites de pequenas empresas e lojas WooCommerce funcionam perfeitamente com o XML-RPC desativado. No entanto, se você tiver processos críticos, como pagamentos e integrações de envio com WooCommerce, é melhor testar a mudança em horários de baixo tráfego.

Por Que o XML-RPC É Um Risco Para Ataques de Força Bruta?

Um ataque de força bruta consiste em tentativas repetidas de combinações de nome de usuário e senha usando ferramentas automáticas. No WordPress, essas tentativas geralmente ocorrem através do wp-login.php; no entanto, o XML-RPC pode oferecer um caminho mais vantajoso para os atacantes. Isso porque alguns métodos do XML-RPC permitem várias tentativas de login em uma única solicitação HTTP. Em particular, o recurso system.multicall pode ajudar a realizar centenas de tentativas em sistemas mal configurados com menos solicitações visíveis.

Por exemplo, fazer 500 tentativas de senha via wp-login.php aparece como 500 solicitações separadas, enquanto as mesmas tentativas via XML-RPC podem ser enviadas em um número menor de pacotes. Isso pode fazer com que plugins de segurança e simples monitoramentos de logs detectem a ataque tarde demais. O resultado é um aumento no uso da CPU, ocupação dos processos PHP, sobrecarga do banco de dados com consultas desnecessárias e respostas mais lentas para visitantes reais. Em ambientes de hospedagem compartilhada, isso se torna não apenas um risco de segurança, mas também um problema de desempenho e uso de recursos.

Outra área de risco do XML-RPC é o abuso de pingback. O mecanismo de pingback foi projetado para notificar que outro site linkou para seu conteúdo; no entanto, pode ser usado para gerar tráfego semelhante a DDoS ou apontar sites de terceiros como alvo. Portanto, desativar o XML-RPC não apenas reduz as tentativas de login, mas também diminui a probabilidade de abusos originados por pingbacks.

Decisão de Desativar o XML-RPC: Tabela de Comparação Rápida

Como pode ser visto na tabela, o caminho mais curto e eficaz, se você não precisa do XML-RPC, é desativá-lo no nível do servidor ou do WAF. Usar um plugin é fácil; no entanto, se a solicitação de ataque chegar até o PHP, o consumo de recursos continuará. Portanto, em sites com alto tráfego, voltados para e-commerce ou que já estão sendo atacados, a prioridade deve ser a regra do servidor web.

Lista de Verificação Antes de Começar

Ao configurar a segurança, o princípio básico é medir primeiro e preparar um plano de retorno. O processo de desativação do XML-RPC geralmente é sem riscos; no entanto, nenhuma alteração deve ser feita cegamente em um site ao vivo. A lista de verificação abaixo ajuda a reduzir a probabilidade de erros durante a implementação.

• Tenha um backup do arquivo e do banco de dados funcionando realizado nas últimas 24 horas. É obrigatório considerar um backup antes de atualizar o WordPress, fazer ajustes de segurança ou alterar plugins.
• Verifique se você está usando o Jetpack, o aplicativo móvel do WordPress, uma ferramenta de publicação remota ou uma integração personalizada.
• Examine o número de solicitações xmlrpc.php nos logs de acesso. Se você ver dezenas ou centenas de solicitações por minuto, pode estar sob ataque.
• Faça a alteração em horários de baixo tráfego. Teste o fluxo de carrinho, pagamento e associação especialmente em lojas WooCommerce posteriormente.
• Defina um método de reversão. Tenha acesso ao gerenciador de arquivos, FTP ou SSH para comentar ou excluir a regra que você adicionou.

Um ambiente de hospedagem profissional com backups regulares, versão atual do PHP, estrutura de contas isoladas e suporte a firewall faz uma grande diferença. Para questões relacionadas à escolha de infraestrutura, você pode consultar Hosting Web Seguro e para a segurança geral do site, links para certificado SSL também podem ser incluídos.

Método 1: Desativação do XML-RPC Com .htaccess em Apache ou LiteSpeed

O método mais comum para sites WordPress que utilizam Apache e LiteSpeed é adicionar uma regra no arquivo .htaccess no diretório raiz do site para bloquear o acesso a xmlrpc.php. Como o LiteSpeed suporta regras .htaccess compatíveis com Apache, esse método pode ser aplicado diretamente na maioria dos ambientes de hospedagem. A maior vantagem é que a solicitação é rejeitada antes que o núcleo do WordPress seja executado.

Implementação Passo a Passo

• Acesse o gerenciador de arquivos a partir do painel de controle de hospedagem ou conecte-se ao diretório public_html via FTP.
• Localize o arquivo .htaccess e faça um backup dele em seu computador. Se o arquivo não estiver visível, ative a opção para mostrar arquivos ocultos.
• Sem apagar as regras geradas pelo WordPress, adicione a regra de bloqueio do XML-RPC ao topo do arquivo.
• A lógica da regra deve ser a seguinte: rejeitar todos os acessos ao arquivo xmlrpc.php.
• Salve as alterações e verifique no navegador se o endereço seu-dominio.com/xmlrpc.php está acessível.

No Apache 2.4 e em ambientes LiteSpeed, a lógica que você usará é a seguinte: deve-se definir Require all denied para o arquivo xmlrpc.php. Em ambientes mais antigos do Apache 2.2, pode-se ver a abordagem Deny from all; no entanto, é recomendável utilizar software de servidor atualizado em 2026. Se você ainda estiver trabalhando com uma versão antiga do Apache, isso deve ser uma preocupação que precisa ser abordada, não só em relação ao XML-RPC, mas em termos de segurança geral.

Em um bloqueio bem-sucedido, o endereço xmlrpc.php deve retornar uma resposta de 403 Forbidden, 404 Not Found ou uma mensagem similar conforme sua configuração de servidor. O importante é que a página não retorne uma resposta como XML-RPC server accepts POST requests. Se essa expressão aparecer, o arquivo ainda está acessível.

Método 2: Bloqueio de Acesso ao XML-RPC no Nginx

No Nginx, .htaccess não funciona, pois o Nginx não lê arquivos .htaccess baseados em diretórios. Portanto, a regra deve ser adicionada à configuração do bloco do servidor do site. Se você estiver usando hospedagem gerenciada, essa área pode não estar diretamente aberta para você; nesse caso, você pode solicitar à equipe de suporte da hospedagem que desative o acesso ao xmlrpc.php.

No Nginx, a abordagem básica é rejeitar a solicitação ou retornar 404 com o bloco location = /xmlrpc.php. Para segurança, pode-se optar por proibir explicitamente com 403 ou mostrar como se o arquivo não existisse com 404. A abordagem 404 é preferida por administradores que desejam fornecer menos informações para bots. Após adicionar a regra, a configuração do Nginx deve ser testada e o serviço deve ser recarregado. Como um caractere incorreto pode impedir que todo o site seja acessível, esse processo deve ser feito com cuidado.

Em servidores VPS ou dedicados que utilizam Nginx, é útil monitorar os logs de acesso após a alteração. Você deve ver que as solicitações ao xmlrpc.php agora resultam em 403 ou 404. Se tentativas intensas continuarem a vir do mesmo IP, pode-se adicionar uma defesa em segundo nível com fail2ban, rate limit ou uma regra do WAF. Para guias mais abrangentes sobre gestão de servidores, você pode considerar o conteúdo em segurança do servidor VPS.

Método 3: Desativação do XML-RPC com Plugin de Segurança

Para usuários que não desejam editar arquivos técnicos, plugins de segurança são uma solução prática. Plugins como Wordfence, Solid Security e All-In-One Security podem ter opções para desativar o XML-RPC, bloquear pingbacks ou impedir tentativas de login via XML-RPC. Esse método oferece um bom começo rápido, especialmente para blogs pequenos e sites corporativos básicos.

No entanto, é importante conhecer os limites da abordagem com plugins. Se o plugin bloquear a solicitação apenas depois que o WordPress tenha sido carregado, isso significa que o atacante pode ainda acionar o processo PHP. Isso implica que, em ataques intensos, o consumo de CPU e memória não será totalmente interrompido. Portanto, desativar via plugin é muito melhor do que não tomar nenhuma medida; no entanto, em sites sob ataque, deve ser apoiado por uma camada de servidor ou WAF.

Pontos de Atenção ao Usar Plugins

• Baixe o plugin de segurança apenas do diretório oficial de plugins do WordPress ou do site oficial do fabricante.
• Evite plugins que não são atualizados há muito tempo. Manutenção ativa e compatibilidade em 2026 são um sinal de segurança importante.
• Não use múltiplos plugins de segurança para a mesma função, pois conflitos podem causar problemas de login, cache e acesso a arquivos.
• Após ajustar as configurações do XML-RPC, teste a saúde do site, formulários, login de usuários e fluxo de pagamento.
• Revise os logs do plugin regularmente. Se você notar tentativas de ataque persistentes, adicione bloqueios baseados em IP ou uma regra do WAF.

Método 4: Bloqueio com WAF, CDN e Firewall de Segurança de Hospedagem

O Firewall de Aplicações Web, ou WAF, é uma das camadas mais eficazes para filtrar solicitações maliciosas antes que elas alcancem a aplicação. Soluções baseadas em CDN, como Cloudflare, podem bloquear solicitações ao xmlrpc.php antes que elas cheguem ao servidor. O ModSecurity ou regras personalizadas de WAF fornecidas pelo seu provedor de hospedagem funcionam de maneira semelhante. Essa camada é valiosa para interromper um grande número de solicitações de bots antes que elas alcancem o WordPress.

A regra do WAF deve ser clara: se o caminho URI contiver xmlrpc.php, bloqueie a solicitação ou aplique um desafio. Se você não precisar do XML-RPC, o bloqueio é mais direto. Se houver necessidade parcial, pode-se permitir apenas endereços IP específicos. Por exemplo, se um serviço de automação vem de um IP fixo, esse IP pode ser colocado na lista branca e todas as outras solicitações ao xmlrpc.php podem ser rejeitadas. Este método é um equilíbrio entre segurança e continuidade dos negócios.

A camada WAF se torna ainda mais significativa quando utilizada com SSL. Sites que não utilizam HTTPS têm credenciais de login e segurança de sessão em risco. Portanto, além de desativar o XML-RPC, é necessário operar todo o site via HTTPS, considerar cabeçalhos como HSTS e monitorar a validade do certificado. Neste ponto, os tópicos certificado SSL e Instalação de SSL Gratuita podem ser utilizados como conteúdos de suporte naturais.

Como Testar Após Desativar o XML-RPC?

Após a alteração, o único ponto a verificar não é apenas se o site está acessível. Devem ser feitos controles como: o XML-RPC está realmente desativado? O sistema de login está funcionando sem problemas? As operações de usuários reais foram afetadas? Os logs mostram os resultados esperados? O fluxo de teste a seguir fornece uma validação prática e suficiente.

• Acesse seu-dominio.com/xmlrpc.php no navegador. Espera-se que você receba uma rejeição de acesso, 404 ou uma resposta vazia. O texto XML-RPC server accepts POST requests não deve aparecer.
• Entre no painel de administração do WordPress com suas credenciais normais. Confirme que a página de login funciona independentemente do XML-RPC.
• Teste o formulário de contato, formulário de comentários, o login de usuários e as etapas de pagamento do WooCommerce.
• Verifique nos logs de acesso do servidor qual código de status está retornando para as solicitações ao xmlrpc.php. Respostas de 403 ou 404 indicam que a regra correta está em funcionamento.
• Se você tiver um plugin de segurança, revise os logs de eventos. Você deve observar que tentativas de bots antigos diminuíram ou foram bloqueadas.

Para um teste mais técnico, uma solicitação POST pode ser enviada a partir do terminal; no entanto, para a maioria dos proprietários de sites, a verificação pelo navegador e controle dos logs é suficiente. Se, após a alteração, a conexão com o Jetpack for interrompida, o aplicativo móvel não puder publicar ou uma integração falhar, isso indicará que realmente há necessidade do XML-RPC. Nesse caso, em vez de uma desativação total, deve-se considerar uma abordagem de permissão baseada em IP ou estratégia de rate limit.

Desativar XML-RPC É Suficiente? Medidas de Segurança Adicionais

A desativação do XML-RPC é um passo rápido e eficaz contra ataques de força bruta; no entanto, por si só, não garante segurança total. Atacantes ainda podem tentar através do wp-login.php, REST API, plugins vulneráveis, temas desatualizados ou senhas vazadas. Portanto, após desativar o XML-RPC, é necessário pensar na segurança do WordPress de forma em camadas.

Medidas Básicas a Serem Implementadas

• Utilize senhas fortes e nomes de usuário únicos. Não usar o nome de usuário admin ainda é uma medida simples, mas eficaz.
• Adicione autenticação de dois fatores. O 2FA em contas administrativas reduz significativamente o risco de vazamento de senhas.
• Implemente um limite de tentativas de login. Utilize rate limit para wp-login.php ou um plugin de segurança.
• Mantenha o núcleo do WordPress, plugins e temas atualizados. Plugins desatualizados são uma das causas mais comuns de violações no mundo real.
• Delete plugins e temas que você não está usando. Plugins antigos, mesmo que inativos, podem apresentar riscos ao sistema de arquivos.
• Verifique as permissões de arquivo. Permissões de gravação desnecessárias aumentam o risco de upload de arquivos maliciosos.
• Realize backups regulares e teste a recuperação. Um backup é apenas uma suposição até que seja testado.
• Utilize uma infraestrutura de hospedagem confiável. Isolamento, PHP atualizado, WAF e suporte a backups reduzem o impacto de ataques.

Por exemplo, se você desativar apenas o XML-RPC e deixar a senha do administrador como 123456, a parte mais fraca da cadeia de segurança ainda estará exposta. Por outro lado, uma senha forte, 2FA, software atualizado, WAF e hospedagem segura utilizados em conjunto podem neutralizar a maior parte dos ataques de bots comuns. Essa abordagem também é importante para SEO em 2026, pois sites com segurança fraca podem sofrer com redirecionamentos maliciosos, geração de páginas de spam e poluição de índices, perdendo assim visibilidade orgânica.

O Impacto da Desativação do XML-RPC em Performance e SEO

Os ataques XML-RPC não são diretamente um fator de classificação; no entanto, seus efeitos indiretos são significativos. Se o tráfego intenso de bots consumir recursos do servidor, os tempos de resposta das páginas aumentam, os valores do Core Web Vitals podem ser prejudicados e a experiência do usuário real pode decair. Além disso, sites que frequentemente atingem limites de recursos podem enfrentar erros 500, problemas de timeout e interrupções. O Googlebot também pode ser mais cauteloso ao rastrear páginas lentas ou com erros.

Vamos pensar em um exemplo: normalmente, sua página inicial carrega com um tempo de resposta do servidor de 300 ms; mas se o xmlrpc.php receber 1000 solicitações por minuto, os processos PHP ficam sobrecarregados e o tempo de resposta pode ultrapassar 2 segundos. Do lado do usuário, a página fica lenta, a taxa de conversão diminui e as estatísticas de rastreamento no Google Search Console podem oscilar. Desativar o XML-RPC no nível do servidor ajuda a eliminar essa carga desnecessária antes que ela chegue à camada da aplicação, contribuindo para a estabilidade do desempenho.

Em termos de SEO, um site seguro e rápido baseia-se tanto na qualidade do conteúdo quanto na infraestrutura técnica. HTTPS, PHP atualizado, disco rápido, cache correto, estrutura de tema limpa e redução da superfície de ataque devem ser considerados em conjunto. Portanto, as configurações de segurança do WordPress não devem ser apenas uma preocupação dos administradores de sistema, mas também das equipes de SEO e conteúdo. O blog da Hostragons pode apoiar esse tópico com conteúdos sobre Otimização de velocidade WordPress e lista de verificação de SEO técnico.

Se Você Não Puder Desativar o XML-RPC, Quais Estratégiass Alternativas?

Em alguns projetos, o XML-RPC não pode ser totalmente desativado. Por exemplo, um fluxo de publicação móvel específico, automações corporativas ou integrações antigas podem ainda depender desse protocolo. Nesse caso, o objetivo não é deixar a porta totalmente aberta, mas sim controlar o acesso. A primeira opção é a lista branca de IPs. O acesso ao XML-RPC é concedido apenas a endereços IP de serviços confiáveis; todas as outras solicitações são bloqueadas.

A segunda opção é aplicar rate limit. Impede que um determinado IP envie muitas solicitações ao xmlrpc.php em um curto período. Esse método não é tão definitivo quanto a desativação total; no entanto, reduz o volume de ataque em sites que precisam dessa funcionalidade. A terceira opção consiste em desativar os métodos de pingback e permitir apenas os métodos necessários. Isso requer uma configuração mais avançada e deve ser implementado sob controle do desenvolvedor.

A quarta opção é associar o acesso ao XML-RPC a uma camada de segurança separada. Por exemplo, pode ser solicitado autenticação básica HTTP, VPN, restrição de IP corporativo ou um desafio do WAF para uma verificação adicional. Essas abordagens ajudam a reduzir o risco da interface pública. Ainda assim, sempre que possível, a solução de longo prazo deve ser migrar integrações antigas para métodos mais modernos e controláveis, como a REST API.

Roteiro Prático para Usuários da Hostragons

Se você é proprietário de um site hospedado na Hostragons com WordPress, comece analisando suas necessidades de segurança do XML-RPC, em seguida, escolha o método mais simples. Em pacotes de hospedagem compartilhada ou hospedagem WordPress, editar o .htaccess pelo gerenciador de arquivos pode ser suficiente para a maioria dos usuários. Se você estiver usando VPS ou servidor dedicado, pode planejar as camadas de Nginx, Apache, LiteSpeed e WAF juntas.

A ordem de implementação pode ser a seguinte: primeiro, faça um backup; depois, verifique os serviços que usam XML-RPC; em seguida, desative no nível do servidor, complete os testes e monitore os logs por 24 horas. Se as tentativas de ataque continuarem, adicione regras do WAF, bloqueio de IP e limite de tentativas de login. Na última etapa, finalize ajustes gerais de segurança, como 2FA, política de atualizações, backups regulares e SSL.

Esse processo não é uma melhoria focada em vendas, mas um passo básico de higiene. No entanto, se sua infraestrutura estiver constantemente apresentando problemas devido a versões antigas do PHP, recursos insuficientes ou falta de firewall, pode ser sensato considerar um plano de hospedagem mais atualizado. Um ambiente otimizado para WordPress, com camadas de segurança, não só oferece resistência durante ataques, mas também melhora o desempenho diário. Nesse contexto, as páginas Hospedagem WordPress, servidor em nuvem e certificado SSL proporcionam direcionamento natural para o leitor.

Perguntas Frequentes

Desativar o XML-RPC do WordPress vai quebrar meu site?

Na maioria dos sites WordPress padrão, desativar o XML-RPC não quebrará o site. O painel de administração, tema, conteúdo, formulários e a parte dos visitantes geralmente não são afetados. No entanto, se você estiver usando o Jetpack, o aplicativo móvel do WordPress ou integrações personalizadas que utilizem XML-RPC, pode haver problemas de conexão. Portanto, é importante verificar a necessidade de uso antes de desativar e testar as funções básicas depois.

Como posso saber se o XML-RPC está desativado?

Abra seu-dominio.com/xmlrpc.php no navegador. Se você visualizar uma mensagem como XML-RPC server accepts POST requests, o arquivo está acessível. Se você receber 403, 404 ou uma rejeição de acesso, a regra de desativação provavelmente está funcionando. Para um controle mais preciso, você pode verificar os logs de acesso do servidor para ver qual código de status está retornando para as solicitações ao xmlrpc.php.

Desativar o XML-RPC interrompe completamente os ataques de força bruta?

Desativar o XML-RPC interrompe significativamente as tentativas de força bruta originadas desse protocolo; no entanto, não elimina todos os riscos de força bruta. Atacantes ainda podem continuar a realizar tentativas através do wp-login.php. Portanto, a desativação do XML-RPC deve ser acompanhada por senhas fortes, autenticação de dois fatores, limites de tentativas de login, WAF e políticas de plugins atualizados.

Se eu usar o Jetpack, devo desativar o XML-RPC?

Algumas funcionalidades do Jetpack podem precisar da conexão XML-RPC. Se você estiver usando o Jetpack, verifique quais módulos está utilizando antes de desativar completamente o XML-RPC. Como alternativa, permitir apenas os endereços IP dos serviços do Jetpack e bloquear todas as outras solicitações xmlrpc.php ou definir acessos controlados no WAF pode ser mais apropriado.

É melhor desativar pelo plugin ou pelo servidor?

Para melhor performance e segurança, desativar no nível do servidor ou do WAF é mais eficaz; pois a solicitação é rejeitada antes que o WordPress e o PHP sejam carregados. Desativar por meio de plugin é mais fácil para usuários com menos conhecimento técnico, mas não pode impedir completamente o consumo de recursos em ataques intensos. Sempre que possível, a regra do servidor deve ser a primeira escolha; caso contrário, um plugin confiável e suporte do WAF devem ser considerados.

Resumo Rápido e Próximos Passos

A desativação do XML-RPC do WordPress é uma das maneiras mais rápidas de reduzir ataques de força bruta, abusos de pingback e tráfego desnecessário de bots em sites que não precisam desse recurso. A abordagem mais robusta é bloquear o acesso ao xmlrpc.php no nível do servidor ou do WAF, e em seguida, criar uma camada de proteção com segurança de login, 2FA, atualizações, SSL e backups regulares. Se você deseja revisar a infraestrutura do seu site, pode conferir as soluções de hospedagem e segurança voltadas para WordPress da Hostragons; e hoje mesmo dar o primeiro passo com uma pequena lista de verificação para o seu site.