Site no ar faz três semanas, o Search Console só devolve página não indexada e a sensação é de que o Google esqueceu de você. Vá em Configurações > Leitura e olhe a caixinha de sugerir aos mecanismos de busca que não indexem este site. Ela costuma ficar marcada desde a homologação e ninguém desmarca no dia da virada.
Confirme pelo terminal, não pelo olho
Essa caixinha grava a opção blog_public: zero significa bloqueado. Dá pra ler, corrigir e conferir em quatro comandos:
sudo -u www-data wp option get blog_public
sudo -u www-data wp option update blog_public 1
curl -s https://seusite.com.br/ | grep -i noindex
curl -s -o /dev/null -w "%{http_code}" https://seusite.com.br/wp-sitemap.xml
Com blog_public em zero o WordPress 6.9 injeta noindex, nofollow na meta robots de todas as páginas e devolve 404 no /wp-sitemap.xml. O que ele não faz mais, desde a 5.3, é escrever Disallow barra no robots.txt: o arquivo continua igualzinho ao de um site liberado. Por isso tanta gente olha o robots.txt, acha tudo normal e procura o problema no lugar errado.
O robots.txt do WordPress é virtual
Não adianta procurar o arquivo na raiz por FTP: ele não existe no disco. O WordPress monta a resposta na hora e os plugins de SEO entram nela pelo filtro robots_txt. A pegadinha é o contrário: se alguém criou um robots.txt de verdade na raiz durante a mudança de servidor, o nginx entrega o arquivo físico e o virtual nunca roda. Um ls -la robots.txt na pasta do site resolve a dúvida.
Com Yoast tem mais uma camada: o plugin entra no filtro wp_robots com prioridade quase máxima, então a meta robots final é a dele. Se o core já está liberado e o noindex continua no HTML, o ajuste está em SEO > Aparência da busca, no tipo de conteúdo que sumiu do índice.
Destravado, não fique esperando. Abra a Inspeção de URL no Search Console, peça a indexação da home e envie o /wp-sitemap.xml. As primeiras páginas entram em poucos dias.
Se travou nisso e precisa de ajuda, me chama aqui.