Tudo o que quer saber antes de instalar.
Uma análise detalhada de como o DataFirefly Indexing API: Submissão Automática à Google Indexing API e ao IndexNow (Bing, Yandex, Naver) para PrestaShop 8 e 9 funciona, porque o construímos assim e o raciocínio por trás das funcionalidades acima.
O problema: o Googlebot e o Bingbot demoram a passar
É o ponto cego de SEO de qualquer loja em crescimento. Publica um novo produto na segunda de manhã e a Google só o indexa na quinta à noite. Corrige uma gralha numa ficha e o Bing continua a mostrar a versão antiga durante duas semanas. Durante todo esse tempo, perde tráfego orgânico, perde conversões, e os utilizadores veem informação desatualizada nos resultados de pesquisa. Numa loja que publica ou altera 20 produtos por semana, são centenas de URL em atraso de indexação a qualquer momento. O sitemap XML continua indispensável: é o canal oficial de descoberta e tem de estar limpo e atualizado. Mas não dá qualquer prioridade, e o ping clássico do sitemap deixou de servir desde que a Google removeu o seu endpoint de ping em junho de 2023. Para assinalar uma alteração em minutos em vez de dias, é preciso passar pela submissão direta.
Google Indexing API: o que faz e o que não faz
A Google expõe um endpoint REST em indexing.googleapis.com que aceita notificações de atualização ou de eliminação de URL. A autenticação é feita por conta de serviço da Google Cloud: cria uma conta de serviço, transfere a chave em formato JSON e acrescenta-a como proprietária da sua propriedade da Search Console. O módulo assina um JWT RS256 com a chave privada, troca esse JWT por um token de acesso OAuth2 em oauth2.googleapis.com, guarda esse token em cache durante 55 minutos e usa-o para autenticar cada submissão. O ponto a conhecer antes de comprar: a documentação da Google restringe oficialmente esta API a páginas com dados estruturados JobPosting, ou BroadcastEvent integrado num VideoObject. Uma ficha de produto ou uma página de categoria não se enquadra em nenhum dos casos. A API aceita na mesma a submissão e responde 200, mas esse 200 significa apenas que a notificação foi recebida: a Google continua a ser a única a decidir sobre o rastreio e a indexação. A quota predefinida é de 200 URL por dia por conta de serviço, e o aumento de quota está reservado a sites que usem efetivamente JobPosting ou BroadcastEvent, pelo que uma loja não deve contar com isso. O módulo submete, regista o código devolvido, e o painel reflete a resposta da API, não a decisão de indexação. Se procura um ganho de indexação mensurável num catálogo de produtos, é o IndexNow que o dá.
IndexNow: Bing, Yandex, Naver e Seznam numa única chamada
O IndexNow é um protocolo aberto impulsionado pelo Microsoft Bing e pelo Yandex em 2021, ao qual se juntaram depois o Naver (o motor dominante na Coreia do Sul) e o Seznam (o motor histórico na República Checa). Ao contrário da API da Google, o IndexNow não impõe qualquer restrição quanto ao tipo de página: fichas de produto, categorias e páginas CMS estão no seu âmbito normal. O princípio: gera uma chave alfanumérica, publica-a na raiz do domínio (ficheiro chave.txt) e chama o endpoint api.indexnow.org com uma lista de URL. A chamada é gratuita, ilimitada e propagada automaticamente a todos os motores participantes. Sem quotas, sem conta de serviço, sem OAuth: apenas uma chave e uma chamada HTTP. O módulo gera a chave automaticamente na instalação, propõe duas formas de a servir na raiz (reescrita no .htaccess com snippet gerado, ou ficheiro físico) e agrupa os URL em lotes de até 100 por chamada, para poupar pedidos.
Os hooks do PrestaShop escutados
O módulo liga-se aos hooks oficiais do ciclo de vida dos objetos do PrestaShop. Nos produtos: o actionProductSave é chamado na criação e em cada alteração e, se o produto estiver ativo, o URL entra em fila como URL_UPDATED, caso contrário como URL_DELETED. O actionProductDelete é chamado na eliminação definitiva, com URL_DELETED. Nas páginas CMS: actionObjectCmsAddAfter (criação), actionObjectCmsUpdateAfter (alteração) e actionObjectCmsDeleteAfter (eliminação). Nas categorias: actionCategoryAdd, actionCategoryUpdate e actionCategoryDelete, sendo a raiz das categorias (ID 1 e 2) ignorada por segurança. Cada hook constrói o URL canónico através do objeto Link oficial do PrestaShop, o que garante o respeito pelas preferências de URL amigáveis, pelos prefixos de língua e pelas regras multilingues.
A fila de espera: porquê e como
Submeter de forma síncrona em cada hook seria duplamente má ideia: a latência atrasaria a administração (a chamada à Google pode demorar 2 a 5 segundos) e uma falha da API tornaria impossível guardar o produto. Por isso, o módulo coloca cada submissão numa tabela de fila de espera persistente e um CRON processa o lote a cada poucos minutos. A desduplicação é essencial: se alterar um produto três vezes numa hora, o módulo reconhece que já existe uma tarefa para esse tuplo (loja, tipo, ID, fornecedor, ação) e limita-se a atualizar o URL e a data, em vez de criar três. O bloqueio lógico de pendente para em processamento evita o duplo tratamento se dois CRON paralelos tirarem do lote ao mesmo tempo. E cada falha incrementa um contador de tentativas, com nova tentativa automática no CRON seguinte até a um máximo configurável (5 por defeito). A partir daí, a tarefa passa a erro e mantém-se consultável no ecrã Fila de espera com a mensagem exata devolvida pela API.
O registo e o painel
Cada submissão gera uma entrada no registo: fornecedor Google ou IndexNow, tipo e ID do objeto, URL exato submetido, ação URL_UPDATED ou URL_DELETED, código HTTP devolvido, indicador de aceite ou recusado, mensagem completa de resposta e data. O ecrã Registo mostra estes dados num HelperList normal do PrestaShop, com filtros nativos (fornecedor, código HTTP, aceite), ordenação e exportação CSV. O painel agrega tudo: cinco cartões com os contadores por estado da fila, dois cartões de diagnóstico por fornecedor (conta de serviço da Google configurada ou não, chave e anfitrião do IndexNow configurados ou não), uma tabela da taxa de aceitação a 30 dias por fornecedor com cores semânticas (verde acima de 90, laranja entre 60 e 90, vermelho abaixo) e um gráfico das submissões diárias que sobrepõe o total submetido e o total aceite. Deve ser lido como um indicador de saúde técnica das chamadas à API, e não como prova de indexação.
A segurança do CRON e do ficheiro de chave
O controlador de CRON é exposto no front num URL normal do PrestaShop, mas protegido por um token aleatório de 32 carateres gerado na instalação e regenerável com um clique na configuração. Sem o token certo, o controlador devolve 403. São suportadas três ações: processar um lote da fila (a chamar a cada 5 a 15 minutos pelo CRON do seu alojamento), limpar as tarefas e registos tratados para além da retenção configurada (a chamar uma vez por dia) e servir o conteúdo do ficheiro de chave do IndexNow em text/plain para a reescrita no .htaccess (protegida pelo conhecimento prévio da chave no parâmetro k). O snippet exato de .htaccess a colar na raiz do PrestaShop é gerado automaticamente na página de Configuração com a chave atual.
Casos de utilização típicos
Loja em crescimento com 50 novos produtos por semana: o módulo coloca cada criação em fila, o CRON submete em 10 minutos, e o Bing, o Yandex, o Naver e o Seznam costumam ter em conta os novos URL nas horas seguintes. Do lado da Google, a submissão acelera a descoberta, sem garantia de resultado. Loja multilingue com catálogo de 5000 produtos: a cada alteração de ficha, os URL canónicos de todas as línguas são colocados em fila e submetidos, em todos os seus mercados em simultâneo. Loja B2B com catálogo técnico atualizado com frequência (preços, stocks, fichas técnicas): a desduplicação evita saturar as APIs em rajadas de alterações, com uma única tarefa por produto mesmo que o altere vinte vezes no mesmo dia. Retoma de SEO após uma migração: um botão Relançar todas as tarefas no ecrã Fila de espera permite voltar a submeter em massa depois de resolver um problema de configuração ou de quota.
Limites conhecidos e boas práticas
A Google reserva oficialmente a Indexing API às páginas JobPosting e BroadcastEvent, o que faz do IndexNow o canal principal do módulo para um catálogo de produtos. Ative o IndexNow em primeiro lugar e trate a Google como um bónus registado. O IndexNow não trata a ação URL_DELETED: o protocolo considera que um 404 ou 410 no URL é a forma correta de assinalar uma eliminação, pelo que o módulo ignora essas tarefas (a Google, essa, suporta esse tipo de ação). A quota da Google está limitada a 200 URL por dia por conta de serviço e, como o aumento depende da presença de marcação JobPosting ou BroadcastEvent, uma loja deve considerar esse teto definitivo: restrinja o filtro da Google às novidades, ou crie uma segunda conta de serviço com a sua própria quota. O módulo não submete as variantes dos produtos, uma vez que o URL canónico do produto principal chega, porque a Google consolida naturalmente as variantes. E a raiz das categorias (ID 1 e 2) é ignorada, para evitar submeter URL sem pertinência.
Ainda não existem avaliações.