Guia de API: GPT Image 2 vs Seedream 5.0 Pro vs FLUX.2 Pro

Esta comparação não aponta um vencedor de qualidade com base em evidências. GPT Image 2, Seedream 5.0 Pro e FLUX.2 Pro oferecem geração e edição de imagens, mas expõem identidades de modelo, regras para imagens de referência, opções de roteamento, ciclos de tarefas e dados de faturamento diferentes. Para uma integração de API, essas diferenças contratuais normalmente importam mais do que uma imagem de demonstração do fornecedor.

A escolha prática depende do fluxo de trabalho. GPT Image 2 é adequado para uma integração direta com o OpenAI Images ou para um fluxo conversacional com Responses. Seedream 5.0 Pro corresponde à rota Seedream 5 atualmente verificada na plataforma conectada, com um contrato de saída restrito e tarefas assíncronas. FLUX.2 Pro é adequado para geração e edição com várias referências nativas da BFL, com a opção de usar um endpoint fixo ou um endpoint de preview atualizado.

Este guia foi revisado em 5 de setembro de 2026. Ele usa a documentação da OpenAI para o GPT Image 2, a documentação da ByteDance e uma revisão datada do catálogo de produtos para o Seedream 5.0 Pro, além da documentação da Black Forest Labs para o FLUX.2 Pro. Nenhuma imagem gerada, tarefa paga, medição de latência ou amostra de saída é usada como evidência.

Principais conclusões

• Selecione um modelo ou endpoint exato, não um apelido de família como “GPT Image”, “Seedream 5” ou “FLUX.2”.
• GPT Image 2 oferece endpoints de geração e edição, enquanto a Responses API aceita fluxos conversacionais de imagens em várias etapas.
• A rota Seedream atualmente verificada é seedream-5.0-pro; rotas genéricas, Lite e em camadas com nomes parecidos não são modelos de API pública intercambiáveis.
• FLUX.2 Pro permite edição com várias referências e oferece tanto um endpoint fixo quanto um endpoint de preview atualizado.
• Normalize os resultados específicos de cada fornecedor por trás do seu próprio estado de tarefa, registro de proveniência e revisão de aceitação.
• Compare o custo por ativo aceito, não um preço copiado de uma página nem o custo de uma única solicitação bem-sucedida.

Neste guia

• Comparação das APIs em resumo
• Identidade dos modelos e estabilidade das rotas
• Entradas de geração e edição
• Fluxos com imagens de referência
• Tarefas síncronas e assíncronas
• Verificação de custos
• Avaliação controlada
• Limites do uso comercial
• Perguntas frequentes

Comparação das APIs em resumo

As três integrações devem ser comparadas como contratos de API, não por meio de afirmações amplas sobre qualidade artística. A tabela a seguir registra o que a documentação oficial ou a revisão datada do catálogo permite comprovar.

A OpenAI documenta gpt-image-2 como um modelo de entrada e saída de imagens disponível nos endpoints de geração e edição. A BFL descreve o FLUX.2 Pro como sua opção de geração e edição em escala de produção. A ByteDance descreve o Seedream 5.0 Pro como um modelo multimodal de geração e edição, mas os controles expostos por um produto conectado ainda precisam ser verificados de modo independente. Consulte a página do modelo da OpenAI, o lançamento do Seedream 5.0 Pro pela ByteDance e a visão geral do FLUX.2 da BFL.

Para uma seleção mais ampla voltada a equipes criativas, consulte a comparação de fluxos dos três modelos. Este artigo permanece concentrado nos contratos para desenvolvedores e nos controles operacionais.

Identidade dos modelos e estabilidade das rotas

Uma integração de produção deve armazenar a identidade exata do modelo usado em cada ativo. Os nomes de família são úteis na navegação, mas ambíguos demais para roteamento, revisão de regressão, conciliação de faturamento ou análise de incidentes.

GPT Image 2 tem um alias e um snapshot datado

A OpenAI lista gpt-image-2 como alias padrão e gpt-image-2-2026-04-21 como snapshot datado. O alias é conveniente quando a equipe quer usar a opção padrão atual do fornecedor. O snapshot datado é mais seguro quando um fluxo aprovado precisa manter o comportamento do modelo consistente entre lançamentos.

