# Busca vetorial no WordPress: Guia em 5 passos A busca vetorial recupera conteúdo por significado, não por palavra exata, comparando vetores numéricos. Segundo a OpenAI Platform (2024), o modelo text-embedding-3-small gera vetores de 1.536 dimensões. Cada consulta custa frações de centavo, mas exige um banco de vetores. Monte em cinco passos e meça antes de migrar. A busca vetorial no WordPress transforma cada post em um vetor numérico e responde à consulta pelo conteúdo mais próximo em significado, não pela coincidência de palavras. Isso resolve o ponto cego da busca nativa, que falha quando o leitor digita um sinônimo ou uma pergunta em vez do termo cravado no texto. Aqui você vai montar a estrutura completa em cinco passos, entender quando o ganho justifica o custo de API e ver onde a abordagem quebra em produção. O percurso vale para quem já trabalha com conteúdos de IA e WordPress da FULL e quer recuperação semântica real, sem prometer mágica. --- ## Primeiros passos: Visão geral da busca vetorial A busca vetorial no WordPress depende de três peças que conversam entre si: um modelo de embeddings, um banco de vetores e uma camada de consulta. O modelo converte cada texto em uma lista de 1.536 números, e a consulta busca os mais próximos por distância de cosseno. O banco guarda esses vetores com índice para responder rápido, e a tabela abaixo posiciona as três peças antes de você escolher o stack.
Busca vetorial no WordPress: as três peças e o que cada uma resolve
Peça Função Opção de baixo custo
Modelo de embeddingsConverte texto em vetor de 1.536 dimensõesOpenAI text-embedding-3-small
Banco de vetoresArmazena e indexa os vetores para busca rápidapgvector no PostgreSQL
Camada de consultaGera o vetor da pergunta e ordena por cossenoEndpoint na WP REST API
Entender essa divisão é o que separa um protótipo que funciona de um que cai sob tráfego, e dá para montar tudo sem licença paga para medir o ganho antes de comprometer orçamento. Para o vocabulário formal, vale revisar o conceito de embeddings antes de codar. --- ## Por que a busca vetorial supera a busca nativa do WordPress A busca nativa do WordPress roda um `LIKE %termo%` no MySQL e só encontra resultados que contêm a palavra exata digitada, ignorando sinônimos, plural e intenção. A busca vetorial resolve isso porque compara significado: a pergunta "como deixar o site rápido" recupera o artigo sobre cache mesmo sem a palavra "rápido" no texto. O ganho aparece em sites de conteúdo denso, onde a mesma ideia é descrita com palavras diferentes em dezenas de posts. Nos tickets de suporte da FULL, a queixa de "busca interna que não acha nada" é recorrente em blogs grandes, e quase sempre a causa é a limitação do `LIKE`. A busca vetorial muda o critério de coincidência de string para proximidade semântica, o que se conecta diretamente com a intenção de busca do leitor que digita. Vale lembrar que a busca vetorial não substitui o filtro por categoria ou por data: ela melhora o ranqueamento por relevância de texto, e é nesse recorte que o ganho aparece de forma consistente em blogs com muito histórico. --- ## Passo a passo: Montar a busca vetorial em 5 etapas Montar a busca vetorial exige cinco etapas em ordem: escolher o modelo, criar o banco de vetores, gerar os embeddings em fila, expor o endpoint de consulta e medir contra a busca nativa. Em uma base de 5 mil posts, o ciclo completo costuma levar de dois a quatro dias, e o gargalo quase sempre é a geração inicial dos vetores. ### Escolha o modelo de embeddings Comece pelo text-embedding-3-small da OpenAI: 1.536 dimensões, custo na casa de centavos por milhão de tokens e qualidade suficiente para conteúdo em português. Modelos maiores, como o text-embedding-3-large de 3.072 dimensões, dobram o custo de armazenamento sem ganho proporcional em busca de blog. Valide gerando o vetor de um post e conferindo se ele retorna uma lista de 1.536 números. ### Crie o banco de vetores Suba o pgvector como extensão do PostgreSQL e crie uma coluna `vector(1536)` na tabela de índice. O pgvector aceita índice HNSW, que troca um pouco de precisão por consultas abaixo de 50 ms. Valide rodando um `CREATE INDEX` HNSW e medindo o tempo de uma consulta de teste com `EXPLAIN ANALYZE`. ### Gere os embeddings em fila Nunca gere todos os vetores de uma vez: acima de 50 mil posts isso estoura o rate limit da API. Use o Action Scheduler em lotes de 100 posts e grave o vetor no postmeta para não reprocessar conteúdo que não mudou. Valide conferindo que a fila esvazia sem erro 429 da API. ### Exponha o endpoint de consulta Registre uma rota na WP REST API que receba a pergunta, gere o embedding dela e devolva os IDs mais próximos por cosseno. A doc oficial da WP REST API (developer.WordPress.org) traz o passo de `register_rest_route`. Valide chamando o endpoint com uma pergunta e conferindo a ordem dos resultados. ### Meça contra a busca nativa Antes de trocar a busca do site, rode 20 consultas reais nas duas e compare a relevância dos cinco primeiros resultados. Se a busca vetorial não ganhar em pelo menos metade dos casos, o problema está nos embeddings ou no conteúdo, não no método. Valide registrando os resultados em uma planilha antes de migrar. --- ## Quando a busca vetorial não compensa no WordPress A busca vetorial nem sempre paga o próprio custo: em sites pequenos, com menos de 200 posts e termos bem cravados, o `LIKE` nativo já entrega resultado aceitável e a API vira despesa sem retorno. O custo real não é só por consulta; é a reindexação constante e a infra do banco de vetores. A gente vê no suporte da FULL que boa parte dos sites que pedem busca "inteligente" na verdade tem problema de conteúdo mal estruturado, e nesse caso nenhum vetor resolve. O critério honesto é volume e diversidade léxica: muitos posts dizendo a mesma coisa com palavras diferentes justificam o vetor; um catálogo enxuto, não. Medir a taxa de busca sem resultado no Google Search Console ajuda a decidir com dado, não com intuição. Antes de investir, rode esse diagnóstico por um mês e veja quantas buscas internas terminam sem clique: esse número, e não a moda do momento, é o que justifica o custo recorrente de um banco de vetores. --- ## Sincronizar o vetor com a edição de conteúdo Manter o vetor sincronizado com o conteúdo é o ponto que mais quebra em produção: um post editado sem reindexação serve um vetor desatualizado e devolve resultado errado sem avisar ninguém. A correção é amarrar a regeneração ao hook `save_post`, com uma guarda de hash do conteúdo no postmeta. Sem essa guarda, cada salvamento de rascunho dispara uma chamada de API paga à toa, já que o `save_post` roda em todo update. Em bases ativas, agendar a reindexação via Action Scheduler em vez de rodar no próprio hook evita travar a tela do editor. Esse cuidado de ciclo de vida é o mesmo rigor que se aplica a Core Web Vitals no WordPress: o ganho técnico só vale se for sustentável no dia a dia. Outra guarda útil é versionar o nome do modelo no postmeta: quando você troca o text-embedding-3-small por outro modelo, os vetores antigos ficam incompatíveis, e marcar a versão evita comparar embeddings gerados por modelos diferentes. --- ## Stack e custo: Quanto custa rodar busca vetorial Rodar busca vetorial cobra em dois lugares: a geração de embeddings, uma vez por post mais as edições, e a infra do banco de vetores. Para um site de 5 mil posts, gerar os vetores iniciais com o text-embedding-3-small custa poucos dólares no total, já que o preço é por token e posts de blog são curtos. O peso recorrente é o banco: pgvector roda na sua própria infra sem licença, enquanto Pinecone e Weaviate cobram por volume gerenciado. A escolha entre eles é de posicionamento, não de "melhor": pgvector compete por custo zero de infra e proximidade do dado; Pinecone compete por escala gerenciada; Weaviate compete por busca híbrida nativa. Para priorizar o conteúdo a indexar primeiro, o Semrush para análise de SEO aponta as páginas com mais demanda. Some o custo de API ao custo de infra e compare com o ganho de retenção: se a busca melhor não segura o leitor por mais tempo, o investimento não se paga. --- ## Ative a busca vetorial com o stack que a FULL já entrega Montar busca vetorial é trabalho de integração, mas o substrato é um WordPress bem servido de plugins premium, e é aí que o bundle da FULL muda a conta. O plano PRO da FULL custa R$849,90 por mês para dez sites, o que dá R$85 por site com 17 plugins premium inclusos, entre eles o Rank Math PRO e o WP Rocket que sustentam a camada de SEO e performance ao redor da busca. A gente vê no suporte da FULL que quem tenta licenciar cada plugin avulso para um projeto de IA gasta mais só nas licenças do que no R$85 por site do bundle. Conheça os planos em FULL.services/planos e libere o stack antes de investir no banco de vetores. Para o lado de visibilidade em motores generativos, vale gerar e publicar seu arquivo com a ferramenta de llms.txt e revisar como a IA generativa no WordPress consome esse conteúdo. --- ---

