Publicação e manutenção de um site

Um site precisa de uma pasta de projeto que contenha todos os arquivos usados pelos visitantes. Essa é a raiz do site. A publicação fica muito mais fácil quando essa pasta é um site completo e portátil: sem imagens emprestadas da pasta Downloads e sem folhas de estilo deixadas na pasta de outro projeto.

Dê um lugar a cada tipo de arquivo

Uma pequena oficina de reparos poderia usar esta organização:

riverside-bikes/
  index.html
  prices.html
  contact.html
  404.html
  css/styles.css
  scripts/menu.js
  images/logo.svg
  images/workshop-800.jpg
  images/workshop-1600.jpg
  blog/index.html
  blog/winter-checklist.html

As páginas HTML são o conteúdo, css/ contém os estilos, scripts/ contém os arquivos JavaScript e images/ contém as imagens prontas para os visitantes. Um site sem scripts não precisa de uma pasta de scripts. Pastas separadas facilitam encontrar arquivos relacionados sem alterar a forma como o navegador os usa.

A maioria dos servidores web envia index.html quando um visitante solicita uma pasta. O endereço https://www.example.com/ abre a página inicial da raiz. O endereço https://www.example.com/blog/ abre blog/index.html. Um arquivo chamado home.html ainda é uma página, mas o servidor geralmente não o escolherá para o endereço do site sem caminho.

Escolha os nomes antes do lançamento

Use letras minúsculas, hífens entre palavras e a extensão correta. opening-hours.html e team-photo.jpg são nomes claros. Espaços podem aparecer em URLs como %20, tornando o endereço mais difícil de ler e digitar. Os nomes passam a fazer parte dos endereços públicos do site, então escolha-os de acordo com o conteúdo que identificam.

A extensão deve corresponder ao arquivo: .html para HTML, .css para CSS, .js para scripts e uma extensão de imagem adequada, como .jpg, .webp ou .svg. O servidor envia um cabeçalho Content-Type que descreve o formato do arquivo. Sistemas de hospedagem costumam usar extensões para escolher esse tipo. Renomear uma foto de .jpg para .webp não converte seu conteúdo; exporte-a no novo formato com uma ferramenta de imagem.

A maioria dos servidores diferencia nomes em maiúsculas e minúsculas. Um link para Logo.svg pode falhar quando o arquivo enviado é logo.svg, mesmo que tenha funcionado em um computador cujo sistema de arquivos não diferencia maiúsculas de minúsculas. O hábito de usar nomes em minúsculas evita essa diferença em novos projetos.

Separe arquivos públicos de arquivos de trabalho

Mantenha os originais da câmera, arquivos de design e anotações fora da raiz do site, por exemplo, em riverside-bikes-originals/. Exporte apenas as imagens preparadas para a web para images/. Arquivos na pasta publicada podem ser baixados mesmo quando nenhuma página tem um link para eles. Mantenha senhas, documentos privados e dados pessoais fora dessa pasta.

Antes do envio, verifique se todos os arquivos de recursos locais vinculados estão dentro do projeto. Uma foto em um endereço pessoal file:// existe no seu computador; ela não acompanha o site, a menos que você a copie para a pasta publicada. Depois de movê-la, atualize o link e teste-o novamente.

Uma estrutura estável também protege os links após o lançamento. Mover prices.html para um novo endereço quebra os favoritos antigos, a menos que o provedor redirecione esse endereço antigo para a nova página.

Um caminho informa ao navegador onde procurar um arquivo. Para escrevê-lo corretamente, identifique tanto o arquivo solicitado quanto o local a partir do qual o navegador resolverá o caminho.

Comece na pasta do arquivo que faz a referência

Um caminho relativo começa na pasta da página atual. No site da oficina de bicicletas, index.html cria um link para prices.html com href="prices.html", para o logotipo com src="images/logo.svg" e para uma publicação com href="blog/winter-checklist.html".

De dentro de blog/winter-checklist.html, o caminho muda:

<link rel="stylesheet" href="../css/styles.css">
<a href="../index.html">Home</a>
<img src="../images/logo.svg" alt="Riverside Bike Repair">
<a href="autumn-tips.html">Autumn tips</a>

Para o logotipo, primeiro suba de blog/ com ../ e depois entre em images/. Um arquivo na mesma pasta precisa apenas do seu nome. Para subir dois níveis, use ../../. Sempre use barras normais / em caminhos web, inclusive ao escrever no Windows.

Um caminho em um arquivo CSS começa na pasta do arquivo CSS. Em css/styles.css, a regra background-image: url("../images/pattern.svg"); sobe de css/ e depois entra em images/. Ela não começa na página HTML que carregar a folha de estilo.

Diferencie três formas de endereço

Uma URL absoluta inclui o esquema e o nome do hospedeiro. Use-a para outro site. Caminhos relativos permitem que seu próprio site se mova entre um servidor local, um endereço de prévia e seu domínio final sem substituir o domínio em cada link.

Uma barra inicial tem um significado específico. Em https://username.github.io/riverside-bikes/, /css/styles.css solicita https://username.github.io/css/styles.css. Ela elimina a pasta do projeto do endereço. A partir da página raiz do site, css/styles.css mantém essa pasta e chega ao arquivo pretendido.

Teste o endereço que o navegador realmente usa

Abrir HTML diretamente do disco fornece um endereço file://. Links para pastas e caminhos que começam com / podem se comportar de forma diferente nesse caso. Execute um servidor local de desenvolvimento a partir da pasta do site, por exemplo, com python3 -m http.server, ou use a prévia em tempo real de um editor de código. Depois, abra o endereço HTTP local que ele fornece.

Em um servidor, href="blog/" abre blog/index.html. Se um link ou uma imagem falhar, abra as DevTools antes de recarregar e encontre a requisição no painel Rede. Um 404 significa que o recurso solicitado não foi encontrado. Leia a URL completa da requisição e compare cada pasta, barra, letra e extensão com os arquivos enviados. Uma letra maiúscula ou um ../ ausente basta para levar o navegador a outro lugar. Um caminho pessoal de computador copiado de um explorador de arquivos não pode atender aos visitantes; substitua-o por um caminho dentro do site.

Os navegadores tentam exibir páginas mesmo quando o código contém erros. Essa recuperação é útil para os visitantes, mas pode ocultar problemas do autor. A validação verifica o HTML ou CSS em relação às regras de seu padrão, independentemente de a página parecer correta.

Use o verificador da linguagem

O W3C Nu Html Checker verifica HTML. O W3C CSS Validation Service verifica CSS. Você pode enviar uma URL publicada, carregar um arquivo ou colar código. As verificações integradas ao editor são úteis enquanto você escreve; os verificadores na web também permitem verificar a cópia publicada.