A API OpenAI Images permite que o cliente selecione diretamente o modelo GPT Image. A Responses API funciona de outro modo: o aplicativo escolhe um modelo principal compatível com a ferramenta de geração de imagens, e a ferramenta cuida da seleção do modelo de imagem subjacente. Essa distinção deve constar no registro de proveniência. “Gerado com a OpenAI” não é preciso o suficiente para reproduzir um resultado. O guia oficial de geração de imagens explica os dois caminhos de API.

Os nomes Seedream atualmente descrevem superfícies diferentes

O ID de modelo público verificado na revisão do catálogo de 5 de setembro foi seedream-5.0-pro. O contrato revisado aceitava uma saída, até 10 imagens de referência, opções de saída de 1K, 1,5K e 2K e nove proporções, incluindo auto. Ele não expunha parâmetros de seed, prompt negativo ou aprimoramento do prompt.

Não substitua essa rota silenciosamente por seedream-5.0, seedream-5.0-lite ou seedream-5.0-pro-layered. O ID genérico tinha uma página estática, mas não aparecia no catálogo de modelos em execução que foi revisado. Lite é um modelo upstream da ByteDance, mas o catálogo público revisado não o confirmou como rota ativa. A identidade em camadas pertence a um fluxo interno do estúdio, não à lista verificada de modelos públicos.

A implementação mais segura consiste em colocar seedream-5.0-pro em uma lista de permissões, validá-lo durante a implantação e falhar de maneira clara quando ele não estiver disponível. Uma substituição pelo primeiro modelo de imagem de um catálogo pode retornar uma imagem válida criada pelo modelo errado. Isso é pior do que um erro de roteamento visível porque corrompe a proveniência.

Use a página atual do produto Seedream 5.0 Pro e a referência da API do modelo como pontos de entrada legíveis, mas mantenha a validação em tempo de execução na lista de revisão da publicação.

FLUX.2 Pro separa endpoints fixos e de preview

A BFL documenta flux-2-pro como um snapshot fixo e flux-2-pro-preview como o endpoint que recebe primeiro as melhorias mais recentes. Ambos usam o mesmo contrato de API, mas não oferecem o mesmo nível de controle de mudanças.

Use o endpoint fixo para cargas de trabalho sensíveis a regressões, modelos aprovados e fluxos de clientes de longa duração. Avalie o preview em um ambiente separado, com uma suíte de testes registrada. Não permita que uma rota de preview substitua uma rota fixa por causa de uma alteração indevida da configuração.

A família FLUX.2 também inclui as variantes Max, Flex, Klein e Dev. Seus recursos e suas licenças são diferentes. Em especial, as declarações de pesos abertos para certas variantes Klein não tornam o FLUX.2 Pro um modelo de pesos abertos nem auto-hospedado. A visão geral oficial do FLUX.2 deve orientar qualquer declaração sobre toda a família.

Entradas de geração e edição

A geração e a edição precisam de validações de solicitação separadas porque uma edição envolve tanto instruções criativas quanto obrigações relacionadas aos ativos de origem. O fornecedor também pode usar outro endpoint, formato multipart, padrão de nomes para referências ou método de entrega da saída.

GPT Image 2 aceita edição direta e conversacional

A API OpenAI Images oferece um endpoint para geração e outro para edições. O endpoint de edição pode modificar uma imagem de modo parcial ou completo, e o guia oficial documenta a edição com máscara. Para gpt-image-2, as entradas de imagem são sempre processadas em alta fidelidade, portanto a API não aceita um valor de input_fidelity controlado pelo cliente.

Use a Images API quando uma solicitação deve gerar ou editar uma imagem. Use a Responses API quando o aplicativo precisa de uma conversa iterativa, de saídas anteriores no contexto ou de uma experiência em várias etapas. Os dois caminhos podem personalizar propriedades de saída, como tamanho, qualidade, formato e compactação, de acordo com o suporte atual do modelo.

Um validador de produção deve distinguir, no mínimo, estas entradas:

• solicitação de geração apenas com texto
• edição da imagem inteira
• edição com máscara
• edição iterativa que depende de uma saída anterior
• solicitação com um ou mais ativos de referência

Não deduza precisão do texto, preservação do assunto ou localidade da edição apenas pela disponibilidade do endpoint. Esses são resultados de testes de aceitação, não recursos da API.

Seedream 5.0 Pro expõe um contrato conectado mais restrito