Perguntas frequentes sobre busca vetorial no WordPress

Por que a busca vetorial entende sinônimos que a busca nativa do WordPress ignora?

Porque ela compara significado, não texto. A busca nativa roda um LIKE no MySQL e exige a palavra exata; a busca vetorial converte pergunta e posts em vetores de 1.536 dimensões e mede a distância de cosseno entre eles. Assim "site lento" recupera o artigo sobre cache mesmo sem a palavra "lento", já que os dois conceitos ficam próximos no espaço vetorial gerado pelos embeddings.

É possível ter busca vetorial no WordPress sem pagar API externa?

Sim. Você pode rodar um modelo de embeddings open source localmente, como os da Hugging Face, e usar o pgvector no PostgreSQL como banco de vetores, sem nenhuma licença ou custo por consulta. A contrapartida é infra: gerar embeddings na sua máquina exige CPU ou GPU dedicada, e a qualidade tende a ficar abaixo do text-embedding-3-small da OpenAI em conteúdo curto em português.

Qual a diferença entre busca vetorial e busca por palavra-chave no WordPress?

A busca por palavra-chave casa strings: encontra só o que contém o termo digitado. A busca vetorial casa significado: ordena os resultados pela proximidade semântica medida em distância de cosseno entre vetores. Na prática, a palavra-chave é precisa para termos técnicos cravados, e a vetorial ganha quando o leitor pergunta com outras palavras. Muitos projetos combinam as duas em busca híbrida.