Leia a linha e a coluna associadas a cada mensagem. Um erro viola uma regra e precisa ser corrigido. Um aviso ou uma mensagem informativa pede atenção, mas pode descrever código permitido. Leia o que a mensagem diz antes de decidir se é preciso fazer uma alteração.

Comece pelo primeiro erro e siga para baixo; execute o verificador novamente após a correção. Uma aspa ausente ou um elemento mal fechado pode fazer o código posterior parecer estar em um lugar ao qual não pertence, produzindo muitas mensagens subsequentes.

Corrija a estrutura no HTML

Veja elementos aninhados incorretamente:

<p>Open <strong>daily</p></strong>

O <strong> interno deve fechar antes do <p> externo:

<p>Open <strong>daily</strong></p>

Para uma foto que transmite conteúdo, forneça um atributo alt que descreva seu conteúdo relevante, como alt="Mechanic adjusting the brakes of a city bike". Uma imagem decorativa usa um alt="" vazio. Cada id também deve ser único dentro da página. Use uma classe compartilhada quando vários elementos precisarem do mesmo estilo.

Outras verificações úteis incluem a declaração de tipo de documento, o título da página, aspas completas nos atributos e itens de lista dentro de uma lista. Um <div> não pode ficar dentro de um parágrafo. O navegador fecha esse parágrafo antes do elemento div, e um </p> posterior pode se tornar uma tag de fechamento sem correspondência. A estrutura corrigida pelo navegador pode diferir do texto que você escreveu.

Corrija declarações no CSS

Um número e sua unidade CSS devem ficar juntos: escreva width: 100px;, sem espaço entre 100 e px. A propriedade para a cor do texto é color. Uma propriedade desconhecida é ignorada.

Um ponto e vírgula ausente também pode prejudicar a declaração seguinte:

.card {
  margin: 10px
  padding: 5px;
}

O navegador lê as duas linhas como uma única declaração inválida. Adicione o ponto e vírgula ausente após 10px e verifique novamente. Os navegadores geralmente ignoram declarações inválidas sem exibir um erro na página.

Combine verificações de código com verificações da página

Passar na validação não comprova que a página é acessível, rápida, útil ou que suas informações estão corretas. Experimente a navegação por teclado, examine o layout em navegadores e verifique o próprio conteúdo. Se o verificador de CSS sinalizar um recurso muito novo, consulte sua especificação e as informações de suporte no MDN antes de remover código que funciona; os verificadores podem demorar a acompanhar recursos mais recentes.

Valide após alterações substanciais e antes de publicar. Após o envio, submeta o endereço publicado e verifique se o conteúdo mais recente está visível. Uma página antiga válida pode passar tão facilmente quanto a atualizada.

As ferramentas do desenvolvedor, muitas vezes chamadas DevTools, mostram como o navegador interpreta sua página. Clique com o botão direito em um item e escolha Inspecionar. Você também pode usar F12 ou Ctrl+Shift+I no Windows e Linux, ou Cmd+Option+I no macOS. No Safari, primeiro ative “Mostrar recursos para desenvolvedores web” em Ajustes, Avançado.

Inspecione a estrutura do navegador

O painel Elementos, chamado Inspetor no Firefox, mostra o DOM: a estrutura construída a partir do HTML. O navegador pode ter corrigido marcação inválida, então ela nem sempre é uma cópia direta do código-fonte. Um <div> escrito dentro de um parágrafo aparece fora dele no DOM porque o navegador encerra o parágrafo primeiro.

Selecione o item com problema. O painel Estilos lista as regras CSS correspondentes e fornece links para seus arquivos-fonte e números de linha. Uma declaração riscada não está ativa. Outra regra pode prevalecer sobre ela, ou um ícone de aviso pode mostrar que a declaração é inválida. O painel Computado mostra os valores finais das propriedades depois que o navegador resolve essas regras.

Acompanhe uma regra de cor que não prevalece

Suponha que este link apareça em azul-marinho, embora sua classe de botão peça branco:

<a class="btn" href="contact.html">Contact us</a>

#main a { color: navy; }
.btn { color: white; }

As duas regras correspondem ao link quando ele está dentro de id="main". O seletor de id torna #main a mais específico: sua especificidade é (1, 0, 1), em comparação com (0, 1, 0) para .btn. Nessas regras comuns, colocar .btn depois não supera essa diferença.

Uma correção direcionada é #main .btn, com especificidade (1, 1, 0). Outra é substituir a regra abrangente de id por uma classe de link como .nav-link. Dois seletores de uma única classe têm a mesma especificidade, então a ordem deles pode decidir a cor. Alterar #main a para .main a ainda deixa (0, 1, 1), que supera .btn. Inspecione a regra que realmente prevalece antes de escolher a menor correção útil.

Meça a caixa inteira

O diagrama do modelo de caixa separa conteúdo, preenchimento interno, borda e margem. Com box-sizing: content-box, uma largura de conteúdo de 300px mais preenchimento interno de 20px em cada lado e bordas de 2px ocupa:

Isso resulta em uma caixa de borda de 344px, antes de quaisquer margens. Com box-sizing: border-box, a caixa de borda inteira permanece com 300px de largura; a largura de seu conteúdo passa a ser:

Use o diagrama para explicar um espaço ou transbordamento em vez de alterar larguras repetidamente por tentativa e erro. Os indicadores de flexbox e grade também podem mostrar trilhas, linhas e espaçamentos do layout.

Experimente uma alteração e depois salve-a

Desative uma declaração, edite um valor ou adicione uma regra em Estilos. Force :hover ou :focus para examinar um estado sem manter o ponteiro ou o teclado na posição. Essas edições são temporárias: a edição comum nas DevTools não atualiza os arquivos do projeto. Copie a alteração que funciona para o código-fonte, salve e recarregue. Se a correção desaparecer, ela ainda não foi salva na cópia carregada pelo navegador.

Uma página é montada a partir de várias requisições. O HTML pode chegar com sucesso enquanto uma folha de estilo ou imagem falha. As mensagens do Console e o painel Rede mostram esses resultados separados.

Abra as ferramentas antes de recarregar

O Console informa erros e avisos, incluindo falhas de scripts, recursos ausentes e conteúdo misto. As mensagens costumam ter links para o arquivo e a linha afetados. Até um site de HTML e CSS pode apresentar mensagens úteis no Console.

O painel Rede registra as requisições da página enquanto as DevTools estão abertas. Abra-o, recarregue e depois filtre por CSS, imagens ou fontes para reduzir a lista. Leia a URL solicitada, o status, o tipo, o tamanho e o tempo. Selecione uma entrada para inspecionar os cabeçalhos e o conteúdo da resposta.

Um status na faixa dos 400 diz respeito à requisição; um na faixa dos 500 diz respeito ao servidor. Um 404 não é evidência de que você precisa alterar o layout CSS.

Investigue um logotipo ausente

