Link na bio automático depois de 13 dias publicando todo dia

Mão segurando um celular de tela apagada acima de uma mesa de madeira clara, com caderno aberto, xícara e planta ao fundo

Vinte e um artigos entre 19 de agosto e 9 de setembro, treze deles em treze dias seguidos, e doze desses treze publicados entre 19h18 e 19h26. Os números saem da API do blog que você está lendo agora. O que interessa neste artigo é o que não aconteceu em nenhum desses treze dias: ninguém abriu a página de link na bio para acrescentar o artigo novo, porque essa página monta a própria lista lendo os artigos do site.

A página existe em postping.com.br/blog/bio/ e, quando este texto foi escrito, listava os oito artigos mais recentes, do de ontem ao de 2 de setembro. Os números daqui vieram de chamadas feitas hoje a esse mesmo blog; os limites de rede social vieram da documentação da Meta lida hoje.

Treze dias seguidos e nenhuma edição de link

A lista completa de publicações do blog vem de uma chamada só: /wp-json/wp/v2/posts com per_page=100. A resposta traz 21 registros e o cabeçalho X-WP-Total: 21 confirma que não sobrou nada em outra página. As datas se distribuem assim: um artigo em 19 de agosto, quatro em 26, três em 27, e a partir de 28 de agosto exatamente um por dia até 9 de setembro.

Uma página de links hospedada em outro serviço teria exigido treze visitas ao painel dessa ferramenta, treze colagens de endereço e treze reordenações da lista, porque o artigo novo entra no topo e o de duas semanas atrás precisa sair. Nenhuma dessas operações é difícil. O problema é que elas acontecem no fim do dia, depois do artigo pronto, e são a primeira coisa que se esquece.

Doze dos treze artigos diários saíram na janela das 19h20; o de 28 de agosto saiu às 9h17. Quem publica sabe por quê: o horário combinado não é lei, e o dia em que ele muda é justamente o dia em que a etapa manual seguinte não acontece. A atualização automática não é mais rápida que uma pessoa atenta. Ela é indiferente ao horário.

A lista que a página precisa ler cabe em um quilobyte

De cada artigo, a página no ar carrega quatro coisas:

  • o título, exatamente como foi publicado
  • a data, no formato curto
  • o endereço do artigo
  • a marcação de origem colada nesse endereço, utm_source=instagram&utm_medium=bio, que separa no analytics quem chegou pela bio de quem chegou pela busca

Pedir só isso muda a ordem de grandeza do que trafega. Uma chamada aos cinco artigos mais recentes deste blog, sem restringir campos, devolve 77.615 bytes: vem o conteúdo inteiro dos cinco artigos em HTML renderizado, mais o conteúdo em bruto, mais o resumo, mais dezenas de campos que uma lista de links nunca usa. A mesma chamada com _fields=id,title,link,date,featured_media devolve 1.098 bytes. É a mesma informação visível na tela, em setenta vezes menos dados.

Tem uma armadilha aí. Para trazer a imagem de capa junto, o caminho óbvio é _embed, que anexa o objeto completo da mídia. Medido neste blog agora: 92.201 bytes para os mesmos cinco artigos, mais pesado que a chamada sem filtro nenhum, porque o embed acrescenta os metadados de cada tamanho de imagem gerado pelo WordPress sem tirar nada do que já vinha. Quem monta a página fora do WordPress e liga o embed sem pensar acaba baixando noventa quilobytes para exibir cinco miniaturas.

O tempo de resposta é a outra medida que conta. Três chamadas seguidas à lista dos cinco artigos deste blog levaram 0,97 s, 0,57 s e 0,67 s. Não é lento para uma requisição feita entre servidores, mas é uma espera longa para uma página que só desenha a tela depois que a resposta chega, e é tempo que depende de uma rede fora do seu controle. A lista, aliás, responde 200 sem nenhuma autenticação: o que a página de links exibe é exatamente o que qualquer visitante já pode ler do seu blog, o que dispensa guardar credencial em página pública.

A documentação da REST API diz que per_page tem padrão 10 e teto de 100, e o blog confirma na prática: per_page=101 volta com status 400 e o código rest_invalid_param. O parâmetro orderby aceita, entre outros valores, date e modified, e a diferença entre esses dois decide se um artigo de agosto que você corrigiu hoje volta para o topo da bio.

O cache de sete dias é onde a atualização automática morre

A página inicial do blog responde com Cache-Control: public, max-age=300. Cinco minutos, o que é razoável para um site que publica uma vez por dia. Já a resposta da REST API do mesmo domínio, pedindo os cinco artigos mais recentes, responde com Cache-Control: public, max-age=604800. Sete dias. O feed RSS responde igual, com sete dias, e traz Last-Modified apontando para o artigo de ontem e um ETag para revalidação. As respostas ainda chegam com o cabeçalho Age, que denuncia a borda de CDN entre o servidor e quem pede.

Uma página de links que busca a lista por HTTP e cai numa borda dessas pode mostrar o estado do blog de sete dias atrás, com toda a razão do mundo do ponto de vista do cache, e sem erro nenhum para ninguém investigar. O sintoma é traiçoeiro justamente porque não é intermitente: a página carrega inteira, sem erro nenhum, e mostra a lista errada.