A ByteDance documenta controles upstream do Seedream 5.0 Pro, como seleção por ponto, seleção por laço, esboços, referências de cor e material, fusão de várias imagens e separação de camadas. Uma rota pública de modelo não expõe automaticamente todos os modos de interação upstream.

Para a rota revisada, implemente apenas os parâmetros presentes no contrato conectado: prompt, URLs compatíveis de imagens de referência, uma saída, opções de resolução compatíveis e proporções compatíveis. Rejeite opções sem suporte para seed, prompt negativo, várias saídas ou aprimoramento do prompt antes de enviar uma tarefa.

Para casos de edição local e camadas editáveis, trate a ferramenta de edição local e o fluxo de camadas de imagem como superfícies de produto separadas. A presença de uma ferramenta no estúdio não comprova que seu modelo interno ou todo o conjunto de controles esteja disponível na API pública.

FLUX.2 Pro usa a mesma família de modelos para geração e edição

A BFL documenta o FLUX.2 Pro para geração de texto para imagem e edição de imagens. As solicitações de edição podem fornecer referências como input_image, input_image_2 e os campos numerados seguintes. A BFL documenta atualmente até 8 imagens de referência pela API, enquanto seu playground aceita até 10.

A API também documenta prompts estruturados, valores exatos de cor, orientação de pose e saídas de até 4 megapixels. Esses são controles compatíveis ou recursos descritos pelo fornecedor. Eles não comprovam que todo prompt preservará uma marca, renderizará um rótulo corretamente ou corresponderá a uma cor de destino depois do gerenciamento de cores posterior.

O guia oficial de edição do FLUX.2 apresenta o padrão atual de solicitação e a resposta da consulta de estado. Para conhecer a família em vez dos detalhes de implementação, consulte o guia dos modelos de imagem FLUX.

Fluxos com imagens de referência

A quantidade de referências é apenas uma restrição. Um fluxo confiável com referências também registra por que cada imagem foi fornecida, o que precisa ser preservado, quem detém seus direitos, como ela foi transformada e se o fornecedor cobra pelo processamento.

Use um manifesto de referências como este no banco de dados do seu aplicativo:

{
  "role": "product_identity",
  "asset_id": "internal-asset-id",
  "rights_record": "rights-record-id",
  "sha256": "content-hash",
  "must_preserve": ["silhouette", "label", "logo", "base_color"],
  "allowed_changes": ["background", "lighting", "camera_angle"]
}

O hash detecta uma substituição acidental. O registro de direitos vincula o upload à permissão correspondente. A lista de preservação transforma um pedido criativo vago em um contrato de aceitação.

Para GPT Image 2, confira na documentação atual de Images ou Responses o formato de entrada usado pelo caminho escolhido. Para Seedream 5.0 Pro, respeite o limite revisado de 10 URLs de referência e o contrato de uma saída. Para FLUX.2 Pro, use o limite da API da BFL, em vez de copiar para o código do servidor o limite maior do playground.

Nunca reutilize a URL temporária de saída de um fornecedor como ativo de origem permanente sem antes transferi-lo para um armazenamento controlado. O guia de edição da BFL afirma que as URLs assinadas retornadas são válidas por um período limitado. Portanto, o worker deve baixar e verificar o resultado assim que a tarefa ficar pronta.

Tarefas síncronas e assíncronas

As APIs dos fornecedores retornam resultados em ciclos diferentes. Normalize essas diferenças no aplicativo, em vez de expor três máquinas de estado separadas na interface do usuário.

Resposta direta do OpenAI Images

Uma chamada direta de geração ou edição no OpenAI Images retorna os dados da imagem no fluxo de solicitação e resposta. O aplicativo ainda pode envolver a chamada em sua própria fila para controlar concorrência, cancelamentos, novas tentativas e registros de auditoria. Essa fila, porém, pertence à sua infraestrutura e não é uma tarefa de imagem da OpenAI que precise ser consultada.

Se usar a Responses API em um fluxo com várias etapas, armazene os identificadores de resposta e conversa necessários para a implementação. Registre se a imagem veio de uma chamada direta do Images ou de uma chamada da ferramenta de geração de imagens.

Consulta de estado da rota Seedream conectada

A rota de imagens conectada é assíncrona. Envie a solicitação de geração, mantenha o taskId retornado e consulte o endpoint de tarefas documentado até o estado ficar pronto ou indicar falha. Uma atualização da página não pode apagar a identidade da tarefa.