A página publicada tem um espaço vazio para a imagem. No painel Rede, a requisição é https://www.example.com/images/Logo.svg, com retorno 404. O arquivo enviado é images/logo.svg. O L maiúsculo solicitado não corresponde ao nome real em minúsculas. Corrija o caminho no HTML, implante a página e confirme que a requisição agora funciona.

Investigue uma página sem estilo

Procure primeiro a requisição do CSS. Se nenhuma requisição aparecer, inspecione o elemento <link>, incluindo rel="stylesheet". Se a requisição retornar 404, compare sua URL com o local do arquivo enviado.

Um 200 indica apenas uma resposta bem-sucedida, não confirma que a resposta é CSS. Verifique o Console e o Content-Type da resposta, que deve ser text/css. Um provedor de hospedagem pode retornar por engano uma página de erro HTML com status 200, e o navegador se recusará a aplicá-la como folha de estilo. Quando o CSS correto chegar com o tipo certo, inspecione declarações inválidas e seletores que não correspondem ao elemento afetado.

Descarte a hipótese da cópia salva do navegador

Um cache armazena arquivos para reutilização. Ele economiza tempo de download, mas uma cópia antiga pode fazer uma atualização bem-sucedida parecer ausente. Com as DevTools abertas, ative “Desativar cache” no painel Rede e recarregue. No Chrome, Edge e Firefox, Ctrl+Shift+R no Windows e Linux ou Cmd+Shift+R no macOS força um recarregamento completo. Inspecione o conteúdo retornado antes de concluir que o envio falhou.

As colunas de tamanho e tempo também ajudam com problemas de velocidade. Uma imagem de 3,6 MB entre pequenos arquivos de texto é um ponto de partida útil. A limitação de velocidade da rede simula uma conexão mais lenta. Uma página HTTPS que solicita um arquivo com http:// pode gerar um aviso de conteúdo misto; inspecione a URL exata do recurso para encontrar a referência insegura.

Um relato útil de defeito descreve uma diferença observável: “Com 360px de largura, a página de contato rola para os lados.” Isso é mais fácil de investigar do que “o layout para celular está quebrado”. Registre o endereço da página, o navegador, a largura da tela, o resultado real e o resultado esperado.

Siga as evidências em cinco etapas

1. Reproduza. Faça o problema acontecer novamente nas mesmas condições.
2. Reúna evidências. Leia o Console e o painel Rede, valide o código e inspecione o elemento afetado.
3. Isole. Desative uma regra ou remova temporariamente um pequeno trecho de código para restringir as possíveis causas.
4. Altere uma coisa. Teste se essa alteração explica o resultado.
5. Salve e teste novamente. Coloque a correção no código-fonte, recarregue e verifique outras condições.

Alterar várias coisas ao mesmo tempo torna o resultado difícil de interpretar. Uma alteração pode resolver o problema original enquanto outra cria um novo. Mantenha disponível o caso que falha para comparar o antes e o depois.

Investigue um transbordamento em tela estreita

Uma página cabe na tela de um notebook, mas rola para os lados em uma área de visualização de 360px. Abra o modo responsivo nessa largura. Passe o ponteiro sobre os elementos em Elementos e observe suas caixas destacadas. Uma imagem é mais larga que sua coluna; seu HTML fornece uma largura intrínseca grande, e nenhum CSS a limita.

Experimente esta regra:

img {
  max-width: 100%;
  height: auto;
}

A largura máxima permite que a imagem diminua para caber no contêiner. A altura automática preserva suas proporções. Se o transbordamento desaparecer, salve essa regra na folha de estilo correta e recarregue. Depois, teste a imagem também em larguras maiores. Ocultar o transbordamento horizontal na página poderia esconder parte da imagem sem fazê-la caber.

Se a alteração não produzir efeito, use as evidências para restringir o próximo passo. A regra aparece em Estilos? Ela é substituída por outra? O navegador carregou o arquivo que você editou? Causas comuns incluem nomes de classe que não correspondem, caminhos incorretos, chaves ou pontos e vírgulas ausentes, arquivos não salvos e cópias em cache.

Teste motores e tamanhos de janela

O modo responsivo altera a largura da área de visualização e pode simular toque, mas não reproduz todos os detalhes da velocidade, das fontes ou da renderização de um celular real. Verifique os pontos de quebra das consultas de mídia e as larguras entre eles; depois, use pelo menos um celular real.

Chrome e Edge usam Blink, Firefox usa Gecko e Safari usa WebKit. Dois navegadores que usam o mesmo motor não oferecem a mesma abrangência de testes que navegadores com motores diferentes. O Safari é particularmente relevante para os muitos navegadores de iPhone que usam WebKit. Consulte as informações de suporte no MDN antes de depender de um recurso mais recente.

Verifique a versão publicada

O comportamento do servidor pode expor falhas ocultas no disco: nomes que diferenciam maiúsculas de minúsculas, arquivos não enviados e caminhos que pulam uma subpasta de projeto. Abra o endereço publicado, siga os links e inspecione as requisições com falha ali.

Antes de publicar, valide o HTML e o CSS, inspecione os erros do Console, verifique se há 404s não intencionais, experimente larguras de celular, tablet e computador e verifique pelo menos dois motores de navegador. Use o teclado para percorrer a navegação e acionar os controles. Após a implantação, repita as verificações no site publicado onde o recurso alterado é usado.

Uma imagem otimizada é um arquivo pequeno que ainda apresenta boa aparência no tamanho em que é exibido. Comece pelo formato, pelas dimensões em pixels e pela compressão. Reduzir uma foto grande demais com CSS altera sua aparência, mas o navegador ainda baixa e decodifica o arquivo original.

Escolha o formato de acordo com o conteúdo

Imagens rasterizadas armazenam pixels. Ampliar uma imagem rasterizada pequena revela o desfoque, pois nenhum detalhe extra é criado. O SVG armazena formas e linhas, então é adequado para um logotipo, mas não para uma foto de câmera. Os principais navegadores atuais aceitam WebP e AVIF. Para animações, um formato de imagem moderno ou um vídeo curto costuma gerar um arquivo menor que o GIF.

A compressão sem perdas preserva os valores dos pixels. A compressão com perdas remove alguns detalhes para economizar mais bytes. Uma qualidade menor acaba produzindo áreas quadriculadas ou bordas borradas. Compare a exportação no tamanho real em que será exibida. Faça cada nova exportação a partir do original, evitando salvamentos repetidos com perdas de uma cópia já comprimida.

Redimensione para o maior uso

Uma foto exibida com no máximo 800 pixels CSS de largura precisa de cerca de 800 pixels de imagem em uma tela de densidade padrão e 1.600 em uma tela que usa dois pixels do dispositivo por pixel CSS. Prepare alternativas adequadas em vez de enviar o original da câmera para todos.

