{"id":17980,"date":"2026-02-24T15:07:38","date_gmt":"2026-02-24T14:07:38","guid":{"rendered":"https:\/\/webhosting.de\/domain-weiterleitungen-ladezeit-performance-optimierung-redirects\/"},"modified":"2026-02-24T15:07:38","modified_gmt":"2026-02-24T14:07:38","slug":"redireccionamentos-de-dominios-tempo-de-carregamento-otimizacao-do-desempenho-redireccionamentos","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/domain-weiterleitungen-ladezeit-performance-optimierung-redirects\/","title":{"rendered":"Porque \u00e9 que os redireccionamentos de dom\u00ednios custam tempo de carregamento: otimizar o desempenho"},"content":{"rendered":"<p><strong>Redireccionamentos de dom\u00ednios<\/strong> O tempo de carregamento \u00e9 mais caro porque os navegadores fazem pedidos adicionais antes de carregarem o recurso final. Vou mostrar-lhe onde se perdem milissegundos, como <strong>lat\u00eancia de redireccionamento<\/strong> e quais as alavancas que melhoram visivelmente o desempenho.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>Cadeias de redireccionamento<\/strong> aumentam a lat\u00eancia e aumentam o tempo at\u00e9 ao primeiro byte.<\/li>\n  <li><strong>DNS<\/strong> e o reencaminhamento entre origens prolongam o tempo de arranque.<\/li>\n  <li><strong>HTTPS<\/strong>-Os apertos de m\u00e3o e a falta de HSTS tornam a primeira chamada mais cara.<\/li>\n  <li><strong>Regras do servidor<\/strong> nos redireccionamentos do plugin Edge beat.<\/li>\n  <li><strong>Liga\u00e7\u00f5es internas<\/strong> a atualiza\u00e7\u00e3o salva os pedidos de informa\u00e7\u00e3o e o or\u00e7amento.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/serverraum-ladezeit-5301.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como os redireccionamentos custam tecnicamente tempo<\/h2>\n\n<p>Cada reencaminhamento desencadeia primeiro um <strong>HTTP<\/strong>-e apenas envia de volta um c\u00f3digo de estado com o URL de destino. O browser inicia ent\u00e3o um segundo pedido ao destino, que devolve o <strong>lat\u00eancia de redireccionamento<\/strong> \u00e9 aumentado diretamente. Se a isto for adicionada uma resolu\u00e7\u00e3o DNS para outro dom\u00ednio, o tempo de espera aumenta visivelmente. Uma cadeia de http \u2192 www \u2192 https triplica a sobrecarga. Por isso, planeio os redireccionamentos de modo a que os utilizadores cheguem sempre ao destino final num s\u00f3 passo.<\/p>\n\n<p>Particularmente problem\u00e1ticas s\u00e3o as variantes do lado do cliente, tais como <strong>Meta-Refresh<\/strong> ou redireccionamentos JavaScript. Aqui, o navegador bloqueia frequentemente os caminhos de renderiza\u00e7\u00e3o e aguarda antes do pr\u00f3ximo salto. Os 301\/302 do lado do servidor no n\u00edvel do servidor Web ou CDN fornecem a resposta muito mais rapidamente. Mesmo assim, cada viagem de ida e volta adicional pela rede aumenta. Por isso, utilizo sistematicamente saltos diretos sem passos interm\u00e9dios.<\/p>\n\n<p>O puro <strong>Lat\u00eancia da rede<\/strong> tamb\u00e9m depende da dist\u00e2ncia e do encaminhamento. Se o servidor de redireccionamento estiver localizado longe do utilizador, uma cadeia complicada ganha rapidamente centenas de milissegundos. As localiza\u00e7\u00f5es perif\u00e9ricas de uma CDN abrandam este efeito e fornecem c\u00f3digos de estado mais pr\u00f3ximos do utilizador. Isto reduz o tempo at\u00e9 ao primeiro byte e o carregamento da p\u00e1gina come\u00e7a mais depressa. Minimizo sistematicamente o caminho desde o primeiro clique at\u00e9 \u00e0 resposta final.<\/p>\n\n<h2>Tipos de redireccionamentos e seus efeitos<\/h2>\n\n<p>V\u00e1rios c\u00f3digos comportam-se em <strong>SEO<\/strong> e o desempenho s\u00e3o diferentes. Escolho o estado adequado para receber sinais de liga\u00e7\u00e3o e, ao mesmo tempo, manter a lat\u00eancia baixa. 301 \u00e9 adequado para altera\u00e7\u00f5es permanentes, 302\/307 para casos tempor\u00e1rios. 308 \u00e9 a variante permanente com preserva\u00e7\u00e3o de m\u00e9todo, que funciona bem em pilhas modernas. Os saltos do lado do cliente s\u00e3o usados apenas como uma solu\u00e7\u00e3o de emerg\u00eancia porque aumentam significativamente o tempo de carregamento.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Tipo<\/th>\n      <th>Benef\u00edcio<\/th>\n      <th>Impacto t\u00edpico em <em>Lat\u00eancia<\/em><\/th>\n      <th>Efeito SEO<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>301 (permanente)<\/td>\n      <td><strong>Permanente<\/strong> desloca\u00e7\u00e3o<\/td>\n      <td>Baixo se for direto e do lado do servidor<\/td>\n      <td>Transmite cerca de 90-99% sinais de esquerda<\/td>\n    <\/tr>\n    <tr>\n      <td>302 (tempor\u00e1rio)<\/td>\n      <td><strong>Tempor\u00e1rio<\/strong> desviar<\/td>\n      <td>Baixa com resposta limpa do servidor<\/td>\n      <td>O sinal permanece basicamente no lado da fonte<\/td>\n    <\/tr>\n    <tr>\n      <td>307 (tempor\u00e1rio, conserva\u00e7\u00e3o do m\u00e9todo)<\/td>\n      <td><strong>M\u00e9todo de pedido<\/strong> restos<\/td>\n      <td>Baixa a moderada<\/td>\n      <td>Como 302, vantagem sem\u00e2ntica clara<\/td>\n    <\/tr>\n    <tr>\n      <td>308 (permanente, m\u00e9todo de conserva\u00e7\u00e3o)<\/td>\n      <td><strong>Permanente<\/strong> com m\u00e9todo<\/td>\n      <td>Baixa a moderada<\/td>\n      <td>Como o 301, op\u00e7\u00e3o mais moderna<\/td>\n    <\/tr>\n    <tr>\n      <td>Meta-Refresh<\/td>\n      <td><strong>Do lado do cliente<\/strong> em HTML<\/td>\n      <td>Elevado devido \u00e0 lat\u00eancia de renderiza\u00e7\u00e3o<\/td>\n      <td>Desfavor\u00e1vel, evit\u00e1vel<\/td>\n    <\/tr>\n    <tr>\n      <td>Redireccionamento de JavaScript<\/td>\n      <td><strong>Baseado em scripts<\/strong> no cliente<\/td>\n      <td>Elevado, bloqueia frequentemente os caminhos de renderiza\u00e7\u00e3o<\/td>\n      <td>Desfavor\u00e1vel, evit\u00e1vel<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Tamb\u00e9m sou eu que decido onde \u00e9 que a regra se aplica: <strong>Servidor Web<\/strong>, O proxy reverso, a borda da CDN ou a aplica\u00e7\u00e3o. Quanto mais pr\u00f3ximo da borda, menor a lat\u00eancia. Em configura\u00e7\u00f5es ocupadas, eu movo os redirecionamentos do aplicativo para a borda para evitar tempos de inicializa\u00e7\u00e3o caros. Isso economiza tempo de CPU e reduz o TTFB do destino. Isso acelera de forma mensur\u00e1vel toda a cadeia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/domain-optimierung-5432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Os maiores factores de lat\u00eancia em pormenor<\/h2>\n\n<p>As pesquisas de DNS t\u00eam um custo inicial <strong>Tempo<\/strong>, especialmente para destinos de origem cruzada. Se o navegador tiver de resolver um novo dom\u00ednio, todos os pedidos ao longo do percurso s\u00e3o acrescidos. Minimizo os dom\u00ednios, reduzo as cascatas CNAME e utilizo servidores de nomes r\u00e1pidos. Tamb\u00e9m controlo os TTLs para que as caches tenham efeito de forma significativa. Isto reduz a curva de arranque at\u00e9 \u00e0 p\u00e1gina final.<\/p>\n\n<p>O processamento do servidor e a rota da rede tamb\u00e9m desempenham um papel importante <strong>Papel<\/strong>. Um .htaccess lento com muitas regras torna o Apache visivelmente mais lento. As regras do Nginx atrav\u00e9s de declara\u00e7\u00f5es de retorno reagem mais rapidamente do que reescritas complexas. A n\u00edvel global, os edge locations fornecem redireccionamentos mais pr\u00f3ximos do utilizador. Isso reduz a lat\u00eancia da rota e reduz a carga no Origin.<\/p>\n\n<p>Os saltos ligados accionam o <strong>lat\u00eancia de redireccionamento<\/strong> por salto para cima. Uma sequ\u00eancia do tipo http \u2192 www \u2192 https \u2192 new-URL soma os pedidos, os apertos de m\u00e3o TLS e as caches. Consolido num \u00fanico salto: http\/non-www \u2192 https\/www ou de acordo com uma forma can\u00f3nica definida. Isto significa que s\u00f3 h\u00e1 uma viagem de ida e volta por pedido. Tanto os utilizadores como os bots v\u00e3o reparar nisto.<\/p>\n\n<h2>Core Web Vitals e SEO: O que fazem os redireccionamentos<\/h2>\n\n<p>Atraso no reencaminhamento lento <strong>FCP<\/strong> e TTFB, o que piora o Core Web Vitals. Os motores de busca desvalorizam as entradas lentas e reduzem o or\u00e7amento de rastreio. Cada cadeia consome slots adicionais antes de o conte\u00fado parecer index\u00e1vel. Os sinais de liga\u00e7\u00e3o do 301 s\u00e3o em grande parte mantidos, mas os tempos de espera adicionais reduzem a impress\u00e3o geral. Eu mantenho a entrada simples para que os bots possam aceder rapidamente ao conte\u00fado.<\/p>\n\n<p>Na pr\u00e1tica, isto significa: dist\u00e2ncias curtas, objectivos diretos, clareza <strong>Can\u00f3nico<\/strong>-estrat\u00e9gias. As liga\u00e7\u00f5es internas devem apontar imediatamente para o URL final. Isto poupa pedidos, refor\u00e7a os sinais e reduz as taxas de rejei\u00e7\u00e3o. Depois de ter estabelecido corretamente as bases, beneficiar\u00e1 de classifica\u00e7\u00f5es est\u00e1veis a longo prazo. Para mais informa\u00e7\u00f5es sobre cadeias, consulte a minha refer\u00eancia a <a href=\"https:\/\/webhosting.de\/pt\/por-que-as-cadeias-de-redirecionamento-http-aumentam-o-tempo-de-carregamento-otimizado-para-desempenho\/\">Correntes de redireccionamento do trav\u00e3o<\/a>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/domain-performance-optimieren-4378.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Medi\u00e7\u00e3o e diagn\u00f3stico: como encontrar todos os estrangulamentos<\/h2>\n\n<p>Come\u00e7o com um <strong>HAR<\/strong>-exportar do separador de rede do browser. A\u00ed posso ver a sequ\u00eancia de pedidos, c\u00f3digos de estado e tempos por salto. Descobertas como m\u00faltiplos DNS, handshakes TLS antes do destino ou 301s duplicados s\u00e3o imediatamente vis\u00edveis. Ferramentas como o cURL com o sinalizador -L rastreiam claramente as cadeias de redireccionamento. Isto permite-me provar todas as rondas desnecess\u00e1rias e remov\u00ea-las de forma direcionada.<\/p>\n\n<p>Tamb\u00e9m verifico os registos do servidor e a an\u00e1lise da CDN para <strong>Borda<\/strong>-hits. Taxas elevadas de perda de cache para redireccionamentos indicam regras incorrectas ou falta de normaliza\u00e7\u00e3o. Recolho valores medidos de diferentes regi\u00f5es em paralelo para detetar problemas de encaminhamento. Se uma grande propor\u00e7\u00e3o de utilizadores atingir n\u00f3s distantes, transfiro as regras para os PoPs mais pr\u00f3ximos. Em seguida, verifico se o TTFB e o FCP diminuem de forma mensur\u00e1vel.<\/p>\n\n<p>Por fim, confirmo o sucesso com uma renovada <strong>Farol<\/strong>-an\u00e1lise. As m\u00e9tricas Time to First Byte e First Contentful Paint melhoram visivelmente se a entrada n\u00e3o abrandar. Tamb\u00e9m verifico se os motores de busca captam os URLs finais sem desvios. Se as cadeias persistirem, reajusto as regras. S\u00f3 quando todos os pedidos de informa\u00e7\u00e3o chegam diretamente ao alvo \u00e9 que o trabalho est\u00e1 conclu\u00eddo.<\/p>\n\n<h2>Estrat\u00e9gias de otimiza\u00e7\u00e3o: do DNS \u00e0 periferia<\/h2>\n\n<p>A melhor estrat\u00e9gia come\u00e7a com um <strong>Can\u00f3nicos<\/strong>-Defini\u00e7\u00e3o: Formul\u00e1rio de protocolo, nome do anfitri\u00e3o e caminho. Em seguida, defino exatamente um redireccionamento do lado do servidor para este formul\u00e1rio. Remeto imediatamente as liga\u00e7\u00f5es internas, os mapas de s\u00edtios e os dados estruturados para o URL de destino. Isto significa que n\u00e3o s\u00e3o criadas novas cadeias de modelos ou menus. Cada redu\u00e7\u00e3o de saltos poupa tempo imediato.<\/p>\n\n<p>Eu acelero o DNS atrav\u00e9s do fast <strong>Servidor de nomes<\/strong> e TTLs curtos e significativos. Removo CNAMEs sup\u00e9rfluos e aponto consistentemente o anfitri\u00e3o Apex e www para o mesmo ponto final. No servidor Web, utilizo instru\u00e7\u00f5es de retorno de alto desempenho no Nginx ou diretivas de redireccionamento claras no Apache. No CDN, defino as regras o mais pr\u00f3ximo poss\u00edvel do utilizador e deixo que o edge responda. Isto mant\u00e9m o Origin intocado e r\u00e1pido.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/techoffice_nachtszene_2304.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utilizar corretamente HTTPS, HSTS e HTTP\/2\/3<\/h2>\n\n<p>A primeira chamada HTTPS requer um <strong>TLS<\/strong>-que custa tempo. Utilizo o HSTS para que os navegadores escolham de imediato o https no futuro e poupem os desvios http. Al\u00e9m disso, o pr\u00e9-carregamento do HSTS pode acelerar a primeira visita, porque j\u00e1 n\u00e3o h\u00e1 uma tentativa de texto simples. O HTTP\/2 e o HTTP\/3 reduzem a sobrecarga do protocolo e melhoram as lat\u00eancias em redes inst\u00e1veis. Isto minimiza a penaliza\u00e7\u00e3o da convers\u00e3o.<\/p>\n\n<p>As configura\u00e7\u00f5es incorrectas podem facilmente gerar <strong>Rondas<\/strong>: http \u2192 https \u2192 www \u2192 barra ou vice-versa. Uma regra \u00fanica e clara para a forma can\u00f3nica resolve este problema. Verifico meticulosamente a ordem e removo entradas contradit\u00f3rias no servidor Web, na CDN e na aplica\u00e7\u00e3o. Se quiser ler mais sobre o ajuste fino, clique em <a href=\"https:\/\/webhosting.de\/pt\/https-redirect-performance-configuracao-incorrecta-torna-o-serverboost-mais-lento\/\">Desempenho do redireccionamento HTTPS<\/a>. Deste modo, os apertos de m\u00e3o s\u00e3o simples e o reencaminhamento \u00e9 curto.<\/p>\n\n<h2>Estrutura can\u00f3nica: WWW, barra e caminhos<\/h2>\n\n<p>Eu defino um <strong>uniforme<\/strong> forma de anfitri\u00e3o (www ou n\u00e3o-www) e mantenho-me fiel a ela. Decido a barra \u00e0 direita por tipo de conte\u00fado e mantenho a decis\u00e3o em todos os geradores. Normalizo as variantes de par\u00e2metros se fornecerem conte\u00fados id\u00eanticos. Utilizo regras claras de caminho ou subdom\u00ednio para variantes de l\u00edngua ou pa\u00eds. Desta forma, a arquitetura evita novas cadeias em cada chamada de p\u00e1gina.<\/p>\n\n<p>Para projectos com migra\u00e7\u00f5es, planeio <strong>Mapeamento<\/strong>-tabelas ao n\u00edvel do canal hor\u00e1rio. Todos os caminhos antigos t\u00eam um destino direto sem paragens interm\u00e9dias. Actualizo as liga\u00e7\u00f5es internas, os mapas de s\u00edtios e os feeds ao mesmo tempo. Isto significa que os utilizadores e os bots chegam imediatamente ao conte\u00fado mais recente. Isto poupa or\u00e7amento e aumenta os sinais para o URL de destino.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/ladezeit_optimierung_domain_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>WordPress e outros CMS: regras limpas em vez de lastro de plugins<\/h2>\n\n<p>Cada plugin adicional acrescenta <strong>L\u00f3gica<\/strong> e corre o risco de sofrer atrasos. Desloco os redireccionamentos para o servidor Web ou para a CDN, onde s\u00e3o executados mais rapidamente. Utilizo os plug-ins do WordPress com modera\u00e7\u00e3o e apenas em casos especiais com baixa frequ\u00eancia. Tamb\u00e9m limpo os permalinks para que o CMS produza a forma can\u00f3nica de forma nativa. Isto poupa-me muitos saltos na fonte.<\/p>\n\n<p>Para relan\u00e7amentos, actualizo <strong>Menus<\/strong>, widgets e blocos internos diretamente para URLs de destino. Corrijo os caminhos das imagens e dos scripts com pesquisas e substitui\u00e7\u00f5es na base de dados. Giro novos mapas de s\u00edtios para que os bots rastreiem os alvos actuais. Em seguida, verifico se ocorrem erros 404 e corrijo os mapeamentos em falta. O resultado: menos caminhos de erro e tempos de carregamento mais curtos.<\/p>\n\n<h2>Redireccionamentos do Edge vs. redireccionamentos da aplica\u00e7\u00e3o<\/h2>\n\n<p>Os redireccionamentos de extremidade s\u00e3o geograficamente <strong>mais pr\u00f3ximo<\/strong> para o utilizador e requerem menos viagens de ida e volta. Muitas vezes, os redireccionamentos de aplica\u00e7\u00f5es s\u00f3 ocorrem ap\u00f3s o arranque da estrutura e custam tempo de CPU. Prefiro regras no Edge, coloco-as em cache e respondo ao tr\u00e1fego de IA ou bot sem acesso ao Origin. Isso economiza a capacidade do servidor para solicita\u00e7\u00f5es de p\u00e1ginas reais. Isso mant\u00e9m o tempo de resposta est\u00e1vel em hor\u00e1rios de pico.<\/p>\n\n<p>Para alguns cen\u00e1rios, a aplica\u00e7\u00e3o precisa de <strong>L\u00f3gica<\/strong>, como o estado do utilizador ou verifica\u00e7\u00f5es de sess\u00e3o. Depois, divido as regras: can\u00f3nicos est\u00e1ticos para o limite, decis\u00f5es din\u00e2micas na aplica\u00e7\u00e3o. Aqui, tamb\u00e9m, a regra \u00e9 tornar-se din\u00e2mico apenas o mais tarde poss\u00edvel. Quanto mais casos forem cobertos de forma est\u00e1tica, mais r\u00e1pida \u00e9 a cadeia. Os utilizadores apercebem-se disso com cada clique.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/02\/domain-ladezeiten-3957.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configura\u00e7\u00f5es pr\u00e1ticas para Apache e Nginx<\/h2>\n\n<p>Eu confio no Apache para <strong>Permanente<\/strong>-Os saltos devem ter diretivas claras. Uma regra t\u00edpica \u00e9: Redirecionar 301 \/alt https:\/\/www.beispiel.de\/neu. Presto aten\u00e7\u00e3o \u00e0 ordem para que tenha efeito antes de blocos com muita reescrita. Combino v\u00e1rias regras de forma l\u00f3gica para evitar correspond\u00eancias duplas. Isto mant\u00e9m o processamento por pedido curto.<\/p>\n\n<p>No Nginx, utilizo a op\u00e7\u00e3o <strong>retorno<\/strong>-diretiva para respostas r\u00e1pidas. Um exemplo: return 301 https:\/\/www.beispiel.de$request_uri;. Eu encapsulo condi\u00e7\u00f5es complexas em blocos de mapa para que o fluxo de solicita\u00e7\u00e3o permane\u00e7a limpo. Removo blocos de servidores concorrentes que tratam o mesmo host de forma diferente. Isso evita desvios e economiza lat\u00eancia.<\/p>\n\n<h2>Migra\u00e7\u00e3o e planeamento de projectos sem cadeias<\/h2>\n\n<p>Antes de uma altera\u00e7\u00e3o de dom\u00ednio ou de estrutura, crio um <strong>Mapeamento<\/strong> de todos os caminhos relevantes. Defino a forma can\u00f3nica, construo uma estrutura de destino e verifico a exist\u00eancia de conflitos. Em seguida, simulo os redireccionamentos num ambiente de teste. Ap\u00f3s o go-live, monitorizo os c\u00f3digos de estado, 404s e TTFB durante 3-7 dias. Se ocorrerem cadeias, corrijo a regra diretamente na fonte.<\/p>\n\n<p>Adapto as refer\u00eancias internas em paralelo para que nenhum <strong>Antiga<\/strong>-URLs permanecem no sistema. Isto tamb\u00e9m se aplica a e-mails, PDFs, modelos de feed e dados estruturados. Se tiver pontos de entrada incertos, pode utilizar temporariamente o 302 e mudar para o 301 mais tarde. \u00c9 importante definir objectivos claros desde o in\u00edcio. Depois disso, o aparelho de redireccionamento permanece pequeno e r\u00e1pido.<\/p>\n\n<h2>Redirecionar ou p\u00e1gina de destino? Quando um salto direto ao conte\u00fado \u00e9 melhor<\/h2>\n\n<p>Algumas campanhas ou caminhos antigos merecem uma <strong>P\u00e1gina de destino<\/strong> em vez de redireccionamentos. Se a p\u00e1gina fornecer um valor acrescentado independente, poupo-me ao salto e ofere\u00e7o o conte\u00fado imediatamente. Se o caminho antigo existir apenas como um pseud\u00f3nimo, redirecciono diretamente para o recurso principal atrav\u00e9s do 301. Isto cria uma estrutura clara sem duplicar o trabalho de manuten\u00e7\u00e3o. Uma breve compara\u00e7\u00e3o pode ser encontrada em <a href=\"https:\/\/webhosting.de\/pt\/reencaminhamento-de-dominios-vs-landingpage-seo-hosting-avancado\/\">P\u00e1gina de reencaminhamento ou de destino<\/a>.<\/p>\n\n<p>Para as deslocaliza\u00e7\u00f5es SEO, decido estritamente de acordo com <strong>Utilizadores<\/strong>-inten\u00e7\u00e3o. Se o utilizador quiser a mesma informa\u00e7\u00e3o, redirecciono diretamente. Se a inten\u00e7\u00e3o mudar, defino uma p\u00e1gina de destino tematicamente adequada com o seu pr\u00f3prio conte\u00fado. Desta forma, os sinais permanecem consistentes e os utilizadores obt\u00eam o que esperam. Em ambos os casos, o tempo de carregamento beneficia de caminhos claros.<\/p>\n\n<h2>Caching de redireccionamento: cabe\u00e7alhos, TTLs e controlo<\/h2>\n\n<p>Eu uso <strong>Armazenamento em cache<\/strong>, para fazer redireccionamentos recorrentes praticamente sem custos. Os saltos permanentes (301\/308) podem levar muito tempo para os navegadores e CDNs armazenarem em cache. Para isso, defino clear <strong>Controlo da cache<\/strong>-(por exemplo, max-age) ou controlo substituto ao n\u00edvel do limite. Limito deliberadamente os 302\/307s tempor\u00e1rios com TTLs curtos para que as altera\u00e7\u00f5es tenham efeito rapidamente. A consist\u00eancia \u00e9 importante: uma vez publicado um 301, este \u00e9 frequentemente recordado permanentemente pelo browser. \u00c9 por isso que testo as regras em ambientes de teste e s\u00f3 aplico 301s quando a estrutura de destino est\u00e1 finalizada. Nos registos, marco os redireccionamentos com um cabe\u00e7alho como X-Redirect-By para ver as taxas de sucesso e as configura\u00e7\u00f5es incorrectas de forma transparente. Isto permite-me reconhecer se o Edge est\u00e1 a responder corretamente ou se a Origem est\u00e1 a ser utilizada desnecessariamente.<\/p>\n\n<p>O <strong>Chaves de cache<\/strong> Eu normalizo: alvos id\u00eanticos devem receber o mesmo endere\u00e7o de cache (normaliza\u00e7\u00e3o de host e barra). Defino os cabe\u00e7alhos Vary com modera\u00e7\u00e3o - um Vary: User-Agent sup\u00e9rfluo duplica as taxas de erro. Para CDNs, verifico se as respostas 301 s\u00e3o armazenadas em cache por defeito ou se \u00e9 necess\u00e1rio definir ativamente uma regra. O objetivo \u00e9 que os saltos id\u00eanticos venham do limite e n\u00e3o sejam recalculados para cada visita. Isto diminui o TTFB do redireccionamento e reduz de forma mensur\u00e1vel a carga nos backends.<\/p>\n\n<h2>Par\u00e2metros, traject\u00f3rias e normaliza\u00e7\u00e3o sem efeitos secund\u00e1rios<\/h2>\n\n<p>Certifico-me de que um reencaminhamento <strong>Cadeias de consulta<\/strong> \u00e9 passado corretamente. No Nginx, asseguro isto com $request_uri ou $is_args$args, no Apache com sinalizadores adequados para que os par\u00e2metros n\u00e3o se percam. Trato os par\u00e2metros de rastreio como utm_* ou fbclid deliberadamente: Ou eu <strong>normalizar<\/strong> (removendo-as se n\u00e3o tiverem valor acrescentado) ou deixo-as passar de forma transparente. Evito saltos duplos apenas por acrescentar uma barra final, resolvendo as regras de barra e de anfitri\u00e3o numa \u00fanica resposta. Normalizo as mai\u00fasculas\/min\u00fasculas, a codifica\u00e7\u00e3o de percentagens e as barras duplas sup\u00e9rfluas para que n\u00e3o seja criado um caminho diferente para cada visita.<\/p>\n\n<p>Particularmente importante: I <strong>receber<\/strong> a inten\u00e7\u00e3o do utilizador atrav\u00e9s do m\u00e9todo. Para GET, 301\/302 \u00e9 suficiente, para formul\u00e1rios POST defino 307\/308 para que o m\u00e9todo n\u00e3o se torne involuntariamente GET. Isto evita erros nos fluxos de checkout ou login. As \u00e2ncoras (#hash) s\u00e3o do lado do cliente e n\u00e3o s\u00e3o transferidas - se a p\u00e1gina de destino precisar de uma sec\u00e7\u00e3o vis\u00edvel, resolvo isso com rotas do lado do servidor e n\u00e3o com redireccionamentos adicionais. Isto mant\u00e9m o caminho curto e correto.<\/p>\n\n<h2>L\u00edngua, segmenta\u00e7\u00e3o geogr\u00e1fica e escolha do utilizador<\/h2>\n\n<p>Autom\u00e1tico <strong>Geo<\/strong> ou o reencaminhamento de l\u00ednguas s\u00e3o complicados. Utilizo-os, se \u00e9 que os utilizo, apenas uma vez e com base em Accept-Language - n\u00e3o rigidamente de acordo com o IP. A primeira visita pode apontar para uma vers\u00e3o lingu\u00edstica adequada atrav\u00e9s de 302, ap\u00f3s o que guardo a escolha atrav\u00e9s de um cookie. O fator decisivo \u00e9 que cada vers\u00e3o lingu\u00edstica tem um <strong>URL pr\u00f3prio<\/strong> com uma estrat\u00e9gia can\u00f3nica consistente. Isto mant\u00e9m os sinais limpos e permite que os utilizadores mudem de l\u00edngua sem acabarem em cadeias.<\/p>\n\n<p>Para projectos globais, evito saltos de origem entre muitos subdom\u00ednios. Prefiro organizar os caminhos lingu\u00edsticos sob um dom\u00ednio can\u00f3nico e reduzir as pesquisas no DNS. Se utilizar subdom\u00ednios, certifico-me de que o DNS e o TLS s\u00e3o igualmente r\u00e1pidos em todos os anfitri\u00f5es. Testo, a partir de diferentes regi\u00f5es, se um utilizador chega a n\u00f3s desnecessariamente largos. Se a sele\u00e7\u00e3o da regi\u00e3o for oferecida por banner em vez de for\u00e7ada por redireccionamento, poupo viagens de ida e volta adicionais e mantenho o <strong>Tempo de carregamento<\/strong> est\u00e1vel.<\/p>\n\n<h2>Seguran\u00e7a e estabilidade: evitar redireccionamentos abertos, OAuth e loops<\/h2>\n\n<p>O reencaminhamento \u00e9 tamb\u00e9m um <strong>Seguran\u00e7a<\/strong>-t\u00f3pico. Fecho os redireccionamentos abertos atrav\u00e9s de par\u00e2metros de pr\u00f3ximo ou de retorno livremente configur\u00e1veis, permitindo apenas listas brancas de destinos ou verificando rigorosamente os caminhos internos. Para fluxos OAuth e SSO, registo URIs de redireccionamento exactos e evito wildcards. Defino cookies com Secure e uma estrat\u00e9gia SameSite adequada para que uma mudan\u00e7a de dom\u00ednio n\u00e3o perca uma sess\u00e3o. A monitoriza\u00e7\u00e3o ajuda: se a taxa de 3xx aumentar drasticamente, procuro especificamente por loops ou regras defeituosas.<\/p>\n\n<p>Limito os saltos de redireccionamento a um m\u00e1ximo de alguns passos e cancelo-os em caso de erro. <strong>claro<\/strong> desligado. Prefiro responder \u00e0s p\u00e1ginas que s\u00e3o permanentemente removidas com 410 em vez de enviar os utilizadores para a p\u00e1gina inicial (risco de soft-404). S\u00f3 utilizo marcadores de posi\u00e7\u00e3o para restos de migra\u00e7\u00e3o se realmente se enquadrarem no tema - 301s em massa para a p\u00e1gina inicial s\u00e3o maus para os utilizadores e para os sinais. Consigo estabilidade atrav\u00e9s de sequ\u00eancias de correspond\u00eancia claras e testes com as configura\u00e7\u00f5es do Edge e do Origin para que nenhuma regra concorrente tenha efeito.<\/p>\n\n<h2>Redes m\u00f3veis, HTTP\/2\/3 e TLS 1.3 em intera\u00e7\u00e3o<\/h2>\n\n<p>Nas redes m\u00f3veis, cada <strong>Ida e volta<\/strong> duplo. Reduzo os \"handshakes\" evitando o http\u2192https (HSTS), normalizando o anfitri\u00e3o e o protocolo num s\u00f3 passo e activando o HTTP\/3. O QUIC lida melhor com a perda de pacotes e mant\u00e9m as liga\u00e7\u00f5es est\u00e1veis apesar das altera\u00e7\u00f5es de IP. O TLS 1.3 reduz a sobrecarga e os remetentes beneficiam de 0-RTT para os pedidos de seguimento. O agrupamento de liga\u00e7\u00f5es e a coalesc\u00eancia no HTTP\/2 ajudam se v\u00e1rios anfitri\u00f5es estiverem no mesmo certificado - \u00e9 por isso que eu consolido os anfitri\u00f5es quando faz sentido.<\/p>\n\n<p>Verifico se os cabe\u00e7alhos Alt-Svc e os certificados est\u00e3o definidos de forma a que o browser responda rapidamente a <strong>H3<\/strong> altera\u00e7\u00f5es. O Keep-Alive e os tempos de inatividade sensatos impedem o estabelecimento constante de novas liga\u00e7\u00f5es durante redireccionamentos curtos. Nos dispositivos m\u00f3veis, testo com redes reais (limita\u00e7\u00e3o de 3G no acelerador) para ver qual \u00e9 realmente a dimens\u00e3o da parte do redireccionamento na lat\u00eancia global. Essas descobertas fluem diretamente para a consolida\u00e7\u00e3o de regras.<\/p>\n\n<h2>Sugest\u00f5es de recursos, m\u00e9tricas RUM e monitoriza\u00e7\u00e3o cont\u00ednua<\/h2>\n\n<p>Se um redireccionamento de origem cruzada for inevit\u00e1vel, posso utilizar <strong>Dicas de recursos<\/strong> a partir de navega\u00e7\u00f5es na p\u00e1gina: dns-prefetch ou preconnect preparam o anfitri\u00e3o de destino antes de o clique ter lugar. Isto s\u00f3 funciona se o utilizador j\u00e1 tiver carregado uma p\u00e1gina - n\u00e3o ajuda com um arranque a frio. Nos SPAs, certifico-me de que os encaminhadores internos se dirigem diretamente ao URL final em vez de desencadearem primeiro os redireccionamentos do cliente. Quando apropriado, interceto casos de navega\u00e7\u00e3o atrav\u00e9s de um service worker e normalizo os caminhos sem acordar a origem.<\/p>\n\n<p>Para o controlo, confio em <strong>RUM<\/strong> (Real User Monitoring) e testes sint\u00e9ticos. No RUM, me\u00e7o o tempo de navega\u00e7\u00e3o - especialmente o redirectStart\/redirectEnd - para ver os caminhos reais dos utilizadores. Al\u00e9m disso, tenho rob\u00f4s de diferentes regi\u00f5es a verificar URLs definidos para detetar cadeias, atrasos de DNS e erros de TLS. Adiciono cabe\u00e7alhos de tempo do servidor que mostram explicitamente a dura\u00e7\u00e3o dos redireccionamentos. Isto permite-me reconhecer o progresso ap\u00f3s cada altera\u00e7\u00e3o de regra e manter um olho na lat\u00eancia dos redireccionamentos como um item de or\u00e7amento separado.<\/p>\n\n<h2>Breve resumo e controlo pr\u00e1tico<\/h2>\n\n<p>Eu mantenho o reencaminhamento <strong>simples<\/strong>, diretamente e no lado do servidor para minimizar a lat\u00eancia. Cada cadeia custa tempo, aumenta a taxa de rejei\u00e7\u00e3o e desperdi\u00e7a o or\u00e7amento de rastreio. O DNS, o TLS e a dist\u00e2ncia somam milissegundos que s\u00e3o percept\u00edveis. Os can\u00f3nicos limpos, as regras de borda, os servidores de nomes r\u00e1pidos e o HTTP\/2\/3 poupam esfor\u00e7os em cada chamada. A atualiza\u00e7\u00e3o permanente das liga\u00e7\u00f5es internas e dos mapas de s\u00edtios evita saltos desnecess\u00e1rios.<\/p>\n\n<p>Para a realiza\u00e7\u00e3o eu vou <strong>sistem\u00e1tico<\/strong> antes: Mapeamento, defini\u00e7\u00e3o de can\u00f3nicos, uma regra por destino, corre\u00e7\u00e3o de refer\u00eancias internas, testes e monitoriza\u00e7\u00e3o. Me\u00e7o o TTFB e o FCP antes e depois da mudan\u00e7a para provar o sucesso. Com o HTTPS, o HSTS evita os desvios de texto simples, enquanto as regras de retorno no Nginx ou as diretivas simples do Apache reduzem o tempo de resposta. Substituo os truques do lado do cliente porque eles bloqueiam e atrapalham. Desta forma, o desempenho do reencaminhamento de dom\u00ednios mant\u00e9m-se elevado e os utilizadores continuam a bordo.<\/p>","protected":false},"excerpt":{"rendered":"<p>Porque \u00e9 que os redireccionamentos de dom\u00ednios custam tempo de carregamento: Causas da lat\u00eancia dos redireccionamentos e optimiza\u00e7\u00f5es para o desempenho dos redireccionamentos de dom\u00ednios.<\/p>","protected":false},"author":1,"featured_media":17973,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[674],"tags":[],"class_list":["post-17980","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web_hosting"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"934","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Domain Weiterleitungen","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"17973","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/17980","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=17980"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/17980\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/17973"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=17980"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=17980"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=17980"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}