É por isso que a página de link na bio do Post Ping não faz chamada HTTP para lugar nenhum. Ela vive dentro do próprio WordPress, num endereço do seu domínio, e lê os artigos direto de onde eles já estão. A resposta da página no ar traz Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private, que é o oposto dos sete dias da resposta em JSON do mesmo site. O custo é a página não poder ser servida de uma borda; o ganho é ela não ter como mostrar a lista da semana passada. Para uma página que existe justamente para estar em dia, essa troca fecha.

Se você monta a sua à mão, a consequência prática é ler os artigos dentro do próprio WordPress em vez de buscá-los por HTTP no seu próprio site. E se a página tiver mesmo que ficar fora, o mínimo é revalidar pelo ETag do feed antes de confiar na cópia guardada.

O Story não aceita link, e a bio herda esse tráfego

Se o objetivo é levar o seguidor até o artigo, por que passar pela bio em vez de pôr o link no próprio Story?

Porque não existe esse parâmetro. Na documentação de publicação de conteúdo da Meta, lida hoje, o container de story é criado com media_type=STORIES mais image_url ou video_url e o token de acesso. Não há campo de link, de figurinha de link ou de swipe-up na lista de parâmetros. Isso não é limitação de uma ferramenta específica: quem publica story por API, seja qual for o software, publica sem link clicável.

A mesma página impõe outras regras que valem para qualquer esteira automática: cada conta pode publicar 100 posts por período móvel de 24 horas, o container criado expira se não for publicado em 24 horas, JPEG é o único formato de imagem aceito, e filtros e etiquetas de compra não são suportados. São os limites com que qualquer publicação automática convive, e nenhum deles tem a ver com a bio. A mesma documentação registra que o campo de texto alternativo, aberto em março de 2025 para publicações comuns, não vale para reels nem para stories: o story é o formato que menos aceita acessório de qualquer tipo.

O que sobra, então, é o desenho que a própria Meta deixa de pé: o card do Story pede o toque no link do perfil, e o link do perfil precisa estar sempre apontando para uma lista atual. Um endereço fixo, cadastrado uma vez, cuja lista muda sozinha. Quando o Post Ping publica o artigo no Instagram e no Facebook, o mesmo artigo já está no topo dessa página, sem uma segunda operação.

O que quebra a lista antes de você perceber

Nenhuma das falhas dessa lista aparece como erro na tela. Todas aparecem como conteúdo errado. A mais comum é o artigo agendado. Um post com data futura não é publicado ainda, e não deve aparecer. Se a sua página lê tudo sem filtrar por estado, o artigo de amanhã aparece hoje, com link válido, para um texto que você ainda vai revisar. A leitura correta traz só o que está publicado, que é o padrão do endpoint quando o parâmetro status não é informado.

A segunda é a imagem que não existe. Nem todo artigo tem capa definida, e uma lista com quatro miniaturas e um buraco tem cara de erro. O campo featured_media vem como 0 quando não há imagem, e uma página honesta precisa decidir o que fazer nesse caso antes de o caso aparecer: cair para uma cor da marca, mostrar só título e data, ou pular o artigo.

A terceira é a ordenação. Se a página ordena por modified, uma correção de vírgula num texto de agosto joga esse texto para o topo da bio. Ordenar por date mantém a lista fiel ao que foi publicado, que é o que o seguidor espera ver depois de um Story.

A quarta é o artigo que deixa de existir. Um texto despublicado ou apagado sai da lista na mesma hora quando a página lê o site em tempo real, e continua vivo em qualquer cópia que tenha sido guardada em outro lugar. Vale a pena tratar isso como teste: tire um artigo do ar por um minuto, abra a página de links e veja se ele sumiu. Se ele continuar lá, você tem uma cópia intermediária que ninguém sabia que existia, e ela vai reaparecer em outro momento pior.

A quinta não gera erro nenhum e é a mais fácil de não notar: a lista é curta. Este blog tem 21 artigos e a bio mostra oito. O primeiro texto, de 19 de agosto, saiu da lista em 28 de agosto, no dia em que o oitavo artigo mais novo que ele foi publicado, e ninguém tomou essa decisão. É o comportamento certo para um blog diário e é o comportamento errado para um perfil cujo link mais importante é um artigo antigo. Nesse caso, o artigo antigo vira link fixo, ao lado da lista, em vez de disputar espaço dentro dela. A página deste blog tem dois links fixos acima da lista, além do ícone do perfil no Instagram.

Quando essa página não muda nada

A automação da lista só paga quando existe cadência. Um blog que publica duas vezes por mês tem duas atualizações manuais por mês, e duas atualizações por mês ninguém esquece. Se esse é o seu caso, qualquer ferramenta gratuita de links resolve, e o argumento a favor de trazer a página para o seu domínio passa a ser outro: qual página o Google consegue indexar e quem controla o endereço quando a ferramenta muda de plano.

Vale o mesmo para quem usa a bio como vitrine de um produto só. Uma bio com três links fixos que não mudam há um ano não tem problema de atualização para resolver. O que ela tem é um problema de dono do endereço, que é assunto do artigo sobre ter o link na bio no seu próprio domínio.

A lista automática resolve um problema estreito: o do perfil cujo link precisa refletir o que foi publicado hoje, num ritmo em que a etapa manual vai ser esquecida. Se esse é o seu caso, os detalhes da página que faz isso dentro do WordPress estão em recursos do plugin.

Este blog publica sozinho nas redes

Cada artigo daqui vira post no Instagram e no Facebook automaticamente: legenda escrita por IA, card visual gerado na hora. Quem faz isso é o Post Ping, o mesmo plugin que você pode instalar no seu WordPress.

Ver planos do Post Ping