O original da oficina de bicicletas tem 4.000 × 3.000 pixels e 3,6 MB. Uma exportação de 1.600 × 1.200 tem:

pixels, ou 16% dos 12 milhões do original. Uma exportação JPEG na qualidade 80 pode ter cerca de 240 KB; o tamanho real depende da foto. Esse exemplo economiza cerca de 93% dos bytes do arquivo.

A 10 Mbit/s, usando MB decimal, o tempo ideal de transferência do original é:

segundos. A exportação de 0,24 MB leva cerca de 0,19 segundo. Esses são apenas tempos de transferência; o carregamento real também inclui atrasos de conexão e do servidor. Decodificado a 4 bytes por pixel, o uso de memória cai de 48 MB para 7,68 MB. Um arquivo codificado menor e menos pixels decodificados são ganhos distintos.

Exporte uma cópia pública

Use os controles de exportação de um editor de imagens ou uma ferramenta como o Squoosh. Mantenha o original fora da pasta publicada e dê às exportações nomes claros, como workshop-800.jpg e workshop-1600.jpg. Remova os metadados da câmera durante a exportação; eles podem incluir a data da foto, detalhes da câmera e localização GPS.

Para um SVG, um otimizador como o SVGO remove dados remanescentes do programa de desenho. A compressão de texto no servidor pode reduzir ainda mais seu tamanho de transferência. Em qualquer formato, inspecione a imagem final: uma foto salva como PNG pode ser desnecessariamente grande, enquanto um logotipo com muito texto salvo como JPEG pode ter bordas borradas.

Uma imagem pode ser pequena o bastante para baixar rapidamente e ainda assim fazer uma página saltar. O navegador precisa conhecer suas proporções antes de ela chegar e ter opções úteis para diferentes telas.

Reserve espaço com dimensões

Escreva os atributos numéricos width e height sem unidades:

<img src="images/workshop-800.jpg"
     width="800" height="600"
     alt="Mechanic adjusting the brakes of a city bike">

Essas dimensões informam ao navegador a proporção 4:3 entre largura e altura. Com max-width: 100%; height: auto; no CSS, a imagem diminui para caber em uma coluna estreita. Em uma coluna de 360px de largura, sua altura é:

pixels. Reservar esse espaço impede que o texto abaixo se mova para baixo quando a imagem carregar. A ausência de dimensões pode produzir deslocamentos de layout, os movimentos inesperados medidos pelo CLS.

Ofereça larguras que o navegador possa escolher

Para a mesma foto em dois tamanhos, use descritores de largura e uma descrição de sua largura de exibição:

<img src="images/workshop-800.jpg"
     srcset="images/workshop-800.jpg 800w,
             images/workshop-1600.jpg 1600w"
     sizes="(max-width: 840px) 100vw, 800px"
     width="800" height="600"
     alt="Mechanic adjusting the brakes of a city bike">

800w e 1600w informam as larguras reais dos arquivos. Nesse layout, sizes indica que a imagem ocupa a largura da área de visualização até 840px e 800px acima disso. O navegador usa a largura declarada para o espaço da imagem, a densidade da tela e suas regras de seleção para escolher um arquivo. Faça sizes corresponder ao layout real; afirmar que a imagem ocupa toda a área de visualização quando a coluna é muito mais estreita pode causar downloads desnecessários.

Ofereça formatos com uma alternativa

<picture>
  <source srcset="images/workshop.avif" type="image/avif">
  <source srcset="images/workshop.webp" type="image/webp">
  <img src="images/workshop.jpg" width="800" height="600"
       alt="Mechanic adjusting the brakes of a city bike">
</picture>

O navegador escolhe o primeiro formato de origem que aceita. O <img> obrigatório fornece a alternativa, as dimensões e o texto alternativo. Essa é uma escolha de formato; srcset com descritores de largura resolve o problema relacionado de escolher uma largura adequada em pixels.

Adie imagens que ainda não são necessárias

Use loading="lazy" para imagens mais abaixo na página. O navegador pode esperar até que o visitante chegue perto delas, economizando dados para imagens que nunca são alcançadas. Mantenha o carregamento imediato das imagens visíveis na abertura, especialmente da grande imagem principal de destaque. O carregamento tardio dessa imagem atrasa o conteúdo que os visitantes esperam ver. Uma imagem principal no HTML é descoberta cedo; fetchpriority="high" pode solicitar maior prioridade para sua busca.

Escreva o texto alt de acordo com a finalidade da imagem no contexto. Uma imagem decorativa recebe alt="". Fotos e diagramas que transmitem conteúdo devem ficar no HTML como imagens; um fundo CSS é adequado para decoração e não tem atributo alt nem atributo nativo loading.

O peso da página é o total de dados baixados para uma página. O HTML leva a requisições de CSS, imagens, scripts e fontes. Tamanhos de arquivos, quantidade de requisições, velocidade da conexão e desempenho do dispositivo contribuem para a experiência.

Encontre a maior parcela

A página inicial da oficina de bicicletas baixa 15 KB de HTML, 30 KB de CSS, duas fontes de 40 KB, uma imagem principal de 2.400 KB e três fotos de 350 KB:

KB. As imagens representam 3.450 KB, cerca de 96,5%. Com uma imagem principal de 220 KB e três fotos de 45 KB, o total passa a ser:

KB, cerca de 87% menos. A 10 Mbit/s, o tempo ideal de transferência cai de cerca de 2,86 segundos para 0,38 segundo. A resposta do servidor e o estabelecimento da conexão acrescentam tempo. Remover alguns espaços do CSS teria pouco efeito em comparação com essa economia nas imagens.

Leia as medidas da experiência

Os Core Web Vitals, conforme outubro de 2026, medem diferentes problemas:

Um bom desempenho em campo atende a cada limiar no 75º percentil. O CLS pode incluir um banner que desloca conteúdo após o carregamento, não apenas uma imagem que chega durante o carregamento inicial.

O Lighthouse no Chrome ou Edge executa um teste de laboratório com pontuações e correções sugeridas. O PageSpeed Insights executa testes online e, quando há observações suficientes, mostra dados de campo de visitas reais no Chrome. Uma pontuação de laboratório é um teste em condições escolhidas. Repita as comparações com as mesmas configurações e observe visitas reais quando disponíveis.

Melhore primeiro os maiores custos

Prepare primeiro as imagens e sua marcação. Depois, reduza famílias e espessuras de fontes desnecessárias, use fontes WOFF2 e use font-display: swap para que o texto apareça em uma fonte alternativa enquanto a fonte carrega. Adicione defer a scripts externos adequados para que o download não bloqueie a análise sintática do HTML e a execução ocorra após essa análise. Mapas grandes, reprodutores de vídeo e outras incorporações de terceiros podem ser carregados sob demanda.

