{"id":1029,"date":"2026-10-05T11:03:43","date_gmt":"2026-10-05T11:03:43","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/plugins-de-busca-wordpress\/"},"modified":"2026-10-05T11:03:43","modified_gmt":"2026-10-05T11:03:43","slug":"plugins-de-busca-wordpress","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/plugins\/plugins-de-busca-wordpress\/","title":{"rendered":"Plugins de busca WordPress: escolher sem quebrar o site"},"content":{"rendered":"

Voc\u00ea instala um plugin de busca porque os clientes reclamam que a busca interna n\u00e3o acha nada. Duas semanas depois, o painel do WordPress demora o dobro para abrir e o banco cresceu sem explica\u00e7\u00e3o. Escolher entre os plugins de busca WordPress dispon\u00edveis n\u00e3o \u00e9 uma decis\u00e3o de funcionalidade, \u00e9 uma decis\u00e3o de arquitetura: o que funciona em um blog de 80 posts pode derrubar o admin de uma loja com 8 mil produtos.<\/p>\n

O sintoma que aparece antes da escolha<\/h2>\n

Quase sempre o pedido chega assim: “a busca do site n\u00e3o encontra os posts”. Voc\u00ea abre o campo de pesquisa, digita uma palavra que existe em tr\u00eas t\u00edtulos e recebe resultados estranhos, ou nenhum. Em sites com WooCommerce, o cen\u00e1rio \u00e9 pior: a busca padr\u00e3o do WordPress trata produto como post comum. Por isso ela retorna item esgotado, varia\u00e7\u00e3o sem pre\u00e7o e produto que voc\u00ea tirou de linha meses atr\u00e1s.<\/p>\n

O WordPress usa a tabela wp_posts<\/code> e a busca nativa por LIKE<\/code> no t\u00edtulo e no conte\u00fado. Isso significa que ela n\u00e3o entende relev\u00e2ncia, n\u00e3o entende sin\u00f4nimo e n\u00e3o entende atributo de produto. Quando o volume cresce, a consulta fica lenta. \u00c9 a\u00ed que a maioria das pessoas come\u00e7a a procurar um plugin de pesquisa WordPress.<\/p>\n

As tr\u00eas perguntas antes de instalar qualquer coisa<\/h2>\n

Antes de abrir o reposit\u00f3rio e sair testando, responda isto por escrito. A resposta define o tipo de plugin, n\u00e3o o contr\u00e1rio.<\/p>\n

    \n
  1. Quantos posts, p\u00e1ginas e produtos o site tem?<\/strong> Conte tamb\u00e9m rascunhos e lixeira. Um \u00edndice externo precisa ser reconstru\u00eddo quando esse n\u00famero muda muito.<\/li>\n
  2. A busca precisa indexar produto, CPT ou campo personalizado?<\/strong> Se sim, a busca nativa est\u00e1 fora. Voc\u00ea precisa de um plugin que aceite taxonomia, meta campo e tipo de post customizado.<\/li>\n
  3. O servidor aguenta um \u00edndice externo?<\/strong> Plugins que criam tabela pr\u00f3pria consomem disco e mem\u00f3ria. Em hospedagem compartilhada com limite baixo, o ganho de relev\u00e2ncia pode virar erro 500 no admin.<\/li>\n<\/ol>\n

    Se as tr\u00eas respostas forem “volume baixo”, “s\u00f3 post comum” e “servidor apertado”, talvez voc\u00ea n\u00e3o precise de plugin nenhum. Ajustar a busca nativa com um filtro simples costuma resolver. Por\u00e9m, quando a terceira resposta \u00e9 “n\u00e3o sei”, trate como “n\u00e3o aguenta” at\u00e9 provar o contr\u00e1rio em homologa\u00e7\u00e3o.<\/p>\n

    Como os plugins de busca WordPress se comportam conforme o volume<\/h2>\n

    \u00c9 aqui que as listas de “melhores plugins de busca” falham. Elas comparam recursos, n\u00e3o comportamento sob carga. Na pr\u00e1tica, os plugins de busca WordPress se dividem em tr\u00eas fam\u00edlias, e cada uma muda de humor conforme o site cresce.<\/p>\n\n\n\n\n\n
    Fam\u00edlia<\/th>\nComo funciona<\/th>\nO que acontece com volume alto<\/th>\n<\/tr>\n
    Ajuste da busca nativa<\/td>\nFiltra a consulta padr\u00e3o do WordPress<\/td>\nContinua leve, mas para de dar conta quando h\u00e1 CPT e atributo<\/td>\n<\/tr>\n
    \u00cdndice em tabela pr\u00f3pria<\/td>\nCria tabelas extras e reindexa\u00e7\u00e3o manual<\/td>\nRelev\u00e2ncia melhora; o banco cresce e o admin pesa<\/td>\n<\/tr>\n
    \u00cdndice externo (servi\u00e7o)<\/td>\nEnvia conte\u00fado para um servi\u00e7o de busca<\/td>\nConsulta r\u00e1pida; exige sincroniza\u00e7\u00e3o e depend\u00eancia de rede<\/td>\n<\/tr>\n<\/table>\n

    O SearchWP e o Relevanssi s\u00e3o os nomes mais citados da segunda fam\u00edlia. Os dois mudam de comportamento conforme o volume: em site pequeno, a reindexa\u00e7\u00e3o \u00e9 instant\u00e2nea e voc\u00ea esquece que existe. Em site com milhares de itens, a reindexa\u00e7\u00e3o vira uma tarefa que consome CPU, e o tempo de resposta do admin sobe enquanto ela roda. N\u00e3o \u00e9 defeito do plugin, \u00e9 o custo do \u00edndice.<\/p>\n

    J\u00e1 os servi\u00e7os externos resolvem a consulta, mas criam outro problema: o conte\u00fado precisa sair do seu servidor. Em site de cliente com dado sens\u00edvel ou contrato de privacidade, isso precisa de aprova\u00e7\u00e3o antes, n\u00e3o depois.<\/p>\n

    O caso do WooCommerce: a busca padr\u00e3o j\u00e1 erra sozinha<\/h2>\n

    Em loja virtual, a busca nativa retorna produto fora de estoque, varia\u00e7\u00e3o sem pre\u00e7o e item oculto do cat\u00e1logo. Isso n\u00e3o \u00e9 bug, \u00e9 o comportamento esperado de uma busca que n\u00e3o conhece estoque. O cliente digita o nome do produto, encontra, clica e descobre que n\u00e3o tem. A venda morre ali.<\/p>\n

    Por isso, ao avaliar um plugin de pesquisa WordPress para loja, verifique tr\u00eas coisas antes de qualquer outra: se ele filtra por stock_status<\/code>, se respeita a visibilidade do cat\u00e1logo e se indexa atributo e varia\u00e7\u00e3o. Se n\u00e3o filtrar estoque, o plugin s\u00f3 deixa a busca mais bonita, n\u00e3o mais correta.<\/p>\n

    Vale lembrar que a busca \u00e9 s\u00f3 uma parte da experi\u00eancia. Se o site tem outras decis\u00f5es de plugin pendentes, vale revisar o conjunto antes de somar mais um. Temos um artigo sobre plugins essenciais WordPress e o que instalar em cada site<\/a> que ajuda a enxergar o pacote inteiro.<\/p>\n

    A ordem de teste em homologa\u00e7\u00e3o<\/h2>\n

    Nunca ative um plugin de busca direto em produ\u00e7\u00e3o, principalmente em site de cliente. A ordem abaixo evita a maior parte dos sustos.<\/p>\n

      \n
    1. Clone o site para um ambiente de homologa\u00e7\u00e3o com o mesmo volume de conte\u00fado. Banco vazio n\u00e3o serve de teste.<\/li>\n
    2. Me\u00e7a o tempo de resposta da busca nativa antes. Use o DevTools do navegador ou o log do servidor. Guarde o n\u00famero.<\/li>\n
    3. Instale o plugin e rode a indexa\u00e7\u00e3o completa. Cronometre. Em site grande, isso pode levar horas.<\/li>\n
    4. Me\u00e7a o tempo de resposta da busca depois, com o mesmo termo de antes.<\/li>\n
    5. Abra o admin e navegue entre listas de posts e produtos. Observe se ficou mais lento.<\/li>\n
    6. Teste termos dif\u00edceis: nome de produto esgotado, sin\u00f4nimo, erro de digita\u00e7\u00e3o, termo com acento.<\/li>\n
    7. S\u00f3 ent\u00e3o replique em produ\u00e7\u00e3o, em hor\u00e1rio de baixo tr\u00e1fego.<\/li>\n<\/ol>\n

      O passo 5 \u00e9 o mais ignorado. Muita gente mede a busca e esquece o admin. Um \u00edndice grande pode deixar a tela de edi\u00e7\u00e3o de post lenta, porque o plugin tamb\u00e9m consulta o \u00edndice ali. Se o cliente passa o dia no painel, esse \u00e9 o sintoma que ele vai reclamar primeiro.<\/p>\n

      O que observar depois de ativar em v\u00e1rios sites<\/h2>\n

      Quando voc\u00ea administra uma carteira de sites, o problema deixa de ser “qual plugin escolher” e passa a ser “como saber que ele continua saud\u00e1vel”. Depois de ativar em v\u00e1rios sites ao mesmo tempo, acompanhe quatro coisas.<\/p>\n