O cliente deve usar recuo exponencial limitado com jitter, um prazo total e tratamento explícito dos estados finais. Um timeout de rede durante a consulta não prova que a geração falhou. Retome a consulta da mesma tarefa antes de considerar um novo envio, ou poderá gerar cobranças e saídas duplicadas.

Consulta pela URL retornada pela BFL

Uma solicitação de criação da BFL retorna um ID e um polling_url. Consulte essa URL até o resultado ser Ready, Error ou Failed, usando exatamente os valores finais da documentação atual. Quando estiver pronto, recupere o ativo antes que a URL assinada expire.

Não construa uma URL de consulta a partir de um caminho presumido quando a resposta já fornecer uma. Armazene juntos o ID da solicitação do fornecedor, a URL de consulta, a identidade do endpoint e o horário de envio.

Um contrato interno normalizado para tarefas

A camada adaptadora pode mapear o comportamento dos fornecedores para um único registro interno:

type ImageJobState =
  | "queued"
  | "running"
  | "ready"
  | "failed"
  | "cancelled"
  | "unknown";

interface ImageJobRecord {
  internalJobId: string;
  provider: "openai" | "seedream-route" | "bfl";
  modelIdentity: string;
  providerRequestId?: string;
  state: ImageJobState;
  submittedAt: string;
  completedAt?: string;
  inputManifestHash: string;
  outputAssetId?: string;
  billableUsage?: Record<string, number>;
  errorClass?: string;
}

Mantenha unknown separado de failed. Unknown significa que o aplicativo não consegue determinar o estado atual do fornecedor. Repetir a consulta de estado é mais seguro do que enviar uma tarefa substituta.

Como verificar custos sem publicar preços desatualizados

Não grave no código uma tabela comparativa copiada das páginas dos fornecedores. Os preços de imagens mudam, e cada fornecedor mede unidades faturáveis diferentes. Uma comparação de custos válida começa na fonte oficial de preços atual e termina no seu próprio registro de ativos aceitos.

A OpenAI documenta o faturamento do GPT Image 2 em tokens de entrada de texto, entrada de imagem, entrada em cache e saída de imagem. O uso de tokens de saída varia conforme o tamanho e a qualidade solicitados, e as solicitações de edição também incluem o custo das imagens de entrada. Consulte a página atual de preços da OpenAI e a calculadora de imagens no dia da avaliação.

A BFL documenta o faturamento do FLUX.2 por modelo e megapixels processados. As imagens de referência e a resolução de saída afetam o cálculo, com regras de arredondamento descritas na página oficial de preços da BFL. Registre a resolução usada em cada referência e saída, em vez de multiplicar um preço inicial de destaque pelo número de solicitações.

Para a rota Seedream conectada, use a área de faturamento atual disponível para a conta autorizada no momento da avaliação. Não deduza uma conversão fixa entre pontos, créditos e dólares americanos, e não trate uma linha de preço visível como prova de que uma rota com nome semelhante está disponível.

A métrica útil na produção é:

cost per accepted asset =
  (provider charges + retry charges + review labor + correction labor)
  / accepted assets

Armazene estes campos para cada solicitação avaliada:

• fonte de preços e data de consulta
• fornecedor, identidade exata do modelo e endpoint
• qualidade, dimensões e quantidade de saídas solicitadas
• quantidade de imagens de referência e dimensões processadas
• uso de texto, imagem e saída quando fornecido
• quantidade de novas tentativas e tarefas duplicadas
• cobrança do fornecedor ou débito da conta
• tempo de revisão e de correção
• resultado aceito, rejeitado ou aceito com condições

Esse método pode revelar um custo menor por ativo aceito sem fazer uma afirmação universal sobre preços. Ele também permite auditar alterações posteriores no faturamento.

Como elaborar uma avaliação controlada das APIs

Uma avaliação controlada deve testar o trabalho que o aplicativo precisa aprovar. Ela não deve começar com a suposição de que um fornecedor é melhor em retratos, texto, realismo ou seguimento de prompts.

Defina tarefas a partir de falhas de produção

Monte a suíte com entregas representativas e modos de falha conhecidos. Algumas categorias úteis são edição com preservação de produto, imagem promocional localizada, composição com várias referências, infográfico e edição local direcionada.