A minificação remove espaços e comentários do código. A compressão gzip ou Brotli reduz os bytes de texto transferidos. Elas ajudam, mas imagens JPEG, WebP e AVIF já comprimidas ganham pouco com uma compressão adicional do tipo usada para texto.

O cache permite que visitantes que retornam reutilizem arquivos, controlado por cabeçalhos como Cache-Control. Uma CDN mantém cópias em diferentes regiões para reduzir a distância percorrida pelas requisições. Quando um recurso mantido em cache por muito tempo muda, um nome como styles-v2.css ou um endereço como styles.css?v=2 faz com que seja feita uma nova requisição. Teste com limitação de velocidade da rede e em um celular; um notebook rápido no Wi-Fi pode ocultar uma experiência lenta em dispositivos móveis.

Cada página deve explicar sua própria finalidade em seu HTML. Os mecanismos de busca leem essa marcação, enquanto abas do navegador, favoritos e leitores de tela também dependem dela. Uma estrutura clara começa pelo conteúdo que os visitantes podem realmente ler.

Nomeie a página no cabeçalho

O elemento <title> fica no <head>. Dê a cada página seu próprio título descritivo, com o nome do site após o assunto específico:

<title>Repair Prices – Riverside Bike Repair</title>
<meta name="description"
      content="Prices for flat repairs, brake adjustments and full services at Riverside Bike Repair. Walk in Monday to Saturday or book online.">

O título aparece na aba do navegador e nos favoritos e geralmente contribui para o título nos resultados de busca. O HTML não impõe um limite de comprimento para o título, mas as exibições de busca cortam o texto para caber no espaço, então coloque as palavras úteis primeiro. Um título genérico como “Início” fornece pouca informação quando separado do site.

A metadescrição é um resumo legível da página em uma ou duas frases. Os mecanismos de busca podem usá-la como trecho de um resultado, mas também podem selecionar texto da página. Faça a descrição corresponder ao conteúdo daquela página. Copiar uma descrição para todas as páginas oculta as diferenças entre elas; uma lista de palavras-chave repetidas não é um resumo útil. O Google ignora a antiga tag meta keywords.

Declare o idioma e os caracteres

Use <html lang="en"> para uma página em inglês. Isso ajuda leitores de tela a escolher a pronúncia e navegadores a lidar com recursos de idioma. O Google identifica o idioma a partir do texto visível e ignora esse atributo, então não o trate como uma configuração de idioma para o Google.

Coloque <meta charset="utf-8"> perto do início do cabeçalho para que caracteres como é e um travessão curto sejam exibidos corretamente. Inclua a tag meta da área de visualização usada em páginas responsivas:

<meta name="viewport" content="width=device-width, initial-scale=1">

Faça o esquema corresponder às ideias

Use um <h1> claro para o assunto principal da página, <h2> para suas seções principais e <h3> para subseções. Na página de preços, “Serviços” é um h2, com “Serviço básico” e “Serviço completo” como títulos h3 abaixo dele. Escolha os níveis de título de acordo com essa relação; ajuste seus tamanhos visuais com CSS.

Elementos semânticos identificam funções: <nav> para navegação, <main> para o conteúdo principal e elementos <header>, <article>, <section> e <footer> adequados. Use listas reais, links para navegação e botões para ações. Uma página de divisões genéricas perde esses sinais de função. Mantenha palavras importantes, como preços, horários de funcionamento e títulos, em texto HTML, onde ficam disponíveis como texto para visitantes e ferramentas.

Configure uma prévia útil para links compartilhados

As tags Open Graph descrevem uma prévia de link em aplicativos sociais e de mensagens. Propriedades comuns são og:title, og:description e og:image:

<meta property="og:title" content="Repair Prices">
<meta property="og:image"
      content="https://www.example.com/images/workshop-800.jpg">

Use uma URL HTTPS completa para a imagem de prévia. Essas tags descrevem o cartão compartilhado; elas não substituem os títulos visíveis da página nem seu título e descrição comuns.

Rastreamento é a busca de páginas, muitas vezes seguindo links. Indexação é o armazenamento de informações sobre essas páginas para os resultados de busca.

Forneça um caminho até cada página

Crie um link comum <a href> para cada página a partir de pelo menos outra página. Um texto descritivo como “preços de reparos” informa aos visitantes e rastreadores o que o destino contém. Um caminho legível como /blog/winter-checklist.html fornece mais contexto do que /page7.html.

Um mapa do site lista as URLs preferidas completas que você quer que sejam descobertas. Uma entrada XML pode ser assim:

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/prices.html</loc>
    <lastmod>2026-10-01</lastmod>
  </url>
</urlset>

A data opcional da última modificação deve representar uma alteração significativa. Atualize o mapa do site conforme as páginas mudarem. Um site pequeno e bem conectado por links pode ser descoberto sem um mapa do site.

Mantenha distintos os controles de rastreamento e indexação

Um arquivo robots.txt na raiz do domínio pede aos rastreadores que respeitam as regras que não busquem determinados caminhos:

User-agent: *
Disallow: /drafts/
Sitemap: https://www.example.com/sitemap.xml

Isso não bloqueia a pasta. As pessoas podem abrir seus endereços, e uma URL bloqueada ainda pode aparecer nos resultados se outras páginas tiverem links para ela. Sem um arquivo robots.txt, os rastreadores podem buscar as páginas. Um Disallow: / copiado bloqueia o rastreamento de todo o site, então remova um bloqueio de site de teste antes do lançamento quando o site deva ser rastreado.

Para solicitar a exclusão dos resultados de busca, coloque isto no cabeçalho da página:

<meta name="robots" content="noindex">

O rastreador precisa buscar a página para ler essa instrução. Bloquear a mesma URL no robots.txt pode impedi-lo de descobrir noindex. Nenhuma das configurações torna uma página privada: conteúdo privado precisa de controle de acesso ou deve ficar fora do site público.

Escolha um endereço para conteúdo duplicado

Uma página pode responder em endereços HTTP e HTTPS, com e sem www, ou tanto em /blog/ quanto em /blog/index.html. Um link canônico identifica o endereço preferido:

<link rel="canonical" href="https://www.example.com/blog/">

Use a URL absoluta completa. A marcação canônica é uma indicação forte; um redirecionamento que realmente envia visitantes ao endereço preferido é um sinal mais forte. Faça os links internos e as URLs do mapa do site corresponderem a essa preferência para evitar sinais conflitantes.

Verifique o que os mecanismos de busca podem ver

Google Search Console e Bing Webmaster Tools aceitam mapas do site e mostram problemas de indexação e rastreamento depois que você comprova o controle do site. Uma busca por site:example.com fornece uma visão aproximada das páginas indexadas. Sites novos podem levar dias ou semanas para aparecer. Um mapa do site, marcação clara ou um pagamento não podem garantir uma posição alta; essas ferramentas ajudam você a encontrar obstáculos técnicos e entender o que foi processado.