Quanto custa gerar embeddings para um site WordPress com 5 mil posts?

Pouco, na geração inicial. O text-embedding-3-small cobra por token, e posts de blog são curtos, então 5 mil posts custam alguns dólares no total de uma vez. O peso recorrente vem das edições, que disparam regeneração, e da infra do banco de vetores. Por isso a guarda de hash no save_post importa: ela evita pagar de novo por conteúdo que não mudou de fato.

O que é um banco de vetores e por que ele precisa de índice HNSW?

Um banco de vetores armazena os embeddings e busca os mais próximos de uma consulta. Sem índice, ele compara a pergunta com todos os vetores, o que fica lento acima de dezenas de milhares de registros. O índice HNSW monta um grafo navegável que troca um pouco de precisão por velocidade, entregando consultas abaixo de 50 ms. O pgvector e o Weaviate suportam HNSW nativamente.

--- ## Próximos passos para implementar a busca vetorial A busca vetorial no WordPress deixou de ser experimento de laboratório e virou uma camada viável para sites de conteúdo denso, desde que você meça o ganho antes de migrar e mantenha o vetor sincronizado com a edição. Comece pequeno: indexe os 200 posts de maior tráfego, exponha o endpoint na WP REST API e compare com a busca nativa em consultas reais. O custo de API é baixo; o custo escondido está na reindexação e na infra do banco de vetores. Se a relevância subir nos seus testes, escale a fila e o índice com calma. Para continuar aprendendo, o FULL Academy reúne os tutoriais, guias e reviews de WordPress em um só lugar, e o guia de tráfego orgânico com Rank Math mostra como transformar a busca melhor em retenção.

Legenda: o fluxo mostra como a pergunta vira vetor e retorna os posts mais próximos por cosseno, o que comprova a recuperação por significado.