Para cada tarefa, defina os requisitos objetivos antes de enviar qualquer solicitação:

• texto exato e idioma
• proporção e posicionamento final
• ativos de origem e registros de direitos
• elementos que não podem mudar
• alterações permitidas ao modelo
• condições de rejeição
• correções humanas permitidas

Mantenha as evidências comparáveis

Use os mesmos ativos de origem, textos obrigatórios, objetivo de saída e critérios de revisão. A sintaxe específica do fornecedor pode variar, então converta a tarefa para os campos aceitos por cada API, em vez de impor um payload comum inválido.

Registre o prompt enviado depois de qualquer transformação específica do fornecedor. Registre identidades exatas de modelos e tipos de rota. Se uma rota mudar durante a avaliação, separe os resultados em vez de combiná-los.

Revise os resultados sem os nomes dos modelos

Quando possível, oculte a identidade do fornecedor dos revisores. Avalie defeitos objetivos separadamente das preferências estéticas. Um erro ortográfico, recurso ausente no produto, logotipo alterado ou região danificada fora da área editada não deve desaparecer na média por causa de uma nota alta de estilo.

Acompanhe aceitação na primeira tentativa, novas tentativas, tempo de revisão, tempo de correção, erros do fornecedor e custo por ativo aceito. Limite as conclusões às tarefas, entradas, datas, endpoints e condições de conta realmente testados.

Publique os limites das evidências

Um artigo pode dizer que o fornecedor documenta determinado recurso. Também pode informar um resultado observado em uma avaliação interna datada quando a metodologia e a proveniência estiverem disponíveis. Não pode transformar uma imagem sem atribuição ou um teste de prompt sem registro em um vencedor de qualidade.

Este artigo não inclui saídas de uma comparação controlada dos modelos. Portanto, não faz afirmações sobre qualidade relativa das saídas, precisão do texto, realismo de retratos, velocidade, taxa de sucesso ou confiabilidade. A coleção de prompts do GPT Image 2 pode ajudar a estruturar uma futura suíte de tarefas, mas os prompts ainda precisam de critérios de aceitação específicos para cada tarefa.

O uso comercial continua sujeito a condições

O acesso à API ou a um plano pago não libera automaticamente os direitos comerciais de todas as entradas e saídas. A elegibilidade para uso comercial depende dos termos aplicáveis da plataforma e do fornecedor, do plano da conta, dos direitos sobre as referências enviadas, do conteúdo solicitado e de direitos de propriedade intelectual ou de imagem de terceiros.

Antes de usar uma saída em publicidade, embalagens, filmes, entregas para clientes ou qualquer outro contexto comercial:

1. Consulte os termos de serviço atuais e os termos do fornecedor relevante.
2. Confirme a permissão para cada foto, logotipo, imagem pessoal, personagem, design de produto e conjunto de dados enviado.
3. Revise a saída em busca de material protegido de terceiros, afirmações enganosas, conteúdo restrito e avisos obrigatórios.
4. Preserve o prompt, o manifesto de entrada, a identidade do modelo, a data, as evidências da conta e a aprovação humana.
5. Procure uma avaliação jurídica qualificada quando a campanha, o território, o contrato ou o assunto representar um risco relevante.

A OpenAI publica termos de serviço e políticas de uso para sua API, enquanto a BFL publica termos separados para API e licenciamento. Esses documentos podem mudar, e diferentes variantes do FLUX auto-hospedadas podem ter licenças diferentes. Não copie uma conclusão de licenciamento de uma variante para outra.

O acesso pago não cria automaticamente propriedade exclusiva, não comprova ausência de infração e não autoriza o uso de todos os ativos de referência. Estas são orientações operacionais, não aconselhamento jurídico.

Perguntas frequentes

Qual é a melhor API para um novo produto de imagens?

Não existe uma API universalmente melhor. GPT Image 2 é uma opção para geração direta, edição ou um fluxo conversacional da OpenAI. Seedream 5.0 Pro é uma opção quando o contrato conectado verificado atende ao produto. FLUX.2 Pro é uma opção quando a edição nativa da BFL com várias referências e o controle de endpoint fixo atendem à arquitetura. Faça uma avaliação controlada antes de escolher o padrão.

GPT Image 2, Seedream 5.0 Pro e FLUX.2 Pro são assíncronos da mesma forma?