Um site estático serve arquivos preparados de HTML, CSS, imagens e scripts. Seu conteúdo pode ser atualizado sempre que você publicar novos arquivos; “estático” descreve como o provedor de hospedagem os serve. O servidor de hospedagem continua entregando os arquivos quando seu próprio computador está desligado.

Saiba o que o provedor oferece

Um site dinâmico constrói respostas no servidor, muitas vezes a partir de um banco de dados. Um pequeno site informativo ou portfólio construído com HTML e CSS pode usar hospedagem estática sem programação no servidor. Adicionar a marcação de um formulário de contato não cria, por si só, um serviço que armazene ou envie os dados por e-mail. Isso exige processamento de formulários fornecido pelo provedor ou um serviço separado.

Provedores de hospedagem estática costumam fornecer um endereço temporário, controles de publicação e HTTPS. Muitos servem arquivos por meio de uma rede de distribuição de conteúdo, que mantém cópias regionais. GitHub Pages, Netlify, Cloudflare Pages e Vercel são exemplos, com diferentes termos de plano e fluxos de trabalho. A hospedagem compartilhada é outra opção e muitas vezes oferece transferência segura de arquivos.

Uma página estática ainda pode executar JavaScript no navegador do visitante, como uma interação de menu. O provedor continua servindo um arquivo de script preparado. Sem código de aplicação do site ou banco de dados em execução no servidor, há menos componentes de aplicação para atacar; a conta de hospedagem e os arquivos públicos ainda precisam de proteção.

Um site de usuário no GitHub Pages usa o endereço raiz https://username.github.io/ a partir de um repositório chamado username.github.io. Um site de projeto usa uma subpasta como /riverside-bikes/. Essa estrutura de endereço importa ao testar caminhos de arquivos de recursos relativos à raiz.

Compare as necessidades com o plano atual

Leia os limites e as condições do plano antes de escolher. Verifique:

• Limites de armazenamento e transferência mensal de dados.
• Se o plano permite uso comercial.
• Suporte a domínio personalizado e HTTPS automático.
• Um método de publicação que você possa usar de forma confiável.
• Páginas de erro personalizadas, redirecionamentos e recuperação de implantações anteriores.
• Processamento de formulários, se os visitantes precisarem enviar informações.
• A facilidade de levar seus arquivos para outro provedor de hospedagem.

Um portfólio de fotógrafo com seis páginas e 40 fotos preparadas cabe nos limites de tamanho de muitos planos estáticos gratuitos. Se ele atrair trabalhos remunerados, porém, sua finalidade comercial também importa. O tamanho, por si só, não estabelece que um plano gratuito o permita. Os termos mudam, então verifique o serviço e o plano reais em vez de depender de uma comparação antiga.

Escolha um caminho de publicação que você consiga manter

A publicação por arrastar e soltar pode ser adequada a um projeto pequeno: você envia a pasta pela interface do provedor. Uma conexão com um repositório publica a partir de uma fonte de código armazenada e escolhida e pode implantar atualizações quando alterações são enviadas. Ferramentas de linha de comando oferecem outro caminho. A hospedagem compartilhada muitas vezes oferece SFTP, um método criptografado de transferência de arquivos. O FTP simples expõe credenciais e arquivos durante a transferência, então use um caminho seguro.

No GitHub Pages em um plano gratuito, a publicação está disponível a partir de repositórios públicos. Qualquer pessoa pode ler os arquivos do repositório. Os arquivos de recursos publicados também são públicos, mesmo quando a navegação não tem links para eles. Limite o envio aos arquivos destinados ao público e proteja a conta de hospedagem com autenticação de dois fatores.

Verifique um recurso em seu fluxo de trabalho real

Se o site incluir um formulário de contato, localize o endereço de destino do formulário ou o recurso do provedor que o recebe. Confirme que o plano inclui esse recurso e envie uma submissão de teste após o lançamento. Um formulário que parece completo ainda pode não ter para onde enviar os dados. Se uma página 404 personalizada ou um redirecionamento permanente for importante, confirme o método exato de configuração do provedor antes de depender dele.

Implantar é publicar os arquivos atuais do site em um provedor de hospedagem. O diretório de publicação se torna a raiz do site online. Para HTML e CSS simples, não há etapa de construção: selecione a pasta que contém o index.html pronto e seus arquivos de recursos.

Faça a primeira publicação

Para um provedor com arrastar e soltar:

1. Abra a pasta que pretende publicar e confirme que index.html está diretamente dentro dela.
2. Valide as páginas e teste seus links e layouts por meio de um servidor local.
3. Envie essa pasta usando a interface de publicação do provedor.
4. Espere até que o provedor informe que a implantação está publicada.
5. Abra o endereço web fornecido e verifique o site nele.

Se a página inicial aparecer apenas em /riverside-bikes/index.html, você pode ter enviado a pasta que a contém um nível acima do necessário. O diretório de publicação pretendido é riverside-bikes/, não a pasta que o contém. Corrija a seleção do diretório e publique novamente; apenas direcionar visitantes ao endereço aninhado deixa incorreto o endereço inicial sem caminho.

Publique a partir de um repositório

No GitHub Pages, abra Settings e Pages no repositório. Escolha “Deploy from a branch”, selecione a ramificação e a pasta de publicação, sua raiz ou /docs, e salve. Quando uma nova versão é enviada para essa fonte de publicação, o Pages a implanta novamente. Verifique o endereço do Pages exibido após a conclusão da implantação. Uma URL de projeto pode incluir o nome do repositório, então teste os caminhos nesse local real.

Outros provedores têm suas próprias configurações de conexão com repositório e de diretório. Para um site feito de arquivos simples, não adicione um comando de construção apenas porque a interface oferece um campo para ele.

Verifique a versão entregue

Abra todas as páginas, siga os links internos e inspecione o Console e o painel Rede em busca de recursos com falha. Force um recarregamento completo para evitar confundir arquivos em cache com a nova versão. Experimente o site em um celular real. Verifique a alteração visível que pretendia publicar, não apenas a ausência de uma mensagem de erro.

Configure uma página 404.html personalizada onde o provedor oferecer suporte. Ela deve informar ao visitante que o endereço não foi encontrado e oferecer uma forma útil de voltar à página inicial. Verifique um endereço inexistente inventado para confirmar que o provedor realmente a usa. Uma página de erro útil não substitui um redirecionamento quando o conteúdo foi movido.

Mantenha uma fonte que possa ser recuperada

O projeto local ou repositório conectado é a fonte de referência oficial, a cópia a partir da qual futuras versões são publicadas. Uma correção rápida no editor web do provedor pode desaparecer no próximo envio, a menos que você também a coloque nessa fonte.

