Corrigi tudo que o Google pediu e meu Merchant Center continua suspenso. O que mais eles querem?
Resposta Rápida
O modelo de rejeição do Google nunca lista o que ainda está errado, então uma loja em conformidade recebe o mesmo aviso de Misrepresentation que uma loja quebrada. A lacuna geralmente é algo que a verificação automatizada vê e você não: uma conta vinculada ou irmã, uma divergência de entidade ou identidade, um feed desatualizado, uma configuração mobile ou do lado da conta, ou um rastreamento bloqueado. Recursos às cegas queimam um recurso finito; a forma confiável de forçar uma resposta específica e fundamentada é a rota de disputa extrajudicial da UE.
Por Que "Encontramos a Mesma Violação" Não Significa Que Você Não Corrigiu Nada
O e-mail de rejeição que cita Misrepresentation de novo, com as mesmas palavras do primeiro, soa como um veredito sobre o seu trabalho: nada do que você fez importou. Essa leitura é compreensível e geralmente errada.
As respostas de recurso do Google são modelos prontos. "Misrepresentation" não é um problema específico - é uma categoria guarda-chuva que cobre dezenas de sinais distintos: identidade empresarial ausente, divergências entre feed e site, contradições entre páginas de políticas, conteúdo raso ou duplicado, histórico de conta suspeito, inconsistências no perfil de pagamentos e mais. Quando qualquer um desses sinais ainda dispara, o sistema devolve o mesmo nome de categoria que devolveu da primeira vez. O e-mail não distingue entre "todos os quinze problemas originais permanecem" e "quatorze foram corrigidos e um permanece". Ambos produzem uma mensagem idêntica.
Portanto, o mesmo texto de rejeição é compatível com três realidades muito diferentes:
- Você corrigiu a maior parte, e um ou dois problemas residuais continuam acionando a mesma categoria. Este é o caso mais comum que vemos ao auditar lojas cujos donos "corrigiram tudo".
- Você corrigiu o site, mas o gatilho nunca esteve no site. Fatores no nível da conta e da identidade, tratados abaixo, não respondem a correções no site de forma alguma.
- Seu recurso nunca foi de fato reanalisado. Recursos que voltam em minutos ou horas foram processados automaticamente, não lidos. Se isso corresponde à sua experiência, veja por que recursos são rejeitados em poucas horas.
Resumo em linguagem simples
O modelo de rejeição tem exatamente uma mensagem e a envia tanto se você corrigiu 0% quanto se corrigiu 95%. Uma rejeição idêntica não é prova de que seu trabalho foi inútil. É prova de que pelo menos um sinal - possivelmente pequeno, possivelmente um que nem está no seu site - ainda está disparando, e o Google não vai dizer qual.
A Lacuna Entre o Que Você Corrigiu e o Que o Google Realmente Verifica
Lojistas corrigem o que um cliente humano notaria: as páginas de políticas visíveis, a página de contato, as descrições de produto, os preços. Os sistemas do Google verificam algo diferente - uma versão da sua loja legível por máquina e cruzada entre fontes - e é aí que "em conformidade para um humano" e "em conformidade para o classificador" divergem silenciosamente.
Lacunas comuns que encontramos em lojas que estavam "totalmente corrigidas"
A correção existe, mas não em todos os lugares verificados
O bloco de identidade está no rodapé mas falta nas páginas de políticas, ou está no tema desktop mas não no tema mobile, ou na versão em inglês do site mas não na versão de idioma que seu feed segmenta. As verificações automatizadas rastreiam páginas e variantes específicas; uma correção que existe em uma única página não é uma correção.
O site e a conta se contradizem
O site agora mostra um prazo de devolução de 30 dias, mas a política de devolução configurada dentro do Merchant Center ainda diz 14 dias, ou mostra um prazo vazio porque a sincronização da sua plataforma o apagou. Os custos de envio no site mudaram, mas as configurações de envio na conta não. O Google compara os dois lados; corrigir só um lado preserva a divergência.
O feed ainda carrega os dados antigos
Os dados de produto são armazenados em cache e rastreados novamente no próprio cronograma. Se seu feed ainda contém preços anteriores à correção, disponibilidade desatualizada ou links de política apontando para páginas excluídas, os sistemas estão julgando a loja de ontem, não a de hoje.
O checkout conta uma história diferente da página de produto
Uma taxa de manuseio surpresa, uma troca de moeda, um custo de envio que aparece só na última etapa, uma página de pagamento em outro domínio. A simulação automatizada de checkout captura o que um clique manual rápido deixa passar.
A proteção contra bots está bloqueando a própria reverificação
Regras agressivas do Cloudflare, bloqueio geográfico ou muros anti-bot podem impedir que os rastreadores do Google vejam suas páginas corrigidas. Da perspectiva do sistema, uma página que ele não consegue carregar é uma página que não existe - a correção fica invisível.
Nada disso aparece quando você mesmo revisa seu site, porque seu site está genuinamente bem para o olhar humano. Essas lacunas só aparecem quando você audita a loja do jeito que a máquina faz: página por página, campo por campo do feed, configuração por configuração da conta. Nossa versão sistemática dessa auditoria está descrita em como corrigir uma suspensão por Misrepresentation no Merchant Center.
Quando Mais um Recurso por Conta Própria Piora, em Vez de Melhorar
O instinto natural depois de uma rejeição é recorrer de novo imediatamente - ajustar algo pequeno, reenviar, torcer. Resista. Nesta situação específica, recursos repetidos em sequência têm custos reais:
As outras rotas de fuga tentadoras são igualmente improdutivas aqui. Esperar que uma revisão travada se resolva sozinha tem seu próprio modo de fracasso, tratado em o que fazer quando seu recurso fica em análise sem resposta. E escalar para o suporte na esperança de que um humano finalmente explique os detalhes geralmente produz o mesmo modelo de resposta por um canal diferente - veja por que o suporte do Merchant Center só envia respostas copiadas e coladas.
Não recorra de novo até que algo material tenha mudado
O próximo recurso só deve sair quando você puder nomear o sinal específico que ele resolve: uma lacuna concreta encontrada em uma auditoria sistemática, um fator no nível da conta que você resolveu, ou uma evidência nova. "O site parece bem para mim" foi como o último recurso falhou. Se você não consegue dizer o que está diferente desta vez, o resultado também não será diferente.
Como Forçar uma Resposta Fundamentada em Vez de Mais um Modelo
Tudo acima ainda deixa intocada a injustiça central: você está sendo cobrado por uma lista de verificação que não tem permissão de ver. Dentro do processo interno do Google, isso não muda. Nenhum recurso, nenhum tíquete de suporte e nenhum formulário jamais obriga o Google a declarar, especificamente, o que sua loja ainda viola. O processo interno é construído de modo que o Google nunca precise fundamentar a decisão - apenas repeti-la. Uma categoria de política e um link para uma página de ajuda são toda a explicação que o sistema foi projetado para dar; a mecânica disso é tratada em o que uma suspensão por misrepresentation realmente significa.
Para lojistas estabelecidos na União Europeia, existe uma rota em que essa assimetria se inverte: escalar a suspensão para um órgão certificado de resolução extrajudicial de disputas sob a Lei de Serviços Digitais da UE (DSA). Trata-se de um procedimento formal e independente, fora dos sistemas do Google, e ele muda as regras do jogo exatamente da forma que um lojista em plena conformidade precisa:
- O Google tem que apresentar sua posição a um revisor independente. Dentro do processo interno, o modelo pronto é a resposta inteira. Em um procedimento de disputa, um nome de categoria sem fundamentação é uma fraqueza, não uma resposta. Em um dos casos que vencemos, o argumento decisivo foi precisamente que o Google não conseguiu apontar nada concreto que ainda estivesse errado.
- Suas correções documentadas finalmente são lidas. O registro de antes e depois que você construiu - cada correção, datada, com evidências - é exatamente o que um procedimento baseado em evidências recompensa e exatamente o que o pipeline automatizado de recursos ignora.
- O lojista em plena conformidade é o requerente mais forte possível. Esta rota não é uma brecha para lojas com violações ativas; uma loja genuinamente limpa, com uma trilha documentada que o comprova, é o caso de manual para ela.
É exatamente por isso que o trabalho descrito nas seções anteriores não é desperdiçado mesmo quando os recursos que ele sustentou foram rejeitados. A auditoria que descarta problemas residuais do site, a verificação de contas vinculadas e consistência da entidade, o registro datado de cada correção - tudo isso se torna o arquivo de evidências da disputa. O quadro completo de como a rota funciona, quem é elegível e como são os procedimentos está em nossa visão geral sobre a rota de recurso DSA para suspensões do Merchant Center.
Duas ressalvas honestas. Primeira: a rota está disponível apenas para negócios estabelecidos na UE. Segunda: é uma revisão genuinamente independente: se restar uma violação real ou um problema desqualificante de histórico de conta, o revisor vai encontrá-lo. É por isso que a auditoria vem primeiro - a escalada é o passo que você dá quando a auditoria diz que seu caso é forte, não um substituto para ela.
Recursos esgotados? Podemos seguir pela rota DSA a partir daqui.
Se o seu negócio está estabelecido na UE e o processo interno do Google está esgotado, nós preparamos o relatório de conformidade, implementamos as correções, compilamos toda a documentação DSA e protocolamos a disputa extrajudicial em seu nome. Para casos genuínos em que o lojista não pode arcar com o custo antecipadamente, também oferecemos a opção de taxa de êxito: você paga a taxa somente se a sua conta for reativada. Essa opção custa um pouco mais no total, mas torna realisticamente possível iniciar todo o procedimento sem pagar nada adiantado.
Conclusão
Se você realmente corrigiu tudo que o Google pediu e o modelo de resposta continua voltando, pare de adivinhar. Ou algo específico e localizável ainda está disparando - em uma página que você não verificou, em uma configuração de conta que você não tocou, ou em um histórico de conta que você não sabia que tinha - ou sua loja está limpa e o processo interno simplesmente nunca vai admitir isso. O primeiro caso se resolve com uma auditoria no nível da máquina; o segundo, para lojistas da UE, se resolve em um fórum onde o Google finalmente tem que responder com detalhes concretos em vez de um modelo pronto.