Não. As chamadas diretas do OpenAI Images retornam no fluxo da solicitação. A rota Seedream conectada devolve uma identidade de tarefa que precisa ser consultada. A BFL devolve um ID de solicitação e uma URL de consulta. O aplicativo deve normalizar esses ciclos, mas preservar o estado original do fornecedor e o ID da solicitação.

Posso enviar o mesmo corpo de solicitação aos três fornecedores?

Não. Os endpoints, formatos de entrada de imagens, controles de saída, limites de referências e respostas das tarefas são diferentes. Use um briefing interno neutro em relação ao fornecedor e mapeie-o por meio de um adaptador validado para cada rota de modelo exata.

O Seedream 5.0 Pro expõe todos os controles de edição descritos pela ByteDance?

Não necessariamente. A ByteDance documenta recursos upstream, enquanto um produto conectado pode expor apenas parte deles. Use somente os parâmetros do contrato público atual e trate as ferramentas exclusivas do estúdio como superfícies separadas.

Devo usar flux-2-pro ou flux-2-pro-preview?

Use flux-2-pro quando a reprodutibilidade e o controle de mudanças forem importantes. Avalie flux-2-pro-preview quando quiser as melhorias atuais e puder executar testes de regressão. Armazene o endpoint exato de cada tarefa.

Como comparar os custos da geração de imagens?

Consulte os preços oficiais atuais na data da avaliação, registre as entradas faturáveis usadas por cada fornecedor e calcule o custo por ativo aceito. Inclua tarefas com falha, duplicatas, novas tentativas, revisão humana e correções. Não compare preços de destaque que pressuponham resoluções ou regras de imagens de entrada diferentes.

As imagens geradas podem ser usadas comercialmente?

Talvez. Verifique o plano ativo da conta, os termos do serviço e do fornecedor, os direitos sobre as entradas, o conteúdo da saída e as restrições de terceiros. Apenas ter acesso pago à API não libera todos os usos comerciais.

Construa o adaptador antes de escolher um vencedor

A decisão de engenharia defensável não é “qual modelo vence?”. É “qual rota exata atende a este contrato de produto, e conseguimos comprovar isso?”.

Defina um único esquema interno de tarefas e proveniência, valide cada solicitação específica do fornecedor, preserve as identidades exatas dos modelos, recupere tarefas de estado desconhecido sem reenviá-las às cegas e concilie cobranças com os ativos aceitos. Em seguida, execute uma avaliação controlada com critérios reais de produção.

Esse processo pode selecionar rotas diferentes para edição conversacional, composição com muitas referências, edições locais e produção estável em lotes. Uma arquitetura com vários modelos só é útil quando a identidade do modelo, o estado da tarefa, o custo, as evidências e os direitos continuam visíveis desde a solicitação até o ativo aprovado.

Fontes oficiais e registro de atualização

Esta comparação foi verificada novamente em 5 de setembro de 2026. Os limites das evidências abrangem apenas contratos públicos atuais dos produtos, documentação oficial dos fornecedores e uma revisão datada do catálogo da plataforma. A disponibilidade e os preços podem mudar depois dessa data, por isso as equipes de produção devem verificá-los novamente antes de uma publicação ou decisão de custos.

• OpenAI, referência do modelo GPT Image 2, consultada em 5 de setembro de 2026.
• OpenAI, guia de geração de imagens, consultado em 5 de setembro de 2026.
• OpenAI, preços da API, consultados em 5 de setembro de 2026.
• ByteDance Seed, apresentação do Seedream 5.0 Pro, publicada em 8 de julho de 2026 e consultada em 5 de setembro de 2026.
• Black Forest Labs, visão geral do FLUX.2, consultada em 5 de setembro de 2026.
• Black Forest Labs, edição de imagens com FLUX.2, consultada em 5 de setembro de 2026.
• Black Forest Labs, preços do FLUX.2, consultados em 5 de setembro de 2026.

A equipe editorial da PixMind é responsável pela revisão do artigo. O site atual não expõe um perfil nominal de revisor técnico, então esta página não atribui uma credencial individual que não possa ser verificada. O pacote final de publicação deve verificar os metadados canônicos, a capa WebP compartilhada de 1.200 × 630 e os schemas de artigo e breadcrumb gerados pelo site antes do lançamento.