Use uma implantação de prévia quando disponível para testar uma atualização antes que os visitantes a recebam. Se uma atualização quebrar o site publicado, uma reversão para uma versão anterior do provedor pode restaurar uma implantação anterior. Depois, corrija também a fonte, caso contrário a próxima versão pode reintroduzir a falha.

Quando uma página mudar de endereço, adicione um redirecionamento 301 permanente da URL antiga para a nova usando as regras de redirecionamento do provedor. Teste o endereço antigo após a publicação: ele deve levar à nova página pretendida. No Netlify, um arquivo _redirects é uma forma de configuração; outros provedores usam configurações diferentes.

Um nome de domínio é um nome legível, como example.com. O DNS conecta esse nome a informações como o endereço IP de um provedor de hospedagem. O registro dá a você o direito de usar o nome por um período; não é uma compra permanente.

Leia um endereço web

Em https://www.example.com/prices.html, https é o esquema, www.example.com é o nome do hospedeiro e /prices.html é o caminho. Leia os rótulos de domínio da direita para a esquerda: .com é o domínio de nível superior, ou TLD; example é o nome registrado sob ele; www é um subdomínio.

TLDs genéricos incluem .com, .org, .net, .dev, .shop e .studio. TLDs de código de país usam duas letras, como .de, .fr, .jp, .ca e .au. Alguns nomes são registrados sob uma categoria de segundo nível, como .co.uk.

Algumas terminações têm regras de elegibilidade. .ca exige uma ligação com o Canadá; .eu aceita cidadãos, residentes e organizações estabelecidas elegíveis da União Europeia ou do EEE; .us exige uma ligação com os Estados Unidos. Verifique as regras do operador de registro antes de escolher uma terminação restrita. As terminações .dev e .app exigem HTTPS nos navegadores.

Saiba quem cuida do registro

Um registrador de domínios registra seu domínio junto ao operador de registro de domínios que administra o TLD. A ICANN coordena o sistema de TLDs genéricos e credencia seus registradores; operadores de registro de códigos de país definem suas próprias regras. Os registros costumam durar de um a dez anos e precisam ser renovados.

Escolha um nome curto, fácil de dizer e soletrar e próximo do nome do projeto ou negócio. Evite números e hífens confusos e verifique se o nome não usa a marca registrada de outra pessoa. Se um nome .com preferido estiver ocupado, compare um nome mais longo e claro, uma terminação local adequada ou uma terminação genérica pertinente. A disponibilidade, por si só, não é permissão para usar o nome de outra empresa.

Compare o compromisso contínuo

Verifique o preço de renovação além da oferta do primeiro ano. Serviços adicionais, incluindo e-mail, podem ter cobranças separadas. O domínio e a hospedagem do site podem vir de empresas diferentes; registrar um domínio não envia um site por si só.

Forneça informações corretas sobre o titular e o contato e responda ao e-mail de verificação do registrador. Dados de contato não confirmados podem levar à suspensão. Para informações de registro de TLDs genéricos, o RDAP tornou-se a forma definitiva de consulta pública em janeiro de 2025, substituindo os requisitos do antigo serviço WHOIS. A consulta pública costuma ocultar dados pessoais; o registrador ainda precisa de registros corretos.

Mantenha o controle com o proprietário

O proprietário do projeto ou negócio deve controlar a conta do titular do domínio, mesmo quando um designer cria o site. Ative a autenticação de dois fatores e mantenha os dados de recuperação atualizados. Para mudar de registrador, siga o processo de transferência, incluindo um código de transferência e o desbloqueio do domínio quando for elegível.

Registre a data de expiração, ative a renovação e mantenha válido o método de pagamento. Um registro expirado pode interromper o site e o e-mail do domínio; após os períodos de carência e exclusão aplicáveis, outra pessoa pode registrar o nome. Cópias de segurança da hospedagem não podem preservar um registro de domínio que você deixa expirar.

O Sistema de nomes de domínio, ou DNS, armazena registros de nomes. Um resolvedor procura esses registros, muitas vezes mantendo uma resposta em cache. Os servidores de nomes autoritativos são os servidores responsáveis pelas informações DNS do domínio. Faça alterações no provedor cujos servidores de nomes realmente atendem ao domínio.

Escolha o tipo de registro

Os endereços IP e o nome .example aqui são valores de documentação. Para uma conexão real, use os valores fornecidos pelo seu provedor de hospedagem para o seu site.

O domínio raiz da zona é o nome raiz registrado, como example.com. O DNS padrão não permite um CNAME nele porque a raiz da zona também precisa de outros registros, incluindo NS. Use os valores A e AAAA do provedor de hospedagem ou um recurso ALIAS, ANAME ou de achatamento de CNAME aceito pelo provedor de DNS. Um subdomínio como www costuma usar um CNAME.

Conecte duas formas de um endereço

Suponha que um provedor de hospedagem solicite um registro A na raiz da zona e um CNAME para www. Um provedor de DNS que usa @ para a raiz da zona pode mostrar:

Type    Name    Value                           TTL
A       @       192.0.2.44                       3600
CNAME   www     riverside-bikes.pages.example    3600

Informe também o domínio personalizado nas configurações de hospedagem. O provedor precisa reconhecer o nome solicitado e associá-lo ao site. Escolha o endereço principal e configure a outra forma para redirecionar para ele.

Leia as instruções do provedor para o campo de nome. Se ele adicionar example.com automaticamente, digitar www.example.com pode criar www.example.com.example.com. Remova registros de endereço obsoletos ao substituir um provedor de hospedagem; deixar valores antigos e novos pode enviar visitantes para servidores diferentes.

Aguarde a expiração das respostas em cache

O TTL, tempo de vida, indica por quantos segundos uma resposta DNS pode ficar em cache. Um TTL de 3.600 corresponde a uma hora; 86.400 corresponde a 24 horas. Após uma atualização, visitantes diferentes podem receber respostas diferentes temporariamente. As alterações podem levar 24 horas ou mais para aparecer em todos os lugares.

Para uma mudança planejada, reduza o TTL para 300 segundos pelo menos um período do TTL antigo antes da troca. Reduzi-lo no momento da troca não pode encurtar a duração de uma resposta já armazenada em cache sob o TTL antigo.

Mova o DNS sem perder outros serviços

Você pode deixar o DNS com o registrador e editar os registros ou mudar os servidores de nomes para um novo provedor. Uma mudança de servidores de nomes não copia os registros. Recrie e verifique os registros MX, TXT e outros necessários no novo provedor antes da troca, especialmente quando o e-mail do domínio já funciona.

Verifique as respostas com nslookup www.example.com, dig example.com A +short ou um serviço de consulta DNS e compare-as com as configurações do provedor de hospedagem. Adicione registros curinga apenas de forma deliberada e onde o provedor oferecer suporte. Ao remover um site hospedado, remova também os registros DNS que apontam para ele; um apelido esquecido pode permitir que outra pessoa reivindique o destino abandonado na hospedagem.

O HTTPS envia HTTP por uma conexão TLS criptografada. Ele protege a privacidade e a integridade dos dados em trânsito e permite que o navegador autentique o servidor para o domínio solicitado. O HTTP simples expõe os dados a pessoas que podem observar a conexão.

Um certificado identifica o domínio

Um certificado TLS associa um nome de domínio a uma chave pública e é assinado por uma autoridade certificadora, ou CA, confiável. Ele lista os nomes que cobre e sua data de expiração. Se os visitantes usarem tanto example.com quanto www.example.com, o certificado deve cobrir os dois nomes, mesmo quando um redireciona para o outro: o navegador estabelece uma conexão segura antes de receber esse redirecionamento.

Uma conexão HTTPS não é um julgamento sobre a honestidade de uma empresa. Um site fraudulento pode obter um certificado para um nome que controla. A proteção da conexão e a confiabilidade do site são questões separadas.

Deixe o provedor emitir e renovar o certificado

Muitos provedores de hospedagem estática solicitam automaticamente um certificado gratuito, muitas vezes da Let's Encrypt, assim que o DNS aponta para o provedor e o domínio está configurado. A autoridade certificadora verifica o controle do nome, por exemplo, por meio de um registro DNS ou de um arquivo buscado na web. A emissão pode levar de alguns minutos a cerca de um dia.

Em outubro de 2026, certificados TLS de servidor de confiança pública recém-emitidos têm validade máxima de 200 dias conforme as regras em vigor desde 15 de março de 2026. O máximo passa a 100 dias em março de 2027 e 47 dias em março de 2029. Os certificados clássicos padrão da Let's Encrypt atualmente duram 90 dias, com perfis mais curtos também disponíveis. A renovação automática evita ter de repetir esse trabalho manualmente.

Em um exemplo de 90 dias, um certificado emitido em 1º de março de 2026 expira em 30 de maio. A renovação com 30 dias restantes ocorreria por volta de 30 de abril. A expiração real e o status da renovação estão disponíveis no provedor de hospedagem ou nos detalhes do certificado; não suponha que um registro de domínio ativo também signifique que o certificado esteja em dia.

Redirecione para HTTPS e corrija recursos inseguros

Ative o uso obrigatório de HTTPS do provedor de hospedagem. Ele redireciona requisições http:// para o endereço HTTPS, geralmente com status 301 ou 308. Escolha também um nome de hospedeiro principal, com ou sem www, e redirecione o outro para ele.

Conteúdo misto ocorre quando uma página HTTPS solicita um recurso por http://. Os navegadores bloqueiam scripts, folhas de estilo, quadros e fontes inseguros. Eles tentam atualizar algumas requisições de mídia para HTTPS, o que falha se a origem não puder servi-las assim. Verifique as mensagens do Console e pesquise http:// no código. Use caminhos relativos para seus próprios arquivos e URLs HTTPS funcionais para recursos externos.

O HSTS, política de segurança estrita de transporte HTTP, informa aos navegadores que usem HTTPS por um período definido. Ative-o quando o HTTPS estiver funcionando de forma confiável; os navegadores que tiverem recebido a política não recorrerão ao HTTP simples durante esse período. As terminações .dev e .app são pré-carregadas para funcionar apenas com HTTPS.

Se um aviso de certificado aparecer após conectar um domínio, verifique o DNS, o status de emissão e a cobertura de nomes. O domínio raiz pode funcionar enquanto www falha quando apenas o nome raiz está coberto. Corrija a configuração e aguarde a emissão quando necessário; os visitantes não devem ignorar um aviso de certificado.

Um site publicado muda mesmo quando seus arquivos não mudam. Links externos mudam de lugar, dados de contato ficam desatualizados, domínios se aproximam da expiração e widgets de terceiros mudam. A manutenção mantém o conteúdo correto e a entrega confiável.

Siga o mesmo caminho para cada atualização

Edite o projeto local ou repositório, teste em um navegador, valide o código afetado, implante e verifique as páginas publicadas. Crie uma prévia quando o provedor oferecer suporte. Verifique se uma correção bem-sucedida está na cópia usada para futuras publicações, para que não seja perdida no próximo envio.

Uma alteração de conteúdo também merece uma verificação de conteúdo. Confirme datas, horários de funcionamento, preços e dados de contato em sua fonte atual. Atribua às páginas um responsável ou uma data de revisão. Remova ou substitua informações que não descrevem mais o serviço; um aviso de evento antigo pode enganar visitantes mesmo quando todas as tags são válidas.

Verifique links e tarefas dos visitantes

A deterioração de links é a falha gradual de links à medida que as páginas de destino mudam de lugar ou desaparecem. Use um verificador de links como o W3C Link Checker e depois verifique e corrija as falhas informadas. Quando sua própria página tiver sido movida, um redirecionamento preserva os links antigos que apontam para ela. Para uma página externa, atualize o destino ou remova o link quando não houver substituição útil.

Experimente tarefas reais dos visitantes. Envie um teste pelo formulário de contato e confirme que ele chega. Percorra a navegação com um teclado. Teste um layout para celular. Uma verificação de disponibilidade que recebe uma página não pode comprovar que um formulário ou a navegação funciona.

Mantenha cópias recuperáveis

Faça cópias de segurança do código-fonte e dos arquivos de recursos necessários em pelo menos dois lugares, como um computador e uma unidade externa, armazenamento em nuvem ou repositório. Um problema na conta de hospedagem ou uma implantação equivocada pode remover a cópia publicada, então o provedor de hospedagem não deve ser sua única cópia de segurança. O histórico de versões pode permitir recuperar versões anteriores. Guarde informações suficientes para reconectar o domínio e republicar o site.

Proteja as renovações e o acesso às contas

Ative a renovação automática do domínio e mantenha válido o método de pagamento. Verifique a data de expiração e as mensagens de confirmação. Garanta que as contas do registrador e do provedor de hospedagem usem autenticação de dois fatores e tenham dados de recuperação atualizados. A renovação do certificado também depende de uma configuração de domínio funcional, então verifique o HTTPS após alterações no DNS.

Um monitor de disponibilidade verifica o site repetidamente e alerta você quando ele para de responder. Ferramentas para administradores de sites podem revelar falhas de rastreamento e 404s de endereços antigos. Revise esses relatórios e teste o problema subjacente, em vez de supor que todos os alertas têm a mesma causa.

Programe o trabalho de acordo com o tipo de alteração

Fontes, scripts, mapas e outras incorporações de terceiros podem ficar lentos, mudar ou desaparecer independentemente do seu site. Mantenha poucos e verifique se ainda são necessários. Quando uma licença permitir, hospedar uma cópia local de um arquivo de recurso pode reduzir a dependência de outro servidor. Verifique novamente sua licença e as necessidades de atualização ao substituí-lo.