# websitedevelopment.biz — texto integral

> O texto completo de cada guia neste idioma, para que um motor de respostas leia o catálogo num único pedido. Nada disto falta nas páginas visíveis.

## Quando renovar o site — e quando não renovar
https://websitedevelopment.biz/pt/guides/quando-renovar-o-site
Atualizado a 2026-08-07 · Manutenção

As renovações são mais frequentemente motivadas por tédio do que por dados. Um site parece datado à equipa que olha para ele todos os dias, e essa sensação transforma-se num projeto de dezenas de milhares que raramente melhora os números.

Este guia cobre as razões que justificam uma renovação, as que não justificam, e a alternativa que costuma render mais.

### Razões que justificam uma renovação
São estruturais: não se resolvem com uma paleta nova nem com mais duas páginas.
- O site não é utilizável em telemóvel, e é de lá que vem a maior parte do tráfego.
- A plataforma já não é suportada ou não pode ser atualizada em segurança.
- A equipa não consegue alterar conteúdo sem um programador — isto paralisa tudo o resto.
- O modelo de negócio mudou mesmo e a estrutura já não reflete o que vende.
- O desempenho é estruturalmente mau de forma que não se resolve sem reconstruir.
- O site não cumpre requisitos de acessibilidade que lhe são legalmente aplicáveis.
- Precisa de funcionalidade que a base atual fundamentalmente não suporta.

### Razões que não justificam
São mais frequentes do que as anteriores e produzem os projetos mais caros com menor retorno.
| «Parece datado» | Você vê-o todos os dias; os visitantes não | Renovar tipografia, espaço e imagens |
| «O concorrente tem site novo» | Comparação, não problema | Ver o que o site deles resolve e o seu não |
| «O tráfego está a cair» | Normalmente SEO ou conteúdo, não desenho | Diagnosticar antes de reconstruir |
| «Novo responsável de marketing» | Mudança de dono | Medir primeiro o que já funciona |
| «A conversão é baixa» | Pode ser uma página só | Testar essa página em concreto |
| «Temos logótipo novo» | Atualização de marca | Aplicar a identidade, não reconstruir |
Uma renovação sem problema diagnosticado costuma produzir um site que fica melhor e desempenha pior, porque o que funcionava desapareceu sem querer.

### A alternativa: melhoria dirigida
Para a maioria dos casos que começam como «precisamos de renovar o site», isto rende mais por uma fração do custo e do risco.
- Identifique com análise as páginas que trazem mais tráfego e conversões. Costumam ser menos de dez.
- Descubra onde as pessoas se perdem nessas páginas — gravações de sessão e análise de formulários mostram isto de imediato.
- Resolva primeiro a velocidade. É quase sempre a melhoria mensurável mais barata.
- Reescreva os textos das páginas principais; a falta de clareza custa mais conversão do que o desenho.
- Atualize tipografia, espaço e qualidade de imagem — resolve a maior parte do «parece datado».
- Melhore os percursos de conversão: formulários, contactos, informação de preço.
- Meça depois de cada alteração. Ao fim de três meses sabe se a renovação é mesmo necessária.
Esta abordagem produz dados. Se depois disso renovar mesmo, já sabe o que tem de preservar — e é isso que as renovações costumam destruir.

### Se renovar, faça-o em segurança
Os maiores riscos de uma renovação não são de desenho mas técnicos e mensuráveis.
- Mapeie cada URL existente para o novo antes do lançamento; é onde o tráfego desaparece.
- Registe os números atuais — tráfego, posições, conversões — para poder comparar depois.
- Preserve o que comprovadamente funciona. Uma página que posiciona merece cuidado, não reescrita.
- Faseie o lançamento se puder, para ver o efeito de cada parte.
- Conte com quatro a seis semanas de oscilação e só investigue se continuar a cair depois disso.
- Teste formulários e, numa loja, o pagamento em produção no dia do lançamento.
- Mantenha o site antigo acessível para si durante algum tempo, para poder consultar o que lá estava.

Q: De quanto em quanto tempo devo renovar o site?
A: Não há calendário, e trabalhar a partir de um calendário é exatamente o erro. Um site bem construído com conteúdo atualizado pode desempenhar bem cinco anos ou mais com melhorias contínuas. Renove quando houver um problema concreto que não consegue resolver sem reconstruir — não quando passaram três anos.

Q: Uma renovação vai prejudicar o meu tráfego de pesquisa?
A: Temporariamente quase sempre, e permanentemente se os redirecionamentos forem descuidados. Conte com quatro a seis semanas de oscilação mesmo com execução limpa. O prejuízo duradouro vem de URL não mapeados, de páginas removidas que posicionavam, e de textos reescritos em páginas que estavam a funcionar bem.

Q: Quanto custa uma renovação?
A: Normalmente entre metade e a totalidade do valor de um site novo, porque o trabalho é em grande parte o mesmo mais a migração. É precisamente por isso que vale a pena diagnosticar primeiro: se uma melhoria dirigida por uma fração desse valor resolve o mesmo problema, a renovação é um desvio caro.

Q: Como sei se o problema é o desenho?
A: Veja onde as pessoas desistem. Se saem em poucos segundos, é velocidade ou relevância, não desenho. Se leem e depois saem, é normalmente o texto ou a oferta. Se ficam presas num formulário, é o formulário. O desenho raramente é a causa que a análise aponta, embora seja quase sempre a causa que a intuição aponta.

## Monitorização: saber que o site caiu antes dos clientes
https://websitedevelopment.biz/pt/guides/monitorizacao-de-disponibilidade
Atualizado a 2026-08-07 · Manutenção

A monitorização começa com uma pergunta — o site responde — mas as falhas que custam dinheiro raramente são assim tão simples. O site está no ar e o formulário não envia nada. A página principal carrega e o pagamento falha. O certificado expira daqui a três dias e ninguém está a olhar.

Este guia cobre o que monitorizar de verdade, como configurar alertas que recebem atenção, e o que fazer quando um dispara.

### O que monitorizar para além de «está no ar»
Um ping à página principal apanha as falhas óbvias. Estas verificações apanham as silenciosas.
- Estado HTTP e conteúdo: não só que responde algo, mas que a página contém texto esperado.
- Validade do certificado: alerta com trinta dias de antecedência, não no próprio dia.
- Expiração do domínio: a mais rara e mais catastrófica, e inteiramente evitável.
- Envio de formulários: um envio de teste periódico que confirma que o e-mail chega mesmo.
- Percurso de pagamento numa loja: a falha silenciosa mais cara que existe.
- Tempo de resposta: uma tendência a subir avisa frequentemente dias antes de uma falha real.
- Taxa de erros nos registos: subida de erros 500 que os visitantes não reportam.
- Tarefas agendadas: processos que param em silêncio sem ninguém notar.
A verificação de formulários é a que mais rende por esforço. Formulários de contacto que falham em silêncio custam pedidos durante semanas antes de alguém reparar.

### Configurar alertas que funcionam
Um alerta que ninguém lê é pior do que nenhum alerta, porque cria a sensação de estar coberto.
| Frequência de verificação | A cada minuto em sites críticos | Cinco minutos são até cinco minutos de falha silenciosa |
| Confirmação de segundo local | Ativa | Evita alertas por falha de rede do verificador |
| Limiar de alerta | Duas falhas consecutivas | Evita ruído por uma falha pontual |
| Canal | E-mail mais SMS ou chat | Só e-mail não é lido de noite |
| Destinatário | Uma pessoa nomeada, não uma caixa de grupo | Caixas de grupo significam que ninguém é dono |
| Alerta de recuperação | Ativo | Sem ele, não sabe que terminou |
| Janela de manutenção | Definida antes de alterações planeadas | Evita habituação a alertas falsos |
A fadiga de alertas é a forma mais comum de a monitorização falhar. Dois alertas falsos por semana e ninguém olha para o terceiro.

### Quando um alerta dispara
Um procedimento curto que poupa tempo e, sobretudo, evita que alguém mude algo em pânico.
- Confirme a falha a partir de outra rede — dados móveis servem bem. Uma parte dos alertas é local.
- Verifique a página de estado do alojamento antes de investigar seja o que for.
- Veja o que mudou por último: uma publicação, uma atualização de extensão, uma alteração de DNS.
- Verifique certificado e domínio — os dois explicam uma parte surpreendente das falhas súbitas.
- Coloque uma página de manutenção se for preciso, para que os visitantes vejam algo útil.
- Reverta antes de diagnosticar se uma alteração recente for a causa provável.
- Registe depois o que foi e quanto durou. Três desses registos mostram um padrão.

### De quanta disponibilidade precisa mesmo
As percentagens de disponibilidade soam abstratas até serem convertidas em tempo por ano.
| 99 % | Mais de três dias | Pouco para um site de empresa |
| 99,5 % | Quase dois dias | Alojamento partilhado barato |
| 99,9 % | Quase nove horas | Bom alojamento; objetivo razoável |
| 99,95 % | Pouco mais de quatro horas | Alojamento gerido com suporte |
| 99,99 % | Cerca de uma hora | Exige redundância e engenharia real |
Para a maioria dos sites de empresa, 99,9 % é um bom objetivo e o dinheiro rende mais em recuperação rápida do que a perseguir mais um nove.

Q: Com que frequência devo verificar?
A: A cada minuto para algo por onde passa receita, a cada cinco minutos para um site institucional. O intervalo importa porque é o mínimo de tempo que uma falha passa despercebida. Mais importante do que o intervalo é que a verificação confirme o conteúdo da página em vez de apenas confirmar que o servidor devolveu alguma coisa.

Q: A monitorização gratuita chega?
A: Para um site com verificações de cinco minutos e alertas por e-mail, normalmente sim. Paga-se por intervalos curtos, vários locais, alertas por SMS e verificações transacionais como um percurso de pagamento. Para uma loja isso compensa; para um site institucional normalmente não.

Q: Porque é que o site parece no ar e a monitorização diz que caiu?
A: Normalmente cache de DNS ou problema regional: o seu resolvedor ainda tem o endereço antigo, ou a falha afeta uma rede. É por isso que a confirmação de um segundo local é valiosa. Verifique sempre a partir de outra rede antes de classificar o alerta como falso — essa suposição é como se ignoram falhas verdadeiras.

Q: O que é uma falha silenciosa?
A: Uma falha em que o site parece funcionar mas algo essencial não funciona: o formulário de contacto não envia e-mail, o pagamento falha no último passo, ou a pesquisa não devolve nada. A monitorização de disponibilidade não apanha isso, porque a página carrega bem. Para isso são precisas verificações funcionais que executem mesmo a ação.

## Estratégia de cópias de segurança que funciona mesmo
https://websitedevelopment.biz/pt/guides/estrategia-de-copias-de-seguranca
Atualizado a 2026-08-07 · Manutenção

Praticamente toda a gente tem cópias de segurança. Muito menos gente tem cópias comprovadamente restauráveis, e isso é a única coisa que conta no dia em que precisa delas.

Este guia cobre o que entra numa cópia, onde deve ficar, quanto tempo se guarda, e como fazer o teste de restauro que transforma uma suposição num facto.

### O que entra numa cópia completa
Uma cópia parcial parece uma cópia até ao momento em que precisa dela. Esta é a lista completa.
- Base de dados: todo o conteúdo, utilizadores, definições, e numa loja encomendas e clientes.
- Ficheiros carregados: imagens, documentos, anexos — muitas vezes a maior parte em volume.
- Código e temas: sobretudo personalizações que não existem em mais lado nenhum.
- Configuração do servidor: hosts virtuais, regras de redirecionamento, tarefas agendadas.
- Certificados e variáveis de ambiente: o que se esquece até o restauro encravar.
- Um procedimento de restauro escrito: por que ordem, que credenciais, que definições de DNS.
- Em código à medida, o controlo de versões substitui a cópia do código, mas não a base de dados nem os ficheiros.
Os ficheiros carregados são o que mais frequentemente fica de fora das cópias automáticas, por estarem fora do caminho do CMS. Confirme especificamente que vão incluídos.

### Frequência e retenção
A frequência certa decorre de uma pergunta: quanto trabalho se pode dar ao luxo de repetir?
| Site institucional estático | A cada alteração, mais mensal | Alguns meses |
| Site com blogue | Diária | Trinta dias, mais pontos mensais |
| Loja online | Horária ou contínua | Trinta dias mínimo; encomendas mais tempo |
| Aplicação com dados de utilizadores | Contínua com registo de transações | Conforme política de retenção |
| Antes de cada atualização | Manual, sempre | Até a atualização provar estar bem |
Guardar várias gerações pesa mais do que a frequência elevada. Uma invasão detetada duas semanas depois torna inútil qualquer cópia dessas duas semanas.

### Onde devem ficar as cópias
O local determina contra que tipo de falha está protegido. É aqui que a maioria das configurações fica curta.
| Mesmo servidor | Apagar conteúdo por engano | Falha do servidor, ransomware, perda de conta |
| Mesma conta de alojamento | Falha do servidor | Suspensão de conta, acesso comprometido |
| Armazenamento na nuvem separado | Praticamente tudo | Perda das credenciais desse armazenamento |
| Cópia local | Falha do fornecedor | Exige disciplina para se manter atual |
| Três cópias, dois suportes, uma fora | Praticamente tudo | Nada de relevante |
Pelo menos uma cópia deve estar completamente fora da infraestrutura e da conta do seu alojamento. Ransomware e suspensões levam tudo o que estiver ao alcance.

### O teste de restauro
É a parte que transforma cópias de suposição em facto, e a que praticamente toda a gente salta.
- Restaure uma cópia para um ambiente de testes trimestralmente, não para produção.
- Cronometre quanto demorou. Esse número é o seu tempo real de recuperação, e costuma ser maior do que se pensa.
- Verifique que o conteúdo está completo — incluindo imagens, não só texto.
- Verifique que formulários, entrada e, numa loja, o pagamento funcionam.
- Anote o que faltou ou correu mal e corrija o processo de cópia.
- Documente o restauro para que outra pessoa o consiga fazer quando você não estiver contactável.
- Repita depois de qualquer alteração significativa ao site ou ao alojamento.
A descoberta mais comum num primeiro teste de restauro é que faltam ficheiros ou que ninguém tem as credenciais da base de dados. É precisamente por isso que se testa num dia calmo.

Q: As cópias do meu alojamento chegam?
A: Como única cópia, não. São úteis e normalmente rápidas, mas estão dentro da mesma conta que pode perder por disputa, suspensão ou acesso comprometido. Mantenha as cópias do alojamento e uma cópia independente noutro sítio. A segunda existe precisamente para o cenário em que a primeira está inacessível.

Q: Com que frequência devo fazer cópias?
A: Com frequência suficiente para que a perda entre duas cópias seja aceitável. Um blogue que publica semanalmente pode ser diário. Uma loja não — perder um dia de encomendas é um problema operacional, não um incómodo, por isso aí é horário ou contínuo. Decida perguntando quanto trabalho está disposto a repetir.

Q: Quanto tempo devo guardar cópias?
A: Trinta dias de pontos recentes cobre a maioria dos incidentes, mais pontos mensais para prazo mais longo. A razão para o prazo longo é que os problemas são frequentemente detetados tarde — uma importação corrompida ou uma invasão de três semanas atrás. Dados de encomendas e faturação têm ainda prazos legais de conservação.

Q: E se não tenho cópia e o site desapareceu?
A: Pergunte primeiro ao alojamento — muitos têm instantâneos que você não gere, por vezes de alguns dias. Depois disso, o Wayback Machine e a cache dos motores podem devolver conteúdo visível, mas não base de dados, nem ficheiros, nem encomendas. É salvamento, não recuperação, e é a razão pela qual o teste de restauro existe.

## Segurança de sites: guia prático
https://websitedevelopment.biz/pt/guides/seguranca-de-sites-guia-pratico
Atualizado a 2026-08-07 · Manutenção

A maioria dos sites não é atacada de propósito. É encontrada por analisadores automáticos que varrem a internet à procura de vulnerabilidades conhecidas e palavras-passe fracas. Isso é boa notícia, porque significa que medidas básicas travam a maior parte dos ataques.

Este guia percorre essas medidas, aproximadamente por ordem de risco removido por esforço investido.

### Acessos: onde começam quase todas as invasões
Credenciais roubadas ou adivinhadas são a forma mais comum de sites pequenos caírem — mais do que qualquer vulnerabilidade técnica.
- Autenticação de dois fatores em todas as contas de administrador, sem exceção.
- Palavras-passe únicas geradas por um gestor; palavras-passe reutilizadas vazam noutro sítio e são testadas aqui.
- Remova contas de pessoas que saíram e de agências antigas — isto é quase sempre esquecido.
- Dê as permissões mínimas necessárias; um editor não precisa de ser administrador.
- Limite tentativas de entrada e bloqueie após falhas repetidas.
- Proteja também o que está à volta: alojamento, DNS, registador de domínio e e-mail. Perder o DNS é pior do que perder o site.
- Use SFTP ou chaves SSH, nunca FTP simples com palavra-passe.
O registador de domínio é a conta que mais frequentemente fica sem dois fatores e a que causa mais estragos se cair.

### Atualizações e superfície de ataque
Cada peça de software instalada é uma peça que tem de ser mantida atualizada. O trabalho de segurança mais barato é remover o que não usa.
| Núcleo do CMS atualizado | Vulnerabilidades conhecidas são procuradas em dias |
| Extensões atualizadas | A porta de entrada mais comum em sites WordPress |
| Remover extensões não usadas | Desativada não é segura; o código continua lá |
| Remover temas não usados | Mesma razão, ainda mais esquecido |
| Versão de PHP suportada | Versões antigas deixam de receber correções |
| Pacotes do servidor atualizados | Cabe ao alojamento em planos geridos — confirme |
| Dependências em código à medida | As bibliotecas também envelhecem |
Aplique atualizações em ambiente de testes e depois teste formulários e, numa loja, o percurso de pagamento. Uma atualização que parte um formulário em silêncio é um tipo próprio de avaria.

### Proteção da aplicação e do servidor
As medidas que cobrem vulnerabilidades técnicas em vez de acessos.
- Valide e limpe todas as entradas no servidor. Verificação no navegador é conveniência, não segurança.
- Use consultas preparadas em todo o acesso à base de dados — isto fecha a injeção de SQL.
- Escape a saída ao apresentar, para evitar scripting entre sites.
- HTTPS em todo o lado, com HSTS e certificado de renovação automática.
- Configure cabeçalhos de segurança: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy.
- Restrinja carregamentos por tipo e tamanho, e guarde-os fora da pasta pública.
- Desative a apresentação de erros em produção; as mensagens dizem ao atacante o que está a correr.
- Considere uma firewall de aplicação num CMS com muitas extensões.

### Cópias e recuperação depois de uma invasão
A segurança falha às vezes. O que acontece depois depende inteiramente do que preparou antes.
- Guarde cópias fora do servidor. Uma cópia na mesma máquina é cifrada ou apagada com o resto.
- Guarde várias gerações. Se a invasão só for detetada duas semanas depois, a cópia de ontem também está comprometida.
- Teste o restauro trimestralmente. É o passo que mais frequentemente falta.
- Numa invasão: tire o site do ar ou ponha-o em modo de manutenção antes de fazer mais alguma coisa.
- Mude todas as palavras-passe — CMS, alojamento, base de dados, FTP, DNS — antes de restaurar.
- Restaure a partir de uma cópia anterior à invasão, e atualize tudo antes de voltar a publicar.
- Descubra como entraram. Restaurar sem encontrar a causa significa que volta a acontecer.
Numa violação com dados pessoais existem obrigações de notificação com prazos curtos. Saiba antes quem avalia isso, não durante o incidente.

Q: O WordPress é inseguro?
A: O núcleo é razoavelmente bem mantido; o risco está quase sempre em extensões, temas e palavras-passe fracas de administrador. Um site WordPress com dois fatores, poucas extensões e atualizações em dia está bem. Um site com quarenta extensões, metade sem atualização há dois anos, é uma questão de tempo.

Q: Preciso de uma extensão de segurança?
A: São úteis para limitar tentativas de entrada, vigiar ficheiros e enviar alertas, mas não substituem nada da lista acima. Uma extensão de segurança num site com extensões desatualizadas e palavra-passe partilhada não resolve o problema real. Veja-a como detetor de fumo, não como construção resistente ao fogo.

Q: O que faço se o meu site for invadido?
A: Tire-o do ar, mude todas as palavras-passe incluindo alojamento e DNS, e restaure a partir de uma cópia limpa anterior à invasão. Atualize tudo antes de voltar a publicar, e descubra como entraram — senão repete-se em semanas. Se houver dados pessoais envolvidos, há obrigações de notificação com prazos curtos.

Q: O HTTPS protege o site de invasões?
A: Não, e é um mal-entendido frequente. O HTTPS cifra o tráfego entre visitante e servidor, o que impede interceção e manipulação em trânsito. Não faz nada contra palavras-passe fracas, extensões desatualizadas ou injeção de SQL. É necessário e completamente insuficiente.

## Manutenção de sites: o que inclui e quanto custa
https://websitedevelopment.biz/pt/guides/guia-de-manutencao-de-sites
Atualizado a 2026-08-07 · Manutenção

Um site não é um produto terminado mas um sistema em funcionamento. O software envelhece, as integrações partem, os certificados expiram e o conteúdo desatualiza-se. Manutenção é o trabalho que impede que essas coisas aconteçam todas ao mesmo tempo.

Este guia cobre o que é preciso fazer, com que ritmo, quanto custa razoavelmente, e como avaliar uma proposta de manutenção.

### O que a manutenção inclui realmente
«Manutenção» é uma palavra vaga nos orçamentos. Estas são as componentes que devem estar por trás dela.
- Atualizações de software: núcleo do CMS, extensões, temas, pacotes do servidor — e testes depois.
- Cópias de segurança: automáticas, guardadas fora do servidor, e restauradas periodicamente como teste.
- Vigilância de segurança: alertas de vulnerabilidades, integridade de ficheiros, entradas suspeitas.
- Monitorização de disponibilidade: alerta quando o site cai, não quando um cliente telefona.
- Certificados e domínios: renovações que expiram em silêncio e tiram o site do ar.
- Verificações de desempenho: o peso da página cresce sozinho à medida que entra conteúdo.
- Ligações partidas e erros: ligações internas e 404 que se acumulam com o tempo.
- Atualizações de conteúdo: preços, equipa, serviços, o ano no rodapé.
- Análise e relatório: alguém que efetivamente olhe para o que o site está a fazer.
Pergunte em qualquer proposta de manutenção quais destes pontos estão incluídos. «Manutenção» sem discriminação significa, na prática, correr atualizações.

### Um ritmo realista
Nem tudo é mensal. Esta é uma divisão praticável para um site institucional típico.
| Contínuo | Monitorização, cópias automáticas, alertas de segurança |
| Semanal | Aplicar atualizações de segurança, verificar formulários |
| Mensal | Ronda completa de atualizações com teste, ligações partidas, registo de erros |
| Trimestral | Testar restauro de cópia, medir desempenho, verificar acessibilidade |
| Semestral | Ronda de conteúdo: páginas desatualizadas, preços, equipa |
| Anual | Rever dependências e versão de PHP, remover extensões não usadas |
| A cada alteração | Testar formulários e, numa loja, o percurso de pagamento |
O teste trimestral de restauro é o que toda a gente salta e o que realmente conta. Uma cópia que nunca restaurou é uma suposição, não uma cópia.

### Quanto custa
Os preços de manutenção variam muito porque cobrem trabalhos muito diferentes. Ordens de grandeza mensais e o que esperar de cada nível.
| Só alojamento | Baixo | O servidor corre; mais nada |
| Manutenção básica | Dezenas de euros | Atualizações, cópias, monitorização |
| Gerido | Cem a algumas centenas | O anterior mais testes, segurança, pequenas alterações |
| Gerido com horas | Algumas centenas ou mais | O anterior mais orçamento de horas para trabalho |
| Loja online | Substancialmente mais | Testar pagamento, integrações, stock |
Uma regra prática útil é um a dois por cento do custo de construção por mês num site normal. Se uma proposta ficar muito abaixo disso, pergunte exatamente o que inclui.

### O que corre mal sem manutenção
Os modos de falha são previsíveis e quase sempre mais caros de resolver do que de prevenir.
- Uma extensão desatualizada com vulnerabilidade conhecida é explorada automaticamente — é a forma mais comum de sites pequenos serem invadidos.
- O certificado expira e todos os visitantes veem um aviso antes de alguém reparar.
- Uma versão de PHP é descontinuada pelo alojamento e o site parte numa manhã sem nada ter mudado.
- Os formulários deixam de enviar em silêncio; descobre quando alguém pergunta porque não respondeu.
- As cópias corriam mas não restauravam, e isso descobre-se no pior momento.
- O peso da página triplicou com três anos de imagens sem otimizar.
- Recuperar de uma invasão custa tipicamente vários múltiplos de um ano de manutenção.

Q: Preciso mesmo de contrato de manutenção?
A: Precisa do trabalho; se passa por contrato é outra questão. Se consegue correr atualizações mensais com fiabilidade, testar cópias e responder a alertas, faça-o internamente. Se não consegue — e a maioria das empresas não consegue — o contrato é a forma mais barata de garantir que é feito. Um site estático sem CMS precisa de muito pouco.

Q: O que acontece se adiar atualizações?
A: Num mês, normalmente nada. Em seis, as atualizações tornam-se arriscadas porque muda demasiado de uma vez, e com vulnerabilidades conhecidas é analisado e explorado automaticamente — os atacantes procuram números de versão, não empresas. A ironia é que adiar torna as atualizações mais perigosas, não mais seguras.

Q: A minha equipa pode fazer a manutenção?
A: Em parte, e é frequentemente a configuração mais barata. Conteúdo, preços e páginas de equipa são vossos. Atualizações, testes de restauro, segurança e testar depois de atualizar pertencem a alguém com responsabilidade técnica. Divida o contrato por essa linha em vez de subcontratar tudo ou nada.

Q: Quanta manutenção precisa um site estático?
A: Muito menos. Sem CMS, base de dados ou extensões, não há software a envelhecer. Fica a renovação de domínio e certificado, a monitorização e a atualidade do conteúdo. É um dos argumentos mais fortes a favor de sites estáticos em projetos que não precisam de edição diária.

## Como ser programador web: um percurso realista
https://websitedevelopment.biz/pt/guides/como-ser-programador-web
Atualizado a 2026-08-07 · Contratar programadores

O desenvolvimento web é das poucas profissões técnicas em que trabalho demonstrável pesa mais do que um diploma. Isso torna-a acessível e simultaneamente confusa, porque não há percurso prescrito e há material a mais.

Este guia dá uma ordem que funciona, um enquadramento realista de tempo, e o que empregadores e clientes avaliam de facto.

### O que aprender, e por que ordem
A ordem conta. Cada passo assenta no anterior, e saltar deixa lacunas que mais tarde se manifestam como confusão persistente.
- HTML e CSS a fundo. Não superficialmente: semântica, layout com flexbox e grid, desenho responsivo, formulários acessíveis.
- Bases de JavaScript. A linguagem em si antes de tocar num framework — funções, arrays, objetos, assíncrono, o DOM.
- Controlo de versões com Git. Aprenda cedo; todas as equipas usam e todos os empregadores esperam.
- Como funciona a web. HTTP, DNS, alojamento, o que acontece entre escrever um endereço e ver a página.
- Um framework, a fundo. Escolha um e aprenda-o bem; três superficialmente vale menos do que um dominado.
- Servidor: uma linguagem e uma base de dados. PHP, Python ou Node — mais SQL, que aparece em todo o lado.
- Publicar. Pôr algo a funcionar na internet, com domínio e certificado.
- Bases de segurança e desempenho. É o que separa código que funciona de código que se pode lançar.
O erro mais comum é começar diretamente por um framework. Sem bases de JavaScript aprende padrões sem os perceber, e isso bloqueia precisamente quando algo foge ao tutorial.

### Quanto tempo demora
Enquadramentos realistas com cerca de vinte horas por semana. Dedicação a tempo inteiro encurta isto, mas não proporcionalmente.
| Primeira página estática | Algumas semanas | HTML e CSS, responsivo |
| Primeiro site interativo | Dois a três meses | JavaScript, formulários, chamar APIs |
| Primeiro projeto completo | Quatro a seis meses | Front-end, servidor, base de dados, publicado |
| Pronto para trabalho júnior | Seis a doze meses | Portefólio, Git, um framework |
| Trabalhar com autonomia | Dois a três anos | Do problema à solução, sem supervisão |
| Sénior | Cinco anos ou mais | Arquitetura, compromissos, orientar outros |
Estes números pressupõem construir, não assistir. Vinte horas de vídeo por semana rendem uma fração de vinte horas de projetos próprios com problemas reais.

### O que um portefólio deve conter
Três projetos terminados valem mais do que vinte cópias de tutoriais. O que se avalia não é a dimensão mas o acabamento.
- Três projetos publicados num endereço real, não apenas num repositório.
- Pelo menos um com base de dados, autenticação e dados que grava e volta a ler.
- Pelo menos um que resolva algo real — para si, para uma associação, para um pequeno negócio.
- Código limpo num repositório público com histórico de commits legível.
- Um README por projeto a explicar o que faz, como se executa e que decisões tomou.
- Nada de cópias de tutoriais. Quem avalia reconhece-as de imediato e não dizem nada sobre si.
- Devem carregar depressa e funcionar num telemóvel — está a demonstrar o que entregaria profissionalmente.
O README a explicar as decisões é a parte que mais se nota e a que menos vezes existe. Mostra que pensa em compromissos, não apenas em código que funciona.

### O primeiro trabalho pago
É o passo mais difícil, e a maioria dos caminhos até lá começa em pessoas que já conhece.
| Site para um conhecido ou associação | Alta | Pequeno e real; o melhor primeiro projeto |
| Estágio | Média | Acompanhamento é o maior acelerador que existe |
| Vaga de júnior | Média | Exige portefólio, Git e um framework |
| Plataformas de freelancing | Baixa no início | Muito guiada por preço sem avaliações |
| Contribuir para código aberto | Média | Prova visível de saber colaborar |
| Pequenos negócios locais | Alta | Muitos não têm site utilizável |
| Comunidades e networking | Alta ao longo do tempo | A maioria dos primeiros trabalhos vem de pessoas |
Aceite o primeiro projeto pago pequeno e terminável. Um site simples concluído vale mais do que um projeto ambicioso que nunca entrega.

Q: Preciso de um curso superior?
A: Não. O desenvolvimento web é das poucas profissões técnicas em que trabalho demonstrável pesa mais do que formação. Uma base em informática ajuda nos fundamentos e junto de alguns empregadores, mas um portefólio forte com projetos publicados abre mais portas na prática do que um diploma sem trabalho para mostrar.

Q: Começar pelo front-end ou pelo servidor?
A: Front-end, quase sempre. Vê resultados imediatos, o que torna a aprendizagem muito mais sustentável, e HTML e CSS são a base sobre a qual tudo assenta. Acrescente o servidor quando estiver confortável com JavaScript. Quem domina ambos é bastante mais valioso como independente e em equipas pequenas.

Q: Que framework devo aprender?
A: Olhe para as vagas na sua região e escolha o mais pedido. Mais importante do que a escolha é aprender um a fundo: os frameworks partilham conceitos, por isso o segundo aprende-se numa fração do tempo. Conhecer três superficialmente vale menos do que dominar um.

Q: Ainda vale a pena com ferramentas de IA?
A: Sim, mas a profissão desloca-se. A IA gera código depressa e acelera muito o trabalho rotineiro; o que não faz é decidir o que construir, avaliar se está correto, ou desenhar um sistema que se consiga manter daqui a três anos. Essas competências valem mais, não menos. O que desaparece é trabalho que era só transcrever código.

## SEO para lojas online: o guia prático
https://websitedevelopment.biz/pt/guides/seo-para-lojas-online
Atualizado a 2026-08-07 · Comércio eletrónico

O SEO de lojas difere do SEO comum em três pontos: tem milhares de páginas parecidas entre si, o catálogo muda constantemente, e as páginas comerciais são precisamente aquelas onde a concorrência é mais forte.

Este guia cobre o que funciona em cada uma dessas frentes, e o que o prejudica em silêncio enquanto pensa que está a ajudar.

### As categorias são as suas principais páginas de entrada
O erro mais comum em SEO de lojas é dar toda a atenção às páginas de produto. As categorias correspondem à procura mais ampla e é por isso que posicionam para os termos com volume.
- Dê a cada categoria texto descritivo real — não cem palavras de enchimento sob a grelha, mas algo que responda a dúvidas de compra.
- Intitule a categoria como as pessoas procuram, não como se chama a sua taxonomia interna.
- Ligue às subcategorias e de volta, para que a hierarquia seja legível a visitantes e a rastreadores.
- Acrescente ajuda à decisão: tamanhos, diferenças de material, o que verificar. É por isso que uma categoria vence uma lista de produtos.
- Mantenha os produtos principais acima da dobra; uma página que começa com quinhentas palavras perde compradores.
- Um URL canónico por categoria, e ordenações fora do índice.
Uma página de categoria com um guia de compra a sério costuma ser a página com melhor retorno que se pode escrever numa loja.

### Páginas de produto e conteúdo duplicado
As descrições do fabricante estão iguais em cem outras lojas. Não é penalizado por isso, mas também não lhe dá qualquer razão para ficar acima dessas lojas.
| Texto de fabricante idêntico | Reescrever os produtos principais; deixar a cauda longa |
| Variantes como páginas separadas | Uma página canónica, variantes como opções |
| Páginas de produto fracas | Acrescentar o que os compradores perguntam |
| Sem avaliações | Recolher avaliações — conteúdo único que não escreve |
| Produto em várias categorias | Um URL canónico, ligado a partir de todas |
| Produtos sem fotografia própria | Fotografias reais; aumentam conversão e permanência |
Não reescreva tudo. Identifique os vinte por cento de produtos que representam a maior parte da receita ou do volume de pesquisa e invista aí.

### Filtros, paginação e produtos esgotados
São as três questões técnicas específicas de lojas e as que mais frequentemente correm mal.
- Combinações de filtros: noindex, follow por omissão. Indexe apenas as poucas que correspondem a procura real, como «botas de pele pretas».
- Ordenações: nunca um URL indexável separado — os mesmos produtos, outra ordem.
- Paginação: ligações reais rastreáveis, cada página com canónico autorreferente.
- Esgotado temporariamente: mantenha a página no ar com aviso claro e alternativas. Não a remova.
- Descontinuado: 301 para o produto sucessor, ou para a categoria se não houver.
- Produtos sazonais: mantenha o URL o ano inteiro; sinais acumulados são difíceis de recuperar.
- Nunca ponha uma página de produto em 404 enquanto tiver ligações ou tráfego.

### Dados estruturados e as armadilhas
A marcação de produto é dos poucos sítios onde trabalho de SEO pode gerar uma ação manual, por isso vale a pena ser preciso.
| Product | Preço e disponibilidade refletem a página | Divergência gera ação manual |
| AggregateRating | Só com avaliações reais e visíveis | Avaliações inventadas são violação clara |
| Offer | Moeda e tratamento de IVA corretos | Preços errados nos resultados custam confiança |
| Breadcrumb | Deve seguir o caminho visível | Ignorado se divergir |
| Availability | Atualizar quando o stock muda | «Em stock» quando esgotado frustra compradores |
| FAQ | Só perguntas visíveis na página | Conteúdo escondido viola as diretrizes |
Gere a marcação de produto a partir dos mesmos dados que renderizam a página. Marcação mantida à mão dessincroniza-se dos preços reais em semanas.

Q: Tenho de reescrever todas as descrições de produto?
A: Não todas. Identifique os produtos que representam a maior parte da receita ou do volume de pesquisa — normalmente uma pequena fração do catálogo — e escreva esses bem. A cauda longa pode manter o texto do fabricante; dificilmente concorre de qualquer forma. Esta priorização rende muito mais do que ajustar dez mil produtos superficialmente.

Q: O que faço com produtos esgotados?
A: Se for temporário, mantenha a página no ar com aviso claro, data prevista se a tiver, e alternativas. Se for definitivo, 301 para o produto sucessor mais próximo. Nunca ponha essa página em 404 enquanto tiver ligações ou tráfego — está a deitar fora sinais acumulados que levaram meses a construir.

Q: As páginas de filtros devem ser indexadas?
A: Por omissão não. Um punhado de combinações que correspondem a procura real pode ser tornado indexável de propósito e tratado como página de entrada com texto próprio. As restantes — que são milhares — devem ficar em noindex, follow. Filtros sem restrição são a principal fonte de poluição de índice em lojas.

Q: As avaliações de produto ajudam no SEO?
A: Sim, de duas formas: acrescentam conteúdo único que não tem de escrever, e aumentam a conversão de forma notável. O que não deve fazer é acrescentar marcação de avaliação sem avaliações reais na página — é uma violação clara das diretrizes e uma das formas de as lojas apanharem uma ação manual.

## Perguntas a fazer a um programador web antes de assinar
https://websitedevelopment.biz/pt/guides/perguntas-a-fazer-a-um-programador-web
Atualizado a 2026-08-07 · Contratar programadores

Está a avaliar alguém que vai produzir trabalho que você não consegue verificar sozinho. A solução não é tornar-se mais técnico mas fazer perguntas cujas respostas se conseguem avaliar sem conhecimentos técnicos.

Este guia dá essas perguntas, agrupadas por fase, com o que uma resposta forte contém em cada uma.

### Sobre processo e colaboração
Estas preveem mais sobre como o projeto vai correr do que qualquer pergunta técnica.
- Como decorre um projeto típico convosco? Uma resposta forte nomeia fases, momentos de decisão e o que se espera de si.
- Quem trabalha efetivamente nisto, e quantos projetos tem em paralelo? Isto prevê o prazo melhor do que o cronograma.
- Com que frequência falamos, e como? Respostas vagas aqui transformam-se em silêncio mais tarde.
- Do que precisam de mim, e quando? Quem responde a isto com precisão já viu projetos atrasarem por conteúdo.
- O que acontece se quisermos mudar algo a meio? Deve haver um procedimento, não um «logo se vê».
- Conte-me um projeto que correu mal. «Não tivemos nenhum» é, por si, uma resposta.

### Sobre técnica e escolhas
Não precisa de perceber a técnica; precisa de conseguir avaliar se a pessoa consegue explicar as suas escolhas.
| Em que vão construir, e porquê? | Uma razão ligada à sua situação |
| O que consigo alterar sozinho depois? | Uma lista concreta, não «tudo» |
| Como garantem que é rápido? | Medidas concretas e métricas |
| Como tratam o telemóvel? | Desenhar a partir do móvel, não «é responsivo» |
| O que fazem quanto a acessibilidade? | Uma norma e como a verificam |
| O que fazem quanto a segurança? | Atualizações, cópias, acessos, HTTPS |
| Usam temas existentes ou constroem? | Uma resposta honesta com o compromisso |
Repare se as respostas se ligam à sua situação ou ficam genéricas. «Usamos sempre X» informa menos do que «para o que precisa, X encaixa, porque».

### Sobre conteúdo, SEO e lançamento
A área onde os projetos mais atrasam e onde os pressupostos mais divergem.
- Quem escreve os textos? É a pergunta mais importante da conversa e a mais saltada.
- Quem fornece as fotografias, e o banco de imagens está incluído?
- Quem introduz o conteúdo no sistema? Com duzentas páginas, isso é trabalho a sério.
- O que fazem aos URL existentes? A resposta tem de incluir redirecionamentos. Se não incluir, é um problema.
- O que está incluído em SEO? O trabalho técnico pertence ao projeto; a estratégia de conteúdo é separada.
- Como testam antes do lançamento? Deve haver ambiente de testes e uma lista.
- O que acontece no dia do lançamento, e quem está contactável?
- Recebo formação ou documentação?

### Sobre o período depois da entrega
As perguntas que determinam se estará satisfeito daqui a dois anos, e as menos feitas durante a venda.
| Quanto custa a manutenção por mês? | Evita uma surpresa logo após o lançamento |
| O que inclui a manutenção? | «Manutenção» sem lista significa pouco |
| Em quanto tempo respondem numa avaria? | Define a expectativa agora, não durante a avaria |
| E se eu quiser continuar com outra pessoa? | Testa a transição |
| De quem é o código e o alojamento? | Pergunte isto antes de assinar |
| O que acontece se fecharem? | Mais relevante com freelancer ou agência pequena |
| Quem tem acesso às minhas contas? | Deve voltar para si no final |

Q: Qual é a pergunta mais importante?
A: «Quem escreve os textos?» O conteúdo atrasa mais projetos de sites do que qualquer fator técnico, e ambas as partes assumem com demasiada frequência que é a outra a fazê-lo. Se a resposta for «vocês», pergunte para quando tem de estar pronto e o que acontece se atrasar — e garanta que isso fica no contrato.

Q: Devo fazer perguntas técnicas se não consigo avaliar a resposta?
A: Sim, mas avalie a explicação em vez do conteúdo. Quem consegue explicar uma escolha em linguagem simples e nomear as suas desvantagens percebe o que está a fazer. Quem se esconde atrás de jargão ou nunca aponta um inconveniente é o risco. Essa distinção faz-se sem conhecimentos técnicos.

Q: É razoável pedir referências?
A: Completamente, e ligue mesmo a uma. Não pergunte se ficaram satisfeitos mas o que correu mal e como foi resolvido, e como foi a colaboração depois do lançamento. Esta última é a pergunta mais preditiva e a menos feita — antes do lançamento toda a gente está contactável.

Q: E se o fornecedor se incomodar com estas perguntas?
A: Isso é, em si, a resposta. São perguntas normais de um cliente que vai gastar uma quantia relevante, e os profissionais esperam-nas. Irritação perante perguntas razoáveis antes da assinatura prevê como será quando reportar um problema depois do lançamento.

## Integrar meios de pagamento: o que está realmente envolvido
https://websitedevelopment.biz/pt/guides/integrar-meios-de-pagamento
Atualizado a 2026-08-07 · Comércio eletrónico

Integrar um fornecedor de pagamentos não é tecnicamente difícil — os serviços modernos têm boa documentação e exemplos funcionais. O que torna isto complicado é tudo o que está fora do caminho feliz: pagamentos falhados, devoluções, estornos, encomendas duplicadas, e o que acontece quando o cliente fecha o separador a meio.

Este guia cobre a integração e, com mais detalhe, os casos limite onde o dinheiro se perde de verdade.

### Escolher os meios que o seu mercado usa
As preferências de pagamento são fortemente regionais. Oferecer os meios errados perde vendas no pagamento, que é o sítio mais caro para perder alguém.
| MB Way | Essencial em Portugal | Confirmação imediata, muito usado |
| Referência multibanco | Muito usado em Portugal | Confirmação diferida; encomendas ficam pendentes |
| Cartão | Internacional e empresarial | Custo maior, risco de estorno |
| PayPal | Internacional, marca reconhecida | Custo maior, processo de disputa próprio |
| Apple Pay e Google Pay | Móvel, aumenta conversão | Exige HTTPS e verificação de domínio |
| Pagamento a prazo | Cresce em vários mercados | O fornecedor assume o risco, por uma percentagem |
| Transferência SEPA | B2B e valores altos | Confirmação lenta; encomendas ficam à espera |
Comece com dois ou três meios que o seu mercado use mesmo. Cada meio adicional é mais uma escolha no pagamento e, subtilmente, mais um percurso para testar depois de cada atualização.

### Como funciona a integração
A forma é a mesma em praticamente todos os fornecedores modernos, e vale a pena percebê-la porque os modos de falha decorrem dela.
- O seu servidor cria uma intenção de pagamento com valor, moeda e referência da encomenda.
- O cliente é enviado para a página do fornecedor, ou preenche um formulário incorporado.
- O cliente autoriza junto do banco ou emissor, frequentemente com autenticação forte.
- O fornecedor devolve o cliente ao seu URL de retorno — que nunca deve usar como prova de pagamento.
- O fornecedor envia um webhook ao seu servidor com o estado definitivo. É esta a verdade.
- O seu servidor verifica a assinatura do webhook, atualiza a encomenda e envia a confirmação.
- Os dados do cartão nunca tocam no seu servidor — o que o mantém fora da parte pesada do PCI.
Os passos quatro e cinco concentram a maioria dos erros. O cliente pode fechar o navegador antes de regressar; o webhook chega na mesma. Construa sobre o webhook, não sobre o retorno.

### Os casos limite onde se perde dinheiro
Não aparecem em testes e aparecem na primeira semana de movimento a sério.
| Webhook chega duas vezes | Encomenda processada em duplicado | Idempotência: processar cada evento uma vez |
| Webhook chega antes do retorno | Corrida que sobrescreve o estado | Transições de estado explícitas, sem retroceder |
| Cliente fecha o separador após pagar | Pago, sem encomenda | Criar a encomenda no webhook, não no retorno |
| Pagamento falha após reservar stock | Stock preso sem venda | Expirar a reserva após um período fixo |
| Devolução parcial | Contabilidade deixa de bater certo | Modelar devoluções como evento de primeira classe |
| Estorno | Dinheiro perdido, produto enviado | Guardar provas; regras de risco em valores altos |
| Fornecedor indisponível | Zero vendas, não menos vendas | Um segundo meio como alternativa |

### Conformidade e testes
Uma lista curta que cobre o que fica caro quando falta.
- Use campos alojados ou redirecionamento para que os dados de cartão nunca toquem no seu servidor — reduz enormemente o âmbito PCI.
- A autenticação forte é obrigatória na Europa; teste o percurso com um cartão que a exija.
- Verifique a assinatura de cada webhook. Um webhook não verificado é um endpoint público que consegue marcar encomendas como pagas.
- Mostre preços com IVA incluído a consumidores e torne os portes visíveis antes do último passo.
- Guarde dados de encomenda e pagamento pelo prazo fiscal exigido, e não mais do que o necessário quanto a dados pessoais.
- Teste devoluções e devoluções parciais antes do lançamento, não quando o primeiro cliente pedir.
- Faça uma transação real em produção com um cartão real e devolva-a a si próprio. O modo de teste não cobre tudo.

Q: Que fornecedor de pagamentos devo escolher?
A: Escolha pelos meios que suporta no seu mercado, pelas comissões ao seu volume, e por quão bem integra com a sua plataforma. Para uma loja portuguesa, o suporte a MB Way e referência multibanco é o primeiro filtro. As diferenças de preço entre os grandes fornecedores são pequenas o suficiente, com volume modesto, para não serem decisivas.

Q: Preciso de conformidade PCI?
A: Sim, mas o âmbito depende inteiramente de como integra. Se usar campos de pagamento alojados ou redirecionamento, de modo que os dados de cartão nunca toquem no seu servidor, a sua obrigação reduz-se à autoavaliação mais simples. Se processar dados de cartão diretamente, entra num regime completamente diferente — praticamente nenhuma loja o deve fazer.

Q: Porque preciso de webhooks se existe URL de retorno?
A: Porque o retorno depende do navegador do cliente. Se fechar o separador, perder ligação, ou ficar preso na página do banco, o retorno nunca acontece — mas o dinheiro foi debitado na mesma. O webhook vem do servidor do fornecedor e chega de qualquer maneira. Construa a encomenda no webhook e use o retorno apenas para mostrar algo ao cliente.

Q: Como evito encomendas duplicadas?
A: Torne o processamento de webhooks idempotente: guarde o identificador de cada evento processado e ignore repetições. Os fornecedores reenviam webhooks quando não recebem confirmação, por isso entregas duplicadas são comportamento normal e não avaria. Sem esta verificação, envia dois e-mails de confirmação e desconta stock duas vezes.

## Checklist para um contrato de desenvolvimento web
https://websitedevelopment.biz/pt/guides/checklist-contrato-desenvolvimento-web
Atualizado a 2026-08-07 · Contratar programadores

A maioria dos litígios em projetos de sites não é sobre qualidade mas sobre expectativas que nunca foram escritas. Um contrato que nomeia as coisas certas evita praticamente todos eles, e demora uma hora a ler.

Este guia cobre o que deve constar, porque existe cada ponto, e as cláusulas em que deve insistir na dúvida.

### Âmbito: a parte que causa mais litígios
«Construir o site» não é âmbito. Isto é o que deve estar explícito.
- Número de modelos únicos, não número de páginas. Cinquenta páginas em quatro modelos é um projeto pequeno.
- O que está incluído: desenho, construção, introdução de conteúdo, migração, integrações, testes.
- O que não está incluído — esta é a frase mais importante do contrato inteiro.
- Quem escreve os textos e quem fornece as fotografias.
- Número de rondas de desenho e o que conta como uma ronda.
- Navegadores e dispositivos suportados, e o nível de acessibilidade assumido.
- Objetivos de desempenho, se forem importantes, expressos em valores mensuráveis.
- Que idiomas, e quem fornece as traduções.
Um fornecedor que escreve por iniciativa própria o que não está incluído é normalmente um fornecedor que já passou por um litígio de âmbito — o que é bom sinal.

### Propriedade, acessos e saída
Estes pontos parecem abstratos até querer mudar de fornecedor, e nessa altura são os únicos que contam.
| Código-fonte | Passa integralmente para si com o pagamento final |
| Ficheiros de desenho | Também seus, incluindo os ficheiros de origem |
| Domínio | Registado em nome da sua empresa, com o seu acesso |
| Alojamento | Na sua conta, ou transferível a pedido |
| Contas de terceiros | Análise, e-mail, pagamentos — em seu nome |
| Licenças de terceiros | Quais são, e quem as paga depois |
| Transição | Documentação e entrega de acessos ao terminar |
| Uso em portefólio | Podem mostrar; é razoável permitir |
Domínio e alojamento em nome do fornecedor é a forma mais comum de as empresas ficarem presas. Verifique isso antes de assinar, não ao sair.

### Pagamento, prazos e alterações
Estes três ligam-se: quem paga quando, o que define a data, e o que acontece se o âmbito crescer.
- Pagamento por fases ligado a entregas, não a datas de calendário.
- Um adiantamento é normal; pagamento integral antecipado não é.
- Uma parcela final após a entrega, suficientemente relevante para ter significado.
- Dependências mútuas: o prazo desliza se você entregar textos tarde, e isso deve constar.
- Um procedimento de alteração: cada acréscimo recebe estimativa escrita antes de começar.
- Preço à hora para trabalho fora do âmbito, definido à partida.
- O que acontece em caso de atraso de ambos os lados — não apenas do seu.
- Condições de rescisão: como se termina e o que é pago e transferido nesse caso.

### Garantia, manutenção e responsabilidade
A parte que trata do período depois do lançamento, e a que mais frequentemente falta.
| Período de correção | Trinta a noventa dias sem custo |
| O que é um erro | Não funciona como acordado — não: pedido novo |
| Tempo de resposta | Dias úteis para o normal, mais rápido em avaria |
| Manutenção | Contrato separado, com lista explícita |
| Vulnerabilidades de segurança | Quem corrige, em que prazo |
| Dados pessoais | Contrato de subcontratação se tratarem dados |
| Responsabilidade | Limitada ao valor do contrato é habitual |
| Litígios | Que lei, que foro — curto mas presente |
A distinção entre «erro» e «pedido novo» é o que causa mais atrito depois do lançamento. Uma frase que a define poupa meses de discussão.

Q: Preciso de contrato num projeto pequeno?
A: Sim, ainda que curto. Duas páginas que fixem âmbito, preço, momentos de pagamento, propriedade e o que fica de fora cobrem a maior parte do que corre mal. Os projetos pequenos são precisamente aqueles em que ninguém escreve nada e em que o âmbito duplica sem que se dê por isso.

Q: E se o fornecedor quiser manter a propriedade do código?
A: É motivo para perguntar mais. Em código à medida, o código deve ser seu depois de pago. A exceção é uma plataforma ou framework próprio do fornecedor — nesse caso recebe uma licença em vez de propriedade, o que pode ser razoável, desde que o contrato diga o que acontece se sair ou se eles fecharem.

Q: Quanto devo pagar adiantado?
A: Um adiantamento de um quarto a um terço é habitual e razoável. Pagamento integral antecipado não é, porque remove qualquer incentivo para terminar. Ligue o restante a entregas que consiga ver — desenho aprovado, construção entregue, site no ar — em vez de a datas de calendário que podem deslizar.

Q: O que deve cobrir a garantia?
A: Defeitos naquilo que foi entregue: coisas que não funcionam como acordado. Não: pedidos novos, alterações provocadas por atualizações de navegador meses depois, ou problemas causados por alterações suas. Trinta a noventa dias é o habitual. Garanta que o contrato define o que é um erro, ou discutirá isso no pior momento possível.

## WooCommerce, Shopify ou Magento: qual encaixa em si
https://websitedevelopment.biz/pt/guides/woocommerce-shopify-ou-magento
Atualizado a 2026-08-07 · Comércio eletrónico

Estas três aparecem em praticamente todas as listas curtas, e comparam-se surpreendentemente mal porque resolvem problemas diferentes. Pô-las lado a lado é útil desde que se lembre de que «qual é melhor» rende menos do que «qual encaixa na minha situação».

Este guia dá a comparação direta e, mais importante, o perfil de loja para o qual cada plataforma é a escolha certa.

### A comparação em resumo
As diferenças que mais contam na prática, sem listas de funcionalidades que as três acabam por cumprir.
| Tipo | Extensão WordPress, auto-alojada | SaaS alojado | Auto-alojada, empresarial |
| Custo fixo | Alojamento mais extensões | Mensal, sobe por plano | Alojamento significativo |
| Personalização | Alta — o código é seu | Limitada ao que a plataforma permite | Muito alta |
| Manutenção | Sua responsabilidade | Incluída | Sua, e substancial |
| Competência exigida | Média | Baixa | Alta — especializada |
| Dimensão de catálogo ideal | Até alguns milhares | Pequena a grande | Grande a muito grande |
| Ponto forte | Conteúdo e loja no mesmo sistema | Arranque rápido, fiabilidade | B2B complexo e várias lojas |

### Quem deve usar WooCommerce
WooCommerce está no seu melhor quando conteúdo e venda têm de viver juntos, e quando existe quem faça a manutenção.
- Já tem um site WordPress com visitantes, e vender é uma extensão disso.
- O conteúdo puxa as vendas — guias, análises, páginas editoriais que levam a produtos.
- O catálogo é gerível: centenas a alguns milhares de produtos, não centenas de milhares.
- Não quer pagar comissões acima das do fornecedor de pagamento.
- Tem um programador ou agência que assume atualizações, cópias e segurança.
- Precisa de personalizações que uma plataforma alojada não permite.
- Evite quando: ninguém vai assumir a manutenção. É a única forma comum de esta escolha falhar.

### Quem deve usar Shopify
Shopify está no seu melhor quando quer vender depressa e não quer ser dono da manutenção. Isso é uma fatia maior do mercado do que os programadores costumam admitir.
- Quer vender dentro de semanas em vez de meses.
- Os seus requisitos cabem no que a plataforma faz de base, com meia dúzia de aplicações.
- Não tem equipa técnica e não quer contratar uma para manutenção.
- A fiabilidade em picos importa muito — os picos são problema deles, não seu.
- Vende por vários canais e quer que a plataforma trate disso.
- Evite quando: precisa de lógica de pagamento que a plataforma não permite, ou quando as subscrições ultrapassam o custo de uma solução própria.
- Faça as contas às comissões com o seu volume previsto antes de se comprometer.

### Quem deve usar Magento
Magento é poderoso e caro nos dois sentidos — construir e manter. É a escolha certa para menos lojas do que aquelas que o escolhem.
| Preços B2B complexos e grupos de clientes | Sim — é o ponto forte central |
| Várias lojas sobre a mesma retaguarda | Sim |
| Catálogos muito grandes com muitos atributos | Sim |
| Integração profunda com ERP | Sim |
| Catálogo simples de cem produtos | Não — paga complexidade que não usa |
| Sem equipa de desenvolvimento fixa | Não — a manutenção é substancial |
| Orçamento limitado | Não — só o alojamento custa mais que as alternativas |
O erro mais comum com Magento é escolhê-lo por listas de funcionalidades em vez de por capacidade. Sem equipa que o assuma, torna-se uma instalação desatualizada que ninguém se atreve a atualizar.

Q: O WooCommerce é gratuito?
A: A extensão é; a loja não. Conte com alojamento, possivelmente extensões pagas para envios, subscrições ou integração contabilística, e horas mensais de manutenção. O custo total fica muitas vezes perto de uma plataforma alojada — a diferença é que está a comprar controlo e ausência de comissões em vez de comodidade.

Q: O Shopify é melhor para SEO?
A: Não inerentemente. As três podem posicionar bem e as três podem ser mal configuradas. O Shopify impõe algumas estruturas de URL que não pode contornar e que incomodam certas pessoas; o WooCommerce dá controlo total e portanto responsabilidade total. A diferença de posicionamento vem quase sempre de conteúdo e técnica, não da marca da plataforma.

Q: Posso passar de WooCommerce para Shopify?
A: Sim, e no sentido inverso também. Produtos e clientes migram bem; histórico de encomendas e funcionalidade personalizada migram mal. O trabalho a sério é o mapa de URL e reconstruir tudo o que foi personalizado com código. Trate isto como um projeto de semanas, não como um botão de exportar e importar.

Q: Qual escala melhor?
A: As três escalam para além do que a maioria das lojas alguma vez atinge. O Shopify escala sem que trabalhe nisso; o Magento escala mais longe mas exige engenharia; o WooCommerce escala bem até alguns milhares de produtos e depois com trabalho. A escala raramente é a restrição que decide — a capacidade de manutenção é que é.

## Freelancer, agência ou equipa interna: o que encaixa
https://websitedevelopment.biz/pt/guides/freelancer-agencia-ou-equipa-interna
Atualizado a 2026-08-07 · Contratar programadores

As três formas de conseguir trabalho web feito diferem menos em qualidade do que em risco e continuidade. As três produzem trabalho excelente; falham de maneiras diferentes, e é essa diferença que está realmente a escolher.

Este guia compara-as nos pontos que contam e dá o perfil para o qual cada uma é a certa.

### A comparação
As diferenças que se sentem ao fim de meio ano.
| Custo à hora | Mais baixo | Mais alto | Salário mais encargos |
| Tempo de arranque | Dias | Semanas | Meses |
| Disciplinas | Uma ou duas | Várias | O que contratar |
| Continuidade | Frágil — uma pessoa | Boa — há substituição | Boa enquanto ficarem |
| Coordenação | Faz você | Fazem eles | Faz você |
| Conhecimento do negócio | Cresce devagar | Varia por projeto | O mais profundo |
| Encaixa em | Projetos definidos | Projetos grandes, contínuo | Trabalho interno contínuo |

### Quando o freelancer é a escolha certa
Os freelancers são subvalorizados em trabalho bem definido e sobrecarregados em tudo o resto.
- O projeto está bem delimitado e cabe em uma ou duas disciplinas.
- Consegue coordenar e decidir sem um intermediário.
- O orçamento é limitado e prefere comprar horas em vez de estrutura.
- Tem trabalho pequeno e contínuo e quer uma pessoa fixa e conhecida.
- Risco: uma pessoa significa uma doença, umas férias, uma saída. Documente e mantenha os acessos.
- Risco: se o freelancer é designer ou programador, falta-lhe a outra metade — verifique qual.
- Evite quando: o projeto precisa de várias disciplinas ao mesmo tempo e não pode coordenar.

### Quando a agência é a escolha certa
Está a pagar por coordenação, várias disciplinas, e por haver outra pessoa quando alguém falta.
- O projeto precisa de estratégia, desenho, construção e conteúdo ao mesmo tempo.
- Não tem internamente quem conduza o projeto.
- A continuidade pesa muito: o site gera receita e não pode parar por uma doença.
- Quer um único ponto de contacto em vez de coordenar quatro fornecedores.
- Risco: nem sempre recebe as pessoas da reunião comercial — pergunte quem trabalha mesmo no projeto.
- Risco: a estrutura é real. Em trabalho simples, paga coordenação de que não precisa.
- Pergunte pela rotatividade. Uma agência onde as pessoas saem depressa entrega qualidade variável.
Pergunte explicitamente quem executa o trabalho e quantos projetos essa pessoa tem em paralelo. Essa resposta prevê o prazo melhor do que o cronograma da proposta.

### Quando contratar internamente
Um programador interno é a opção mais cara à hora e a mais barata ao ano — desde que haja mesmo um ano de trabalho.
| O site é o produto | Sim, claramente |
| Alterações semanais e funcionalidade nova | Sim |
| Sistemas internos que exigem integração | Sim |
| Um site que muda por trimestre | Não — um freelancer é mais barato |
| Sem liderança técnica na empresa | Não — um programador sozinho perde-se |
| Pico de três meses | Não — contrate externamente para o pico |
O erro comum é contratar um programador sem ninguém que consiga acompanhar tecnicamente. Sem orientação e sem colegas, é uma posição difícil e normalmente de curta duração.

Q: Os freelancers são mais arriscados?
A: Num ponto: não há substituto quando adoecem, saem ou aceitam outro trabalho. Esse risco gere-se com documentação, acessos em seu nome e código no seu próprio repositório. Em qualidade não há diferença sistemática — bons freelancers entregam trabalho que qualquer agência assinaria.

Q: Porque é que as agências são tão mais caras?
A: Porque está a comprar mais: gestão de projeto, várias disciplinas, substituição quando alguém falta, e uma organização que continua a existir. Num projeto complexo isso vale o custo. Num site simples está a pagar coordenação de que ninguém precisa — aí um freelancer está mais honestamente preçado para o mesmo resultado.

Q: Quando devo contratar internamente?
A: Quando existe mesmo trabalho contínuo — alterações semanais, funcionalidade nova, integrações com sistemas internos. Faça as contas: se a fatura externa anual é comparável a um salário, vale considerar. Garanta que existe liderança técnica; um programador sozinho sem colegas é uma posição frágil.

Q: Posso combinar as opções?
A: Sim, e funciona muitas vezes bem. Uma configuração comum é agência para a construção e freelancer para manutenção contínua e pequenas alterações. A condição é que o código seja seu, que a documentação exista e que a transição esteja planeada explicitamente — caso contrário compra um problema de transição em vez de flexibilidade.

## As melhores plataformas de comércio eletrónico comparadas
https://websitedevelopment.biz/pt/guides/melhores-plataformas-de-ecommerce
Atualizado a 2026-08-07 · Comércio eletrónico

A escolha de plataforma determina os seus custos fixos, quanto pode personalizar, e quão doloroso será sair daqui a três anos. É a decisão mais difícil de reverter num projeto de loja.

Este guia compara as categorias em vez de enumerar marcas, porque é a categoria que determina os compromissos que vai herdar.

### As três categorias
Praticamente todas as plataformas caem numa destas três, e a categoria prevê a sua experiência melhor do que o nome da marca.
| Alojada (SaaS) | Shopify, BigCommerce | Manutenção incluída, arranque rápido | Mensalidade, limites, comissões |
| Auto-alojada | WooCommerce, Magento, PrestaShop | Controlo total, sem taxas de plataforma | Atualizações, segurança e alojamento são seus |
| Headless | APIs de comércio com front-end próprio | Liberdade total de desenho e velocidade | Dois sistemas para construir e manter |
Para a maioria das lojas abaixo de cerca de mil encomendas por mês, a pergunta é alojada ou auto-alojada. Headless é uma resposta a limitações concretas, não um ponto de partida.

### Custo a três anos, não no primeiro mês
As plataformas parecem diferentes assim que se olha para o custo total de propriedade em vez do preço de entrada.
| Licença mensal | Fixa, sobe com o volume | Nenhuma |
| Alojamento | Incluído | Seu, escala com o tráfego |
| Comissões de transação | Possíveis, além do fornecedor de pagamento | Só o fornecedor de pagamento |
| Extensões | Normalmente mensais por aplicação | Anuais ou à medida |
| Manutenção | Faz a plataforma | Sua — conte com horas mensais |
| Segurança | Responsabilidade da plataforma | Sua responsabilidade |
| Personalização | Limitada ao que a plataforma permite | Ilimitada, mas paga a construção |
Alojada costuma sair mais barata até certo volume, a partir do qual comissões e subscrições de aplicações podem inverter o resultado. Faça as contas com o seu volume previsto, não com uma regra genérica.

### Onde cada categoria começa a apertar
Cada plataforma tem um ponto a partir do qual se trabalha contra a ferramenta. Saber onde é isso é mais útil do que uma lista de funcionalidades.
- Alojada aperta quando precisa de lógica de pagamento ou de preços que a plataforma não permite — preços B2B, regras de IVA fora do comum, conjuntos complexos.
- Alojada aperta também quando as subscrições de aplicações se acumulam: dez aplicações a trinta por mês são uma fatura de alojamento com passos extra.
- Auto-alojada aperta quando ninguém é dono da manutenção. Uma loja WooCommerce abandonada torna-se um problema de segurança em menos de um ano.
- Auto-alojada aperta com escala sem engenharia: desempenho com catálogos grandes exige trabalho real que as plataformas alojadas fazem por si.
- Headless aperta quando a equipa é menor do que o sistema. Manter duas bases de código exige capacidade que nem toda a gente tem.
- Qualquer plataforma aperta quando a estrutura do catálogo não encaixa no modelo de dados — verifique isso com produtos reais antes de decidir.

### Como escolher na prática
Um procedimento curto que evita a maioria das más escolhas, por ordem.
- Escreva os seus cinco produtos mais complicados e construa-os numa conta de teste. Se o modelo de dados não encaixar, para aí.
- Enumere todos os sistemas com que a loja tem de falar. Verifique se existe integração feita ou se é preciso construir.
- Faça as contas a três anos com o volume previsto, incluindo comissões e aplicações.
- Verifique quem vai fazer a manutenção. Se a resposta for «ninguém», escolha alojada.
- Teste o painel de gestão com a pessoa que vai lá trabalhar todos os dias, não com o programador.
- Verifique o caminho de saída: consegue exportar produtos, clientes e encomendas em formato utilizável?
O passo um apanha a maioria das incompatibilidades. Uma plataforma que não representa bem o seu produto mais difícil transforma-se em três anos de soluções de recurso.

Q: Qual é a melhor plataforma de comércio eletrónico?
A: Não há uma, e isso não é uma evasiva. Alojada ganha quando ninguém quer assumir a manutenção e os requisitos cabem na plataforma. Auto-alojada ganha quando precisa de personalização ou quer evitar taxas de plataforma e tem quem a mantenha. Escolha primeiro a categoria; a marca dentro da categoria é uma decisão menor.

Q: Posso mudar de plataforma depois?
A: Pode, mas é um projeto a sério — produtos, clientes, histórico de encomendas e todos os URL têm de migrar, e as posições oscilam durante semanas. Conte com uma parte substancial do custo da construção original. É por isso que a escolha merece cuidado, e porque a capacidade de exportação é um critério de decisão.

Q: As comissões de transação importam?
A: Com volume baixo, quase nada; com volume alto, muito. Um por cento adicional sobre cem mil por mês são mil euros mensais, o que financia boa parte de uma solução própria. A maioria das plataformas alojadas dispensa a comissão extra se usar o seu próprio meio de pagamento — verifique se isso é vantajoso no seu mercado.

Q: Headless compensa?
A: Quando precisa de um desenho ou de um nível de desempenho que um sistema de temas não consegue, e tem capacidade de engenharia para manter dois sistemas. Para a maioria das lojas, o compromisso honesto é que acrescenta complexidade significativa por benefícios que a maioria dos clientes não nota. Não comece headless; evolua para lá se uma limitação concreta o obrigar.

## Como contratar um programador web: guia completo
https://websitedevelopment.biz/pt/guides/como-contratar-um-programador-web
Atualizado a 2026-08-07 · Contratar programadores

A maioria dos maus projetos de site não falha na construção mas na escolha — um desencontro entre o que a empresa precisava e quem contratou. Isso é boa notícia, porque a escolha é a parte que controla inteiramente.

Este guia cobre como definir o que precisa, onde procurar, como avaliar o que recebe, e que sinais são realmente preditivos.

### Defina primeiro o que precisa mesmo
«Precisamos de um site» é vago demais para orçamentar, e briefings vagos produzem propostas incomparáveis.
- Escreva o que o site tem de fazer pelo negócio — gerar pedidos, vender, informar, recrutar.
- Indique o número aproximado de páginas e os tipos de conteúdo. Vinte páginas é outro projeto que duzentas.
- Enumere cada integração: contabilidade, CRM, stock, e-mail marketing, autenticação.
- Defina quem escreve o conteúdo. É a rubrica mais subestimada e a causa mais comum de atraso.
- Defina quem gere o site depois do lançamento, e com que nível de conhecimento.
- Indique o intervalo de orçamento. Partilhá-lo poupa tempo a todos e produz propostas mais úteis.
- Indique a data e porque existe — uma feira é uma razão real; «o mais depressa possível» não é.
O ponto quatro determina o prazo mais vezes do que qualquer decisão técnica. Um projeto raramente espera por código e frequentemente espera por textos e fotografias.

### Onde procurar, e o que cada canal dá
O canal determina em grande medida quem encontra e a que preço.
| Recomendação da sua rede | Melhor taxa de acerto; trabalho comprovado | Escolha limitada |
| Agências locais | Acessíveis, responsáveis | Preços mais altos |
| Plataformas de freelancing | Muita oferta, rápido | Qualidade muito variável; filtre bem |
| Comunidades técnicas | Fortes tecnicamente | Frequentemente menos desenho e estratégia |
| Sites de que gosta | O rodapé diz quem os construiu | O canal mais subaproveitado |
| Contratação interna | Capacidade contínua | Só faz sentido com trabalho contínuo |
Ver sites de que gosta e descobrir quem os fez é o canal mais subaproveitado, e produz a lista curta mais relevante.

### Avaliar portefólios
Os portefólios mostram o melhor trabalho nas melhores condições. Estas verificações mostram o que está por baixo.
- Visite os sites reais, não as capturas de ecrã. O trabalho degrada-se depois de os clientes assumirem.
- Abra-os no telemóvel e repare no tempo de carregamento. Isto filtra mais candidatos do que qualquer pergunta.
- Veja se há projetos de complexidade semelhante, não apenas do mesmo setor.
- Pergunte qual foi a contribuição deles — desenho, construção, conteúdo, ou tudo.
- Peça um projeto que tenha corrido mal e o que fariam de outra forma. A resposta é muito reveladora.
- Ligue a uma referência e pergunte pela colaboração depois do lançamento, não antes.
- Verifique se têm trabalho com mais de três anos que continue a funcionar.

### Sinais durante a conversa
O melhor preditor de uma boa colaboração não é técnico mas como a pessoa lida com ambiguidade.
| Faz perguntas sobre o negócio antes de sobre desenho | Orçamenta sem perguntar nada |
| Contesta requisitos pouco claros | Diz que sim a tudo |
| Explica compromissos em linguagem simples | Esconde decisões atrás de jargão |
| Diz o que não está incluído | Apenas um valor total |
| Pergunta quem escreve o conteúdo | Assume que o conteúdo existe |
| Fala do que acontece depois do lançamento | Trata o lançamento como o fim |
| Dá um intervalo com os pressupostos | Dá um valor exato sem âmbito |
Quem contesta os seus requisitos está a fazer o seu trabalho. Quem diz que sim a tudo entrega o atraso e o custo extra mais tarde.

Q: Quanto devo pagar por um site?
A: Um site institucional simples com CMS fica tipicamente em baixos milhares. Desenho à medida, mais páginas e integrações levam isso a dezenas de milhares. O que move o preço é a quantidade de personalização, o número de integrações e quem faz o conteúdo — não o número de páginas. Peça propostas que separem essas rubricas.

Q: Freelancer ou agência?
A: Um freelancer é mais barato e mais direto, e funciona bem em projetos bem definidos quando consegue fazer a coordenação. Uma agência traz várias disciplinas e continuidade, o que conta em projetos maiores e em manutenção contínua. A diferença real está no que acontece quando alguém fica indisponível.

Q: Como sei se um orçamento é razoável?
A: Peça três com base no mesmo documento escrito. Diferenças superiores a um fator de dois significam normalmente que estão a orçamentar coisas diferentes, não que um é caro — leia então o que falta no mais barato. Uma proposta que diz explicitamente o que não inclui vale mais do que uma mais baixa sem âmbito.

Q: Devo ser dono do código?
A: Sim, e isso deve constar do contrato. Tem de conseguir continuar o site com outro fornecedor sem reconstruir. Verifique também quem é dono do domínio, do alojamento e das contas — fornecedores que os registam em nome próprio tornam a saída artificialmente difícil. Pergunte isto antes de assinar.

## Criar uma loja online: o guia completo
https://websitedevelopment.biz/pt/guides/guia-de-criacao-de-loja-online
Atualizado a 2026-08-07 · Comércio eletrónico

Uma loja online é um site com dinheiro, stock e obrigações legais agarrados. É isso que torna a criação de uma loja um projeto diferente de um site institucional: as partes que custam mais não costumam ser as que os clientes veem.

Este guia cobre o que um projeto de loja inclui realmente, o que determina o custo, o trabalho operacional que começa no lançamento, e os erros caros de desfazer.

### O que uma loja inclui para além da montra
Catálogo e pagamento são a parte visível. Por baixo estão os sistemas que decidem se o negócio consegue funcionar, e é aí que vai a maior parte do orçamento em qualquer loja acima da mais pequena.
- Estrutura do catálogo: categorias, variantes, atributos, conjuntos, regras de disponibilidade.
- Preços: com ou sem IVA por mercado, descontos, grupos de clientes, moeda.
- Pagamentos: pelo menos um fornecedor, mais devoluções, devoluções parciais e pagamentos falhados.
- Envios: zonas, pesos, dimensões, regras de transportadora, limiares de portes grátis.
- IVA: por destino, com faturas que cumpram os requisitos legais aplicáveis.
- Stock: disponibilidade, encomendas pendentes e reserva durante o pagamento para não vender a mais.
- Gestão de encomendas: onde a equipa processa as encomendas — muitas vezes noutro sistema.
- E-mails: confirmação, expedição, devolução, carrinho abandonado, e o seu conteúdo legal.
- Devoluções: a política e o fluxo de trabalho que a executa.
Pergunte cedo onde a equipa vai processar as encomendas. Se for o ERP existente, a integração é uma parte substancial do projeto e pertence à primeira estimativa.

### O que determina o custo
O número de produtos importa menos do que a complexidade de cada um e o número de sistemas com que a loja tem de falar.
| Catálogo | Produtos simples, um preço | Variantes, conjuntos, produtos configuráveis |
| Mercados | Um país, uma moeda | Vários países, regras de IVA, moedas |
| Integrações | Nenhuma — a loja é o sistema | ERP, gestão de stock, contabilidade, envios |
| Preços | Preços públicos fixos | Grupos de clientes, escalões, orçamentos |
| Desenho | Modelos de tema | Montra e páginas de produto à medida |
| Migração | Loja nova, sem histórico | Encomendas, clientes, URL, avaliações |
| Conteúdo | Pouco e fornecido | Milhares de produtos por escrever e fotografar |
O conteúdo de produto é a rubrica mais subestimada. Descrever e fotografar mil produtos custa frequentemente mais do que construir a loja.

### O que começa no lançamento
Num site institucional, o lançamento é praticamente o fim. Numa loja, é o início de trabalho contínuo que alguém tem de assumir.
- Diário: processar encomendas, verificar falhas de pagamento, responder a clientes.
- Semanal: atualizar stock, rever carrinhos abandonados, verificar custos de envio.
- Mensal: atualizar plataforma e extensões, testar o percurso de pagamento depois de cada atualização.
- Contínuo: acrescentar e renovar conteúdo de produto — uma loja que não cresce recua.
- Trimestral: rever comissões de pagamento, taxas de devolução e a tabela de portes.
- Anual: rever regras de IVA, sobretudo se vender para novos mercados.

### Erros caros de desfazer
São baratos de evitar à partida e caros de resolver depois, normalmente porque tocam em dados ou em URL.
| Tratar o IVA como detalhe final | Faturas erradas são problema contabilístico, não bug | Definir as regras por mercado antes de construir |
| Sem reserva de stock | Vendas a mais em pico, correção manual | Reservar stock ao iniciar o pagamento |
| Migração sem mapa de URL | Todas as posições de produto desaparecem | 301 de antigo para novo, um para um |
| Um só meio de pagamento | Uma avaria significa zero vendas | Acrescentar um segundo antes de precisar |
| Filtros sem restrição | Milhares de URL quase iguais no índice | noindex por omissão nas combinações |
| Pagamento testado só em desktop | A maioria do tráfego é móvel | Testar em telemóveis reais |

Q: Quanto custa uma loja online?
A: Uma loja com tema sobre plataforma existente e catálogo modesto fica tipicamente em baixos milhares. Desenho à medida, vários mercados e integração com ERP levam isso a dezenas de milhares. As maiores variáveis são integrações e conteúdo de produto, não a construção da loja em si — peça um orçamento que separe essas duas rubricas.

Q: Quanto tempo demora construir uma loja?
A: Seis a dez semanas para uma loja com tema, catálogo limpo e um só mercado. Três a seis meses assim que houver desenho à medida, migração de encomendas existentes, ou ligação a um ERP. A preparação de conteúdo corre em paralelo e é frequentemente o que determina a data real.

Q: Posso gerir a loja sozinho?
A: A operação diária sim: produtos, preços, encomendas e conteúdo devem estar todos no painel de gestão. O que se subcontrata é a manutenção técnica — atualizações, cópias, segurança e testar o percurso de pagamento depois de cada alteração de plataforma. Essa divisão funciona bem e é o que a maioria das lojas pequenas faz.

Q: Devo começar com todos os meios de pagamento?
A: Não. Comece com os que o seu mercado usa efetivamente — em Portugal isso significa quase sempre MB Way e referência multibanco, mais cartão para clientes estrangeiros. Acrescente depois com base no que os clientes pedirem. O que quer cedo é um segundo meio como alternativa, para que uma avaria num fornecedor não pare as vendas.

## Sites multilingues: CMS, URL e fluxo de trabalho
https://websitedevelopment.biz/pt/guides/site-multilingue-cms
Atualizado a 2026-08-07 · CMS

Um site multilingue não é um site multiplicado pelo número de idiomas. É um modelo de conteúdo com relações de tradução, um padrão de URL que nunca mais vai querer mudar, e um fluxo de trabalho que determina se as traduções se mantêm atuais ou envelhecem em menos de um ano.

Este guia cobre as decisões por ordem de quanto custa revertê-las.

### Escolha primeiro o padrão de URL
É a decisão mais cara de mudar, porque se liga a hreflang, canónicos e a todos os redirecionamentos que alguma vez vai escrever.
| Subpasta | site.pt/en/servicos | O mais simples; um domínio acumula toda a autoridade |
| Subdomínio | en.site.com/servicos | Separação mais limpa; mais configuração, sinais divididos |
| Domínio por país | site.es/servicios | Sinal local mais forte; um site separado para gerir |
| Parâmetro | site.com/servicos?lang=en | Evitar — sinais fracos e risco de duplicação |
Para a maioria dos projetos, subpastas são a escolha certa. Domínios por país só compensam quando constrói mesmo presença local, com equipa por mercado.

### O idioma, e as partes que se traduzem
Uma versão de idioma é mais do que o texto. Estas partes são as mais esquecidas e são visíveis para os visitantes.
- Nomes de URL: traduzidos para relevância local, ou iguais para manutenção mais simples. Ambos defensáveis; escolha de propósito.
- Metadados: títulos e descrições por idioma, não derivados automaticamente do original.
- Datas, números e moeda no formato local.
- Formulários: etiquetas, mensagens de erro, confirmações, e os e-mails que se seguem.
- Imagens com texto embutido — intraduzíveis sem ficheiros separados.
- Páginas legais: política de privacidade e termos têm diferenças reais por jurisdição.
- Pesquisa e páginas de erro, que ficam quase sempre esquecidas no idioma original.
- Direção de escrita nos idiomas da direita para a esquerda — isso é layout, não só texto.

### Configurar hreflang corretamente
O hreflang diz aos motores qual versão corresponde a que idioma. É mecânico e falha de formas mecânicas.
- Cada página declara todas as versões de idioma de si própria, incluindo ela mesma.
- As referências têm de ser recíprocas. Se faltar a de retorno, o grupo inteiro é anulado.
- Use códigos corretos: pt, en, pt-br. Um código inventado é ignorado.
- Use o mesmo código no HTML e no mapa do site; dois códigos diferentes partem o grupo.
- Acrescente x-default para visitantes que não caem em nenhum idioma.
- Gere tudo a partir de uma só fonte para que HTML e mapa do site não divirjam.
- Se uma página não existir num idioma, não declare esse idioma — não aponte para um substituto.
A última regra é importante em tradução faseada: um site parcialmente traduzido está perfeitamente bem desde que o hreflang só declare o que existe.

### Fluxo de trabalho: onde encalha na prática
A configuração técnica é a parte fácil. Manter as traduções atuais é onde os projetos multilingues param.
| Original muda, tradução não | Os idiomas divergem em silêncio | Marcar traduções como desatualizadas ao alterar o original |
| Sem dono por idioma | As traduções envelhecem sem ninguém notar | Nomear um responsável por idioma |
| Traduzir tudo | O custo escala com páginas, não com valor | Traduzir só o que aquele mercado precisa |
| Tradução automática sem revisão | Erros que prejudicam a marca e posicionam mal | Automática como primeira versão, sempre revista |
| Tradutores sem contexto | Textos literais mas errados | Enviar capturas de ecrã e notas |
| Sem rascunhos por idioma | Meias traduções publicadas | Estado de publicação separado por idioma |
Decida antecipadamente que idiomas ficam completos e quais recebem apenas um núcleo. Um site com cinco idiomas bons desempenha melhor do que um com quinze desatualizados.

Q: Devo usar subpastas ou domínios separados?
A: Subpastas para a maioria dos projetos: um domínio acumula toda a autoridade, a configuração é mais simples e há um só site para manter. Domínios por país compensam quando constrói mesmo presença local com equipa por mercado — aí compra um sinal local forte e paga com carga de gestão.

Q: A tradução automática é aceitável?
A: Como primeira versão revista por uma pessoa, sim — é hoje uma prática normal e poupa bastante. Publicada sem revisão é arriscada: erros em termos técnicos prejudicam a credibilidade junto precisamente dos leitores que quer alcançar, e os textos posicionam mal porque não correspondem à forma como as pessoas realmente procuram.

Q: Tenho de traduzir todas as páginas para todos os idiomas?
A: Não, e tentar fazê-lo é como os projetos multilingues encalham. Traduza o que aquele mercado precisa: as páginas centrais, os serviços que oferece lá, e o conteúdo que é procurado naquele idioma. Desde que o hreflang só declare o que existe, um site parcialmente traduzido está tecnicamente correto.

Q: O que corre mal com mais frequência em sites multilingues?
A: Duas coisas. Tecnicamente: hreflang não recíproco, o que anula o grupo de idiomas inteiro. Organizacionalmente: não haver dono por idioma, pelo que o original avança e as traduções ficam paradas. A segunda é a mais fatal, porque não é uma avaria que alguém reporte — a degradação é gradual.

## Estrutura de URL para SEO: as regras que ainda contam
https://websitedevelopment.biz/pt/guides/estrutura-de-urls-amigavel-para-seo
Atualizado a 2026-08-07 · SEO

Os URL são um fator de posicionamento pequeno e um fator de usabilidade e manutenção grande. O seu valor verdadeiro é a estabilidade: um URL que nunca precisa de mudar é um URL que mantém as ligações, as posições e os favoritos.

Este guia cobre as regras que ainda contam, as que já não contam, e como mudar um URL quando é mesmo necessário.

### As regras que vale a pena seguir
São consistentes entre motores de busca e, mais importante, ao longo dos anos — tanto sobre manutenção como sobre posicionamento.
- Só minúsculas. Alguns servidores tratam /Pagina e /pagina como URL diferentes, criando duplicação acidental.
- Hífenes entre palavras, não underscores nem maiúsculas no meio.
- Curto e descritivo. Se alguém ler o URL em voz alta, deve conseguir adivinhar a página.
- Palavras de ligação são dispensáveis: /guias/planeamento-de-site vence /guias/como-planear-um-site-para-a-minha-empresa.
- Sem extensões de ficheiro em páginas de conteúdo. /sobre, não /sobre.php — esconde a implementação e sobrevive a uma migração.
- Uma escolha canónica sobre a barra final, imposta por redirecionamento.
- ASCII sempre que possível; URL com acentos funcionam mas ficam codificados ao copiar, o que é feio e propenso a erro.
A propriedade mais valiosa é a estabilidade. Um URL ligeiramente imperfeito que nunca muda vale mais do que um otimizado que muda duas vezes.

### O que já não conta muito
Várias crenças persistentes sobre URL têm hoje efeito limitado, e segui-las pode até prejudicar.
| URL com palavra-chave exata posicionam melhor | Marginal quando muito; acumular parece spam |
| Estrutura de pastas profunda sinaliza hierarquia | A profundidade de cliques conta; a de caminho quase não |
| Datas no URL ajudam a atualidade | Fazem conteúdo intemporal parecer velho |
| Mais curto é sempre melhor | Descritivo vence conciso; /p/4821 não ajuda ninguém |
| Subdomínio ou subpasta é decisivo | Subpastas são mais simples; ambos funcionam |
| Query strings não são indexáveis | São, mas multiplicam duplicação — prefira caminhos limpos |

### Padrões de URL multilingues
Num site em vários idiomas, o padrão de URL é das coisas mais difíceis de mudar depois, porque se liga a hreflang, canónicos e a todos os redirecionamentos que alguma vez vai escrever.
| Subpasta | site.pt/en/guias | O mais simples; um domínio acumula toda a autoridade |
| Subdomínio | en.site.com/guias | Separação mais limpa; mais configuração, sinais divididos |
| Domínio por país | site.co.uk/guias | Sinal local mais forte; um site separado para gerir |
| Parâmetro | site.com/guias?lang=en | Evitar — sinais fracos e risco de duplicação |
Independentemente da escolha, decida à parte se o nome do URL é traduzido. Nomes traduzidos ajudam a relevância local; nomes iguais são mais simples de manter. Ambos são defensáveis; mudar de ideias depois não é.

### Mudar um URL sem perder tráfego
Às vezes é mesmo necessário. O procedimento é mecânico, e saltar um passo é onde o tráfego se perde.
- Confirme que compensa. Uma mudança de URL custa sempre alguma coisa; uma melhoria pequena de redação raramente a paga.
- Mapeie antigo para novo, um para um. Cada URL antigo recebe um destino específico, não uma página de categoria.
- Use redirecionamentos 301, não 302, e verifique que cada um é um único salto.
- Atualize as ligações internas para apontarem diretamente ao novo URL. Não dependa dos seus próprios redirecionamentos.
- Atualize o mapa do site e mantenha os redirecionamentos por tempo indefinido — as ligações externas nunca se atualizam.
- Acompanhe a cobertura e o relatório de páginas principais durante quatro a seis semanas.
- Conte com uma quebra, e só investigue se continuar a agravar-se ao fim de um mês.

Q: Devo incluir palavras-chave nos URL?
A: Inclua as palavras que descrevem a página, que normalmente são as palavras-chave. O que não deve fazer é acumular variantes: /desenvolvimento-web-servicos-desenvolvimento-web-barato é pior em todos os aspetos do que /servicos-desenvolvimento-web, inclusive para as pessoas que o veem nos resultados.

Q: Subdomínio ou subpasta para o blogue?
A: Subpasta, na maioria dos casos. site.pt/blogue é mais simples de gerir, partilha os sinais acumulados do domínio e não exige configuração técnica separada. Subdomínios fazem sentido quando a secção é mesmo uma aplicação distinta, tem equipa própria, ou precisa de correr noutra infraestrutura.

Q: Durante quanto tempo devo manter redirecionamentos antigos?
A: Indefinidamente. Custam praticamente nada a manter e as ligações externas para os seus URL antigos nunca são atualizadas. O que deve fazer periodicamente é reduzir as cadeias criadas por migrações sucessivas, para que cada URL antigo aponte num único salto para o destino atual.

Q: Parâmetros no URL prejudicam o SEO?
A: Não são prejudiciais em si, mas multiplicam rapidamente URL quase duplicados — parâmetros de ordenação, filtro e campanha podem gerar milhares de variantes da mesma página. Use caminhos limpos para tudo o que quer indexado, e torne as variantes com parâmetros canónicas ou noindex.

## Migrar de CMS sem perder tráfego nem conteúdo
https://websitedevelopment.biz/pt/guides/guia-de-migracao-de-cms
Atualizado a 2026-08-07 · CMS

Uma migração de CMS é sobretudo um projeto de dados com um dia de lançamento agarrado. O desenho leva a atenção; o mapeamento de conteúdo e os redirecionamentos decidem se corre bem.

Este guia cobre a ordem que funciona, os sítios onde as migrações perdem tráfego, e o que esperar nas semanas seguintes.

### Inventarie antes de mover seja o que for
Não se migra o que não se contou. Este passo é saltado e causa a maioria das surpresas.
- Rastreie o site atual e exporte cada URL com o seu código de estado e título.
- Retire da análise e da consola de pesquisa as páginas com melhor desempenho — merecem mais cuidado.
- Conte os tipos de conteúdo: páginas, artigos, produtos, casos, pessoas, descargas.
- Anote os campos de cada tipo, incluindo os que só aparecem em alguns itens.
- Inventarie multimédia: quantos ficheiros, que volume total, quais já estão em falta.
- Registe funcionalidade que não é conteúdo: formulários, pesquisa, filtros, integrações.
- Decida o que não vai levar. Uma migração é a melhor ocasião para deixar conteúdo morto para trás.
O último passo é o que mais trabalho poupa. Sites acumulam durante anos páginas que ninguém lê; levá-las custa tempo em cada passo seguinte.

### Mapear conteúdo e URL
Dois mapeamentos: campos para campos, e URL antigos para novos. O segundo é o que decide o tráfego.
| Tipos de conteúdo | Tipo antigo para tipo novo, explicitamente | Importar tudo como «página» |
| Campos | Campo a campo, incluindo casos vazios | Falhar campos que só às vezes existem |
| Multimédia | Levar ficheiros e atualizar as referências | Migrar ficheiros e deixar links no antigo |
| URL | Um para um, cada antigo com destino | Tudo para a nova página inicial |
| Categorias e etiquetas | Preservar ou fundir de propósito | Criar estrutura nova sem querer |
| Autores e datas | Levar; as datas afetam sinais de atualidade | Pôr todas as datas na data de importação |
| Redirecionamentos já existentes | Levar também | Descartar cadeias antigas e partir links |
A importação de datas é um assassino silencioso: se todas as datas de publicação passarem a ser a data da migração, todo o seu arquivo parece escrito no mesmo dia.

### Testar antes de lançar
O que verificar no ambiente de testes, pela ordem que apanha mais coisas.
- Conte os itens por tipo de conteúdo e compare com o site antigo. Contagens erradas são o primeiro sinal.
- Verifique uma amostra das páginas mais longas e mais estranhas — são as que partem primeiro.
- Confirme que as imagens carregam do novo local, não do domínio antigo.
- Teste cada redirecionamento com um script contra a lista completa de URL, não à mão.
- Verifique os metadados: títulos, descrições, canónicos, dados estruturados.
- Teste os formulários por completo, incluindo a chegada do e-mail.
- Compare o desempenho com o site antigo; uma migração que duplica o peso é uma regressão.
- Peça à redação para criar e publicar uma página antes de lançar.

### Lançar e as semanas seguintes
O dia de lançamento é curto; a janela de atenção não é.
- Lance num momento calmo, não a uma sexta-feira ao fim da tarde.
- Verifique o robots.txt em produção de imediato — levar o de testes é o erro clássico.
- Submeta o novo mapa do site e mantenha o antigo algum tempo para os URL antigos serem recolhidos.
- Volte a correr o teste de redirecionamentos em produção; ambientes de testes por vezes mentem.
- Acompanhe o registo de erros nos primeiros dias à procura de 404 que não previu.
- Siga tráfego e posições durante quatro a seis semanas; conte com oscilação.
- Só investigue a sério se continuar a cair ao fim de um mês — antes disso é normalmente ruído.
Acrescente à tabela de redirecionamentos os 404 que forem aparecendo nos registos. Nenhum inventário é completo; o registo de erros preenche o resto.

Q: Vou perder tráfego de pesquisa numa migração de CMS?
A: Temporariamente quase sempre, permanentemente só com erros. Conte com quatro a seis semanas de oscilação mesmo com execução limpa. A perda duradoura vem quase exclusivamente de URL não mapeados, de páginas removidas que tinham tráfego, e de alterações de metadados ou conteúdo em páginas que estavam a funcionar bem.

Q: Posso migrar conteúdo automaticamente?
A: Em grande parte sim. Campos padrão e artigos migram bem com ferramentas existentes. O que exige trabalho manual são campos personalizados, marcação embutida dentro do texto, e tudo o que no sistema antigo era resolvido por uma extensão. Conte com uma base automática mais uma ronda manual nas páginas principais.

Q: Quanto tempo demora uma migração de CMS?
A: Para um site de cem páginas com conteúdo padrão, algumas semanas. Para milhares de páginas com campos personalizados e integrações, alguns meses. O número de páginas conta menos do que o número de tipos de conteúdo e a quantidade de personalização — são essas as coisas que nenhuma ferramenta resolve por si.

Q: Devo manter o site antigo?
A: Guarde uma cópia completa e, se possível, uma versão protegida que possa consultar. Vai querer verificar nos primeiros meses o que estava numa página ou como algo estava configurado. O que não deve fazer é deixar o site antigo público — duas versões do mesmo conteúdo competem entre si.

## Otimizar a velocidade de um site: ordem de trabalho prática
https://websitedevelopment.biz/pt/guides/otimizar-velocidade-de-um-site
Atualizado a 2026-08-07 · SEO

O trabalho de velocidade tem uma forma muito desigual: um punhado de intervenções explica a maior parte da melhoria na maioria dos sites, e são quase sempre imagens, resposta do servidor e scripts de terceiros.

Este guia cobre a ordem de trabalho, como medir se uma alteração ajudou, e as otimizações que normalmente não compensam.

### Medir antes de mexer
Otimizar sem medir significa corrigir o que é mais fácil em vez do que é lento. Duas medições, depois trabalho.
- Obtenha dados de campo de visitantes reais — o relatório de Core Web Vitals ou a sua própria monitorização.
- Corra um teste de laboratório nos três modelos principais, limitado a um telemóvel médio em 4G.
- Registe os números antes de começar. Sem linha de base não consegue dizer se algo ajudou.
- Identifique, por modelo, o maior ficheiro individual e o maior pedido bloqueante.
- Anote o Time to First Byte à parte: acima de 800 ms, nenhum trabalho de front-end o salva.

### A ordem que compensa
Aproximadamente por melhoria obtida por hora de esforço, num site institucional ou de conteúdo típico.
| Otimizar e dimensionar imagens | Grande | Baixo |
| Remover scripts de terceiros não usados | Grande | Baixo — sobretudo político |
| Ativar cache e CDN | Grande | Baixo |
| Resolver CSS e JS bloqueantes | Médio a grande | Médio |
| Reduzir o pacote de JavaScript | Médio a grande | Médio a alto |
| Corrigir consultas lentas à base de dados | Grande onde aplicável | Médio |
| Otimizar carregamento de tipos de letra | Médio | Baixo |
| Minificar e comprimir texto | Pequeno | Baixo — normalmente já ativo |
| Micro-otimizar seletores CSS | Insignificante | Não compensa |

### Imagens: normalmente o maior ganho
Na maioria dos sites, as imagens são a maior parte do peso da página, e a maioria é servida várias vezes maior do que é apresentada. É a melhoria grande mais barata que existe.
- Sirva WebP ou AVIF; ambos têm suporte amplo e são tipicamente 25 a 50 % menores do que JPEG com qualidade equivalente.
- Gere vários tamanhos e use srcset com sizes para que os telemóveis descarreguem ficheiros de telemóvel.
- Nunca sirva uma imagem de 2000 px numa caixa de 400 px — este erro isolado é extraordinariamente comum.
- Carregue de forma diferida tudo o que está abaixo da dobra, e nada acima dela.
- Automatize na construção ou no CMS. Imagens otimizadas à mão deixam de o estar assim que outra pessoa carregar uma.
- Remova metadados; o EXIF da câmara pode representar dezenas de kilobytes por ficheiro.
A automatização é o essencial. Uma ronda pontual de otimização perde validade em meses à medida que entra conteúdo novo, e ninguém repara até o peso ter duplicado.

### Scripts de terceiros e servidor
As duas áreas onde o problema costuma ser organizacional em vez de técnico: ninguém é dono do gestor de etiquetas, e ninguém é dono da escolha de alojamento.
| Gestor de etiquetas com etiquetas desconhecidas | Auditar cada uma; remover o que ninguém justifica |
| Widget de chat em todas as páginas | Carregar por interação, ou só onde é preciso apoio |
| Várias ferramentas de análise | Manter uma; cada uma é um script e uma ligação |
| Script de testes A/B a bloquear a renderização | Mover para o servidor, ou aceitar um flash e carregar async |
| TTFB lento em alojamento partilhado | Cache de página completa; subir de plano se persistir |
| Consultas sem cache | Colocar em cache as caras; criar índices para as frequentes |
| Sem CDN | Acrescentar um — a correção de latência global mais barata |
Os scripts de terceiros são a fonte mais fiável de lentidão inexplicada, porque mudam sem avisar e ficam fora do seu processo de publicação.

Q: O que é um bom tempo de carregamento?
A: Os objetivos úteis são os limiares dos Core Web Vitals em vez de um número único: LCP abaixo de 2,5 segundos e Time to First Byte abaixo de 800 ms. O tempo total de carregamento é má medida, porque uma página pode ser utilizável muito antes de todos os ficheiros terminarem — e, num aparelho lento, inutilizável muito antes disso.

Q: Um site mais rápido aumenta a conversão?
A: Normalmente sim, e o efeito é maior onde as páginas estão lentas e os visitantes usam redes móveis. O ganho de três segundos para dois é muito superior ao de um e meio para um. Se o site já é rápido, invista o esforço em conteúdo e clareza — o retorno é melhor.

Q: As extensões de cache resolvem tudo?
A: Resolvem bem uma coisa real — trabalho repetido do servidor para a mesma página — e podem criar problemas novos, sobretudo com utilizadores autenticados, carrinhos e formulários. Também não fazem nada quanto a imagens demasiado grandes ou scripts de terceiros, que costumam ser os problemas maiores. Úteis, não suficientes.

Q: Renderizar no servidor compensa em velocidade?
A: Se as suas páginas são hoje renderizadas apenas no navegador, sim: renderizar no servidor ou gerar estaticamente elimina uma ida e volta inteira antes de o conteúdo aparecer, e ajuda a indexação ao mesmo tempo. Se as páginas já são HTML gerado no servidor, a questão não se coloca — já tem a vantagem.

## WordPress, Webflow ou à medida: qual encaixa no seu projeto
https://websitedevelopment.biz/pt/guides/wordpress-webflow-ou-a-medida
Atualizado a 2026-08-07 · CMS

A maioria dos sites de empresa acaba por chegar a estas três opções, e elas diferem menos no que conseguem fazer do que no que exigem de si — em dinheiro, em atenção e em capacidade técnica.

Este guia compara-as nos pontos que contam ao fim de um ano, e dá por opção o perfil de projeto para o qual é a certa.

### A comparação
As diferenças que contam na prática, sem as listas de funcionalidades que as três cumprem.
| Custo inicial | Baixo a médio | Médio | Alto |
| Custo fixo | Alojamento mais manutenção | Subscrição mensal | Alojamento; manutenção conforme necessário |
| Liberdade de desenho | Alta com tema à medida | Muito alta dentro da plataforma | Total |
| Facilidade de edição | Familiar, por vezes confusa | Excelente visualmente | Exatamente o que construir |
| Peso da manutenção | Significativo — extensões e atualizações | Praticamente nenhum | Baixo, mas real |
| Saída | Exportação completa possível | Limitada; a plataforma é o site | Você é dono de tudo |
| Equipa necessária | Programador ou agência | Designer | Programador |

### Quem deve escolher WordPress
O WordPress continua a ser a escolha por omissão por boas razões, desde que a manutenção tenha um dono.
- Publica com regularidade e quer uma experiência de edição que toda a gente já conhece.
- Precisa de funcionalidade para a qual existe uma extensão madura — eventos, subscrições, loja.
- Não quer custos mensais de plataforma e aceita alojamento mais manutenção.
- Tem agência ou programador que assume atualizações, cópias e segurança.
- Quer liberdade de mudar de fornecedor mais tarde sem reconstruir o site.
- Evite quando: ninguém vai fazer a manutenção. É a única forma comum de esta escolha falhar.
- Mantenha o número de extensões baixo; é o fator que mais determina o peso da manutenção.

### Quem deve escolher Webflow
O Webflow encaixa quando o desenho manda e ninguém quer assumir manutenção técnica.
- Um designer constrói e mantém o site sem programador.
- O desenho é particular e adaptar um tema daria mais trabalho do que construir de novo.
- Não quer gerir atualizações, cópias nem segurança — está incluído.
- O site é sobretudo marketing: páginas, casos, um blogue, formulários.
- Evite quando: precisa de funcionalidade própria no servidor, ou de integrações complexas.
- Considere a saída: o código exportado não traz a gestão de conteúdo, por isso sair implica em grande parte reconstruir.
- Faça as contas à mensalidade a três anos e compare com alojamento mais manutenção noutro sítio.
O caminho de saída é o compromisso mais importante e o menos discutido. Pondere-o explicitamente em vez de o descobrir quando quiser sair.

### Quem deve escolher à medida
À medida é a escolha certa em menos casos do que aqueles em que é proposta, mas nesses casos é claramente certa.
| O site é o produto | Sim |
| Modelo de conteúdo invulgar que nenhum CMS representa bem | Sim |
| Integração profunda com sistemas internos | Sim |
| Exigências rigorosas de desempenho ou segurança | Sim |
| Site de marketing com um blogue | Não — está a pagar por nada |
| Sem capacidade técnica contínua | Não — código à medida sem manutenção fica órfão |
| Orçamento apertado e prazo curto | Não |
Numa proposta à medida, pergunte sempre que problema concreto um CMS existente não resolveria. Se não houver resposta clara, está a comprar complexidade.

Q: O WordPress ainda é boa escolha?
A: Sim, para a maioria dos sites de empresa. As críticas referem-se quase sempre a instalações mal mantidas com extensões a mais, não à plataforma. Um site WordPress com tema à medida, poucas extensões e manutenção a sério é rápido, seguro e agradável de usar.

Q: O Webflow é mais caro que o WordPress?
A: Mensalmente costuma ser; no total é menos evidente. Com WordPress paga alojamento mais manutenção, e essa manutenção é trabalho real que alguém faz. Faça as contas a três anos com horas de manutenção reais incluídas, em vez de comparar apenas o preço da subscrição.

Q: Quando é que à medida compensa mesmo?
A: Quando um CMS existente não resolve o seu problema concreto: um modelo de conteúdo invulgar, integrações profundas com sistemas internos, ou exigências de desempenho e segurança acima do que uma plataforma partilhada oferece. Para um site de marketing com blogue, à medida é pagar liberdade que não vai usar.

Q: Posso mudar de plataforma depois?
A: Do WordPress relativamente bem — o conteúdo exporta-se e o modelo de dados é conhecido. Do Webflow com mais dificuldade, porque a exportação dá o site como código mas não a gestão por trás; sair implica em boa parte reconstruir. Em código à medida depende de quão limpo foi construído. Pergunte pelo caminho de saída antes de começar.

## Core Web Vitals: o que move realmente os números
https://websitedevelopment.biz/pt/guides/core-web-vitals-para-programadores
Atualizado a 2026-08-07 · SEO

Os Core Web Vitals são três medições de campo sobre como uma página se sente: quanto demora a aparecer o conteúdo principal, quanto ele salta durante o carregamento, e com que rapidez a página responde ao toque.

Este guia cobre o que cada métrica mede, as causas concretas de más pontuações, e as correções que movem dados de campo em vez de moverem apenas pontuações de laboratório.

### O que as três métricas medem
Cada uma tem um limiar de «bom» e um pequeno conjunto de causas habituais. Note que o número que conta para posicionamento são os dados de campo de visitantes reais, não uma pontuação obtida no seu portátil.
| LCP | Abaixo de 2,5 s | Tempo até desenhar o maior elemento visível | Imagem principal por otimizar, servidor lento, CSS bloqueante |
| CLS | Abaixo de 0,1 | Quanto a disposição salta ao carregar | Imagens sem dimensões, banners inseridos, tipos que chegam tarde |
| INP | Abaixo de 200 ms | Rapidez de resposta à interação | Tarefas longas de JavaScript a bloquear a thread principal |
As ferramentas de laboratório medem um carregamento numa máquina. Os dados de campo são o percentil 75 de visitas reais, incluindo telemóveis antigos em redes más — precisamente os visitantes que desistem mais depressa.

### Corrigir o LCP
O LCP é quase sempre uma imagem ou um título bloqueado por outra coisa. Percorra estes pontos por ordem; os dois primeiros resolvem a maioria dos sites.
- Identifique qual é realmente o elemento LCP nos dados de campo. Otimizar a imagem errada é o desperdício mais comum.
- Nunca carregue a imagem do LCP de forma diferida. Dê-lhe fetchpriority="high".
- Sirva-a em formato moderno, no tamanho em que é apresentada, com srcset para ecrãs menores.
- Pré-carregue o tipo de letra do texto do LCP e use font-display: swap.
- Retire CSS e JavaScript bloqueantes do head; incorpore o CSS crítico se a página for pequena.
- Reduza o Time to First Byte com cache e CDN — nenhum trabalho de front-end compensa um servidor lento.
- Corte scripts de terceiros do caminho crítico. Cada um é uma resolução de DNS, uma ligação e um ficheiro imprevisível.

### Corrigir o CLS
O salto de disposição é quase inteiramente evitável e as correções são baratas. É também a métrica que os visitantes mais sentem, porque é o que os faz tocar na coisa errada.
- Defina width e height em todas as imagens e vídeos para o navegador reservar espaço.
- Reserve espaço para anúncios, incorporações e iframes com um contentor de proporção fixa.
- Nunca insira conteúdo por cima de conteúdo existente depois do carregamento — o aviso de cookies deve ficar em baixo ou em sobreposição.
- Ajuste as métricas do tipo de recurso ao tipo web, ou use size-adjust, para que a troca não reorganize a página.
- Evite animar propriedades de disposição. Anime transform e opacity, que não forçam recálculo.
- Dê min-height às secções carregadas dinamicamente para não expandirem a partir do zero.

### Corrigir o INP
O INP substituiu o First Input Delay e é mais difícil, porque mede todas as interações da visita e não apenas a primeira. Mau INP é quase sempre JavaScript a mais na thread principal.
| Pacote grande processado ao carregar | Dividir código; carregar só o que a página usa |
| Tarefas longas acima de 50 ms | Partir o trabalho e devolver a thread |
| Manipuladores de eventos caros | Aplicar debounce e tirar trabalho pesado do caminho de interação |
| Etiquetas de terceiros pesadas | Carregar após interação, ou remover — verifique o que cada uma dá |
| DOM grande, acima de 10 000 nós | Virtualizar listas longas; simplificar aninhamento profundo |
| Leituras e escritas alternadas no layout | Agrupar leituras e escritas em vez de alternar |
Em sites de conteúdo, a intervenção mais valiosa no INP costuma ser remover JavaScript em vez de o otimizar. Pergunte o que cada script traz; os gestores de etiquetas acumulam scripts que ninguém se lembra de ter acrescentado.

Q: Quanto pesam os Core Web Vitals no posicionamento?
A: São um sinal real mas modesto, que funciona mais como desempate do que como substituto de relevância. Uma página rápida sobre o assunto errado não vence uma página mais lenta que responde à pergunta. O argumento mais forte para os corrigir é comportamental: páginas lentas e instáveis perdem visitantes antes de o posicionamento sequer entrar em jogo.

Q: Porque tenho boa pontuação no Lighthouse e maus dados de campo?
A: Porque o Lighthouse simula um carregamento na sua máquina e com a sua ligação, e os dados de campo são o percentil 75 de visitas reais — incluindo telemóveis de três anos em redes congestionadas. Quando os dois se contradizem, os dados de campo é que contam. Use o laboratório para diagnosticar, não para pontuar.

Q: Tenho de corrigir as três métricas?
A: Corrija as que estão a falhar, pela ordem do que os seus visitantes sentem. O CLS costuma ser o mais barato de resolver e o mais irritante para quem usa, por isso é um bom ponto de partida. O LCP tem o maior efeito sobre se as pessoas esperam. O INP pesa mais em sites interativos e menos em artigos estáticos.

Q: Quanto tempo até as melhorias aparecerem?
A: Os dados de campo são uma janela deslizante de 28 dias, por isso movimento significativo demora cerca de quatro semanas depois de a correção chegar a todos os visitantes. Não avalie uma alteração ao fim de três dias. Verifique de imediato os valores de laboratório para confirmar que a correção fez o que esperava.

## Headless CMS ou CMS tradicional: a comparação honesta
https://websitedevelopment.biz/pt/guides/headless-cms-ou-cms-tradicional
Atualizado a 2026-08-07 · CMS

Um CMS tradicional guarda o conteúdo e apresenta as páginas. Um CMS headless guarda o conteúdo e entrega-o por API, cabendo-lhe a si decidir como é apresentado. É essa a diferença inteira, e todos os compromissos decorrem dela.

Este guia cobre o que ganha com headless, o que custa, e quando essa troca compensa.

### O que muda de facto
A diferença é arquitetural, não de funcionalidades. Ambos editam conteúdo; distinguem-se em quem constrói a apresentação.
| Apresentação | O CMS apresenta as páginas | Você constrói o front-end |
| Pré-visualização | Integrada e fiel | Constrói-a você, ou é aproximada |
| Liberdade de desenho | Dentro do sistema de modelos | Total |
| Vários canais | Difícil — o site é a saída | É o centro do desenho |
| Velocidade de arranque | Rápida — os temas existem | Mais lenta — constrói tudo |
| Competência exigida | Média | Desenvolvimento front-end obrigatório |
| Manutenção | Um sistema | Dois sistemas, dois processos de publicação |

### O que headless dá realmente
Os benefícios são reais, mas aplicam-se a situações específicas em vez de em geral.
- Vários canais a partir de uma fonte: site, aplicação, quiosque, newsletter — mesmo conteúdo, apresentações diferentes.
- Liberdade total de desenho e desempenho: sem herança de tema, sem CSS por usar.
- Geração estática: construir páginas antecipadamente e servi-las como ficheiros, o que é muito rápido e muito seguro.
- Substituir o front-end sem migrar: o conteúdo fica onde está.
- Modelo de conteúdo mais limpo: campos em vez de páginas com marcação embutida.
- Superfície de ataque menor: o painel de gestão não está no mesmo endereço público do site.
Note que a maioria destes benefícios só conta se tiver vários canais ou uma limitação de desempenho ou desenho que um tema não resolva.

### O que custa
Estes custos são sistematicamente subestimados nas comparações, e explicam porque projetos headless encalham mais.
| Dois sistemas | Duas bases de código, dois processos, duas fontes de erro |
| Pré-visualização | Os editores esperam-na; tem de a construir |
| Tudo é à medida | Formulários, pesquisa, paginação, redirecionamentos — tudo seu |
| Necessidade contínua de programador | Não há tema para instalar quando algo muda |
| Conforto dos editores | Campos sem contexto são mais abstratos que editar uma página |
| Componentes de SEO | Mapa do site, canónicos, hreflang — sua responsabilidade |
| Custo inicial mais alto | Nitidamente mais caro de arrancar que um site com tema |
«Tudo é à medida» é a rubrica que mais surpreende. Funcionalidade que um CMS tradicional oferece de graça torna-se, em headless, uma série de pequenas tarefas de construção.

### Quem deve escolher headless
Uma regra de decisão curta que evita a maioria das escolhas erradas.
- Publica para mais do que um canal? Se sim, headless é provavelmente acertado.
- Tem equipa ou agência de front-end permanente? Sem isso, a necessidade contínua é um problema.
- Um tema consegue fazer o seu desenho? Se consegue, está a comprar liberdade que não usa.
- Tem uma exigência de desempenho que cache num CMS tradicional não cumpre? Normalmente não tem.
- Prevê substituir o front-end nos próximos anos? Aí a separação vale.
- Os seus editores estão confortáveis com campos estruturados sem página visual? Teste, não adivinhe.
- Se hesitar em mais de duas destas, escolha tradicional — é a opção de recurso por bons motivos.

Q: Headless é melhor para SEO?
A: Não inerentemente, e pode ser pior se construir sem cuidado. Páginas geradas estaticamente são excelentes para SEO; páginas apresentadas só no navegador não são. Além disso, tem de construir mapa do site, canónicos, hreflang e redirecionamentos, que um CMS tradicional já traz. A arquitetura não decide — a execução decide.

Q: Posso passar de tradicional para headless?
A: Sim, e é das migrações mais favoráveis porque o conteúdo continua estruturado. Alguns CMS tradicionais, incluindo o WordPress, podem servir como fonte headless através da sua API. Isso dá-lhe um meio-termo: edição familiar para a redação, front-end próprio para a apresentação.

Q: Headless é mais caro?
A: Para arrancar, quase sempre, porque constrói o que um tema já traz. Ao longo de vários anos depende: se tem vários canais ou substitui o front-end com regularidade, pode sair mais barato. Para um site que vai durar cinco anos, tradicional costuma ser mais barato no total.

Q: Os editores gostam de headless?
A: Depende inteiramente de quão bem construiu o modelo de conteúdo e a pré-visualização. Campos sem contexto são mais abstratos do que editar uma página que se parece com a página. Com boa pré-visualização e grupos de campos lógicos, funciona bem. Sem isso, é a fonte mais comum de insatisfação.

## Checklist de SEO técnico para quem constrói sites
https://websitedevelopment.biz/pt/guides/checklist-de-seo-tecnico
Atualizado a 2026-08-07 · SEO

SEO técnico é a parte do trabalho de pesquisa que vive no código e não num calendário de conteúdos. É em grande medida uma lista de verificação, e a maior parte é verificável em vez de opinável.

Este guia é essa lista, agrupada pelo problema que cada ponto evita, com os erros que aparecem vezes suficientes para merecerem menção.

### Controlo de indexação
O objetivo é que estejam indexadas exatamente as páginas que quer, e mais nenhuma — sem cópias de testes, sem permutações de filtros, sem versões para impressão.
- Uma versão canónica do domínio; todas as outras redirecionam com 301, incluindo HTTP e o par com e sem www.
- URL canónico autorreferente em cada página indexável.
- noindex, follow em páginas fracas ou duplicadas: resultados de pesquisa interna, combinações de filtros, páginas de agradecimento.
- Nunca bloqueie no robots.txt uma página que tenha noindex — a etiqueta nunca chega a ser lida e o URL fica preso no índice.
- Ambiente de testes protegido com autenticação, não apenas com robots.txt.
- Política de parâmetros definida: que query strings criam uma página distinta e quais não criam.
noindex e bloqueio no robots.txt fazem coisas opostas e anulam-se. Se quer uma página fora do índice, permita o rastreio para que a etiqueta seja vista.

### Redirecionamentos e códigos de estado
É nos redirecionamentos que os relançamentos perdem tráfego em silêncio. Os erros são mecânicos e fáceis de testar antes de publicar.
| Página movida definitivamente | 301 para a equivalente | 302, ou redirecionar para a entrada |
| Página removida sem equivalente | 410 ou 404 | 404 falso: página de erro que devolve 200 |
| Indisponibilidade temporária | 503 com Retry-After | Devolver 200 com uma mensagem de erro |
| Variantes com e sem barra final | Uma forma canónica, a outra com 301 | Servir ambas com 200 |
| Domínio antigo | 301 mapeado página a página | Tudo para a entrada do novo domínio |
| Cadeias de redirecionamento | Reduzir a um salto | A → B → C → D, com perda em cada passo |

### Paginação, filtros e duplicação
As páginas de listagem causam os maiores problemas de índice, porque meia dúzia de filtros pode gerar milhares de URL quase iguais.
- Páginas paginadas: ligações reais rastreáveis, cada página com canónico autorreferente — não faça a página 2 canónica para a 1.
- Combinações de filtros: noindex, follow por omissão; indexe apenas o pequeno número que corresponde a procura real.
- Ordenações: nunca criam um URL indexável novo. O mesmo conteúdo, outra ordem.
- Parâmetros de sessão e de campanha: elimine-os, ou torne-os canónicos para o URL limpo.
- Versões para impressão e duplicados equivalentes: canónicos para a versão principal.
- Produtos em várias categorias: um URL canónico, ligado a partir de todas elas.
Navegação por filtros sem restrição é a causa mais comum de poluição do índice, e limpa-se devagar. É muito mais barato evitá-la na construção do que revertê-la depois.

### Dados estruturados e configuração internacional
Duas áreas onde um único erro mecânico desativa a funcionalidade inteira sem aviso.
| Marcação Article | Só em artigos reais, com datas verdadeiras | Datas inventadas fazem ignorar a funcionalidade |
| Marcação Product | Preço e disponibilidade iguais aos da página | Divergência gera ação manual |
| Marcação FAQ | Só perguntas visíveis na página | Conteúdo escondido viola as diretrizes |
| Migalhas de pão | Devem corresponder ao caminho visível | Caminhos divergentes são ignorados |
| hreflang | Recíproco em todas as páginas do conjunto | Etiquetas num só sentido anulam o grupo |
| Códigos hreflang | O mesmo código no HTML e no mapa do site | Dois códigos para a mesma página partem o grupo |
| x-default | Aponta para o seletor ou versão padrão | Sem ele, perde o comportamento de recurso |

Q: Como encontro problemas técnicos num site existente?
A: Rastreie-o com uma ferramenta de desktop e compare o resultado com o seu mapa do site e com a cobertura na consola de pesquisa. Onde as três listas divergirem estão os problemas: URL no rastreio mas não no mapa, URL indexados mas fora do rastreio, e páginas excluídas por motivos que não pretendia.

Q: As cadeias de redirecionamento importam mesmo?
A: Sim, por duas razões. Cada salto acrescenta latência para pessoas reais, e os rastreadores deixam de seguir ao fim de alguns saltos. Depois de algumas migrações, é comum encontrar cadeias com quatro ou cinco níveis que ninguém planeou. Reduza-as para que cada URL antigo aponte diretamente para o destino final.

Q: Devo pôr páginas de etiquetas em noindex?
A: Só se forem realmente fracas. Uma página de categoria com descrição própria, uma lista curada e ligações internas é uma página de entrada legítima e muitas vezes forte. Uma página de etiqueta com dois artigos e nenhum texto é poluição. Avalie cada modelo pela pergunta: responde a algo que as pessoas procuram?

Q: O que parte mais frequentemente o hreflang?
A: Etiquetas não recíprocas. Se a página em português declara a versão inglesa mas a inglesa não declara a portuguesa, o grupo inteiro é anulado. O segundo erro mais comum é usar um código no HTML e outro no mapa do site para a mesma página. Gere ambos a partir da mesma fonte para que não possam divergir.

## Ferramentas de desenvolvimento web que valem a pena
https://websitedevelopment.biz/pt/guides/melhores-ferramentas-de-desenvolvimento-web
Atualizado a 2026-08-07 · Desenvolvimento web

Há mais ferramentas de desenvolvimento web do que tempo para as avaliar, e a maioria das listas é apenas uma enumeração de nomes. O que interessa é qual o problema que cada uma resolve.

Este guia agrupa as ferramentas por problema, indica o que a maioria dos projetos precisa realmente, e assinala onde adicionar ferramentas piora as coisas.

### O essencial, independentemente do projeto
Se um projeto não tem isto, o problema não é falta de ferramentas melhores.
| Escrever código | VS Code ou equivalente | Com formatação automática configurada |
| Histórico e reversão | Git, com repositório remoto | Inegociável |
| Testar em vários navegadores | Ferramentas do navegador | Já as tem instaladas |
| Medir desempenho | Lighthouse e dados de campo | Laboratório diagnostica, campo decide |
| Verificar acessibilidade | Extensão gratuita de auditoria | Apanha cerca de um terço |
| Analisar tráfego | Uma ferramenta, não três | Cada uma é peso na página |
| Monitorizar disponibilidade | Serviço de monitorização | Com verificação de conteúdo |

### Por fase do projeto
Ferramentas que valem a pena em momentos específicos e que não precisam de estar sempre presentes.
- Desenho: Figma para ecrãs e entrega de especificações.
- Estrutura: qualquer ferramenta de diagramas para o mapa do site.
- Conteúdo: uma folha de cálculo partilhada com o inventário de páginas e responsáveis.
- Construção: um ambiente local reproduzível, para que a equipa tenha a mesma configuração.
- Testes: um serviço de rastreio para verificar ligações, títulos e redirecionamentos.
- Migração: um script que testa a lista completa de URL antigos contra os novos.
- Lançamento: consola de pesquisa e verificação de erros no servidor.
- Depois: monitorização, cópias de segurança e alertas de segurança.

### Onde acrescentar ferramentas piora
Cada ferramenta tem custo de configuração, de aprendizagem e de manutenção. Estas são as adições que costumam sair caras.
| Três ferramentas de análise | Três scripts, três verdades diferentes |
| Gestor de etiquetas sem dono | Acumula scripts que ninguém consegue justificar |
| Framework para um site estático | Complexidade sem benefício |
| Dezenas de extensões no CMS | Superfície de ataque e trabalho de atualização |
| Testes automáticos sem critério | Manutenção de testes que ninguém lê |
| Publicação automatizada complexa | Só compensa acima de certa frequência |
| Ferramenta de otimização de imagens manual | Deixa de ser usada assim que outra pessoa carrega imagens |
A regra prática é acrescentar uma ferramenta quando um problema real dói duas vezes, não antecipadamente.

### Escolher stack sem seguir modas
Critérios que envelhecem bem, aplicáveis a qualquer tecnologia que esteja na moda no momento.
- Escolha o que quem vai manter o site consegue manter, não o que é mais interessante de construir.
- Prefira tecnologias com comunidade grande: encontrar quem as conheça é um requisito real.
- Verifique quantas dependências entram com a escolha. Cada uma é manutenção futura.
- Prefira o que gera HTML no servidor, salvo se houver razão concreta para o contrário.
- Verifique se a escolha continua adequada quando o site triplicar de tamanho.
- Desconfie de qualquer tecnologia sem versão estável há muito tempo.
- Pergunte a quem propõe o que aconteceria se essa tecnologia deixasse de ser mantida.

Q: Preciso de um framework de JavaScript?
A: Para um site institucional ou um blogue, quase nunca. Frameworks resolvem interfaces com muito estado — painéis, aplicações, ecrãs com interação complexa. Num site de conteúdo, acrescentam peso e uma camada de renderização que pode prejudicar a indexação sem qualquer benefício visível para o visitante.

Q: Que ferramenta de análise devo usar?
A: Uma só. A escolha específica importa menos do que a decisão de não ter três a competir pelo mesmo tráfego e a produzir números diferentes. Se privacidade for uma preocupação, existem alternativas leves e sem cookies que evitam o aviso de consentimento e pesam muito menos na página.

Q: Vale a pena automatizar a publicação?
A: Acima de uma publicação por semana, claramente. Abaixo disso, um processo manual bem documentado pode chegar. O que não deve fazer é publicar por FTP manual sem qualquer registo do que foi alterado — isso não é uma questão de automatização, é falta de rasto para diagnosticar problemas.

Q: As ferramentas de IA mudam isto?
A: Aceleram bastante escrever código, gerar variantes e explorar soluções. Não substituem decidir o que construir, verificar se está correto, nem desenhar algo que se consiga manter daqui a três anos. O melhor uso prático é como acelerador de trabalho rotineiro, com revisão humana do que sai.

## Design system para sites: quando vale a pena
https://websitedevelopment.biz/pt/guides/design-system-para-sites
Atualizado a 2026-08-07 · Design web

Um design system é um conjunto partilhado de decisões visuais e de componentes reutilizáveis. Bem feito, acelera todo o trabalho seguinte. Mal dimensionado, torna-se um projeto paralelo que consome tempo e fica desatualizado.

Este guia mostra o que incluir, quando compensa, e como começar sem construir uma biblioteca que ninguém vai usar.

### O que inclui, do essencial ao acessório
Comece pelo topo desta lista. Os primeiros itens resolvem a maior parte do problema.
| Fundações | Cores, tipografia, escala de espaçamento | Essencial |
| Elementos | Botões, campos, ligações, etiquetas | Essencial |
| Padrões | Formulários, cartões, navegação, tabelas | Alta |
| Modelos | Estruturas de página completas | Média |
| Diretrizes de escrita | Tom, rótulos, mensagens de erro | Alta e muito esquecida |
| Regras de uso | Quando usar cada componente | Média |
| Documentação viva | Exemplos que correm código real | Depende da dimensão |
As diretrizes de escrita são a camada mais subestimada. Rótulos e mensagens inconsistentes prejudicam a experiência tanto como componentes inconsistentes.

### Quando compensa
Um design system tem custo de criação e de manutenção. Compensa quando há repetição suficiente para o amortizar.
- Vários produtos ou sites que devem parecer da mesma marca.
- Uma equipa com mais do que uma pessoa a desenhar ou a construir interfaces.
- Um site grande com muitos modelos e crescimento previsto.
- Rotatividade de fornecedores, em que consistência depende de documentação.
- Não compensa: um site institucional de dez páginas com um único responsável.
- Não compensa: quando o site vai ser refeito dentro de um ano.
- Nesses casos, um ficheiro de estilos com cores, tipos e botões chega perfeitamente.

### Começar pequeno
A forma mais fiável de ter um design system é extraí-lo do que já existe, em vez de o desenhar em abstrato.
- Faça um inventário do que existe: fotografe todos os botões, campos e cartões do site atual.
- Vai encontrar variações a mais. Escolha uma de cada e elimine as restantes.
- Defina os tokens: cores, tipos, espaçamentos, raios, sombras — como variáveis nomeadas.
- Construa os cinco a dez componentes que aparecem em todo o lado.
- Documente cada um com os estados e uma nota sobre quando usar.
- Aplique num modelo real antes de continuar; a aplicação revela o que falta.
- Só depois expanda, e apenas quando um componente for necessário mais do que duas vezes.
Um sistema extraído do site real usa-se; um sistema desenhado em abstrato fica bonito na documentação e é ignorado na prática.

### Como morrem os design systems
Os modos de falha são previsíveis e quase todos organizacionais.
| Ninguém é responsável | Deixa de ser atualizado | Um dono com tempo alocado |
| Desatualizado face ao código | Documentação mente | Gerar a partir do código real |
| Demasiado rígido | Equipas contornam-no | Permitir exceções documentadas |
| Demasiado grande | Ninguém encontra nada | Começar com dez componentes |
| Sem adesão | Componentes duplicados fora do sistema | Envolver quem o vai usar desde o início |
| Só desenho, sem código | Programadores reimplementam à mão | Componentes reais, não só ecrãs |

Q: Preciso de um design system para um site pequeno?
A: Não. Para um site institucional com um responsável, um ficheiro de estilos com cores, tipografia, espaçamentos e alguns componentes chega e cumpre a mesma função. Um sistema formal só compensa quando há várias pessoas ou vários produtos a manter coerência entre si.

Q: Quanto tempo demora criar um?
A: Uma versão inicial útil — tokens mais dez componentes — leva duas a quatro semanas. Um sistema completo com documentação, código e diretrizes leva meses e nunca fica verdadeiramente terminado, porque acompanha o produto. Comece pequeno e aplique-o cedo, em vez de tentar chegar a completo antes de usar.

Q: Devo usar uma biblioteca já existente?
A: Muitas vezes sim, sobretudo em aplicações internas onde a identidade visual importa menos do que a velocidade. Uma biblioteca madura dá-lhe componentes acessíveis e testados de imediato. Personalize-a com os seus tokens em vez de construir tudo de raiz — construir componentes acessíveis do zero é mais trabalho do que parece.

Q: Quem deve ser responsável pelo design system?
A: Uma pessoa nomeada, com tempo efetivamente alocado. Sem dono, o sistema desatualiza-se em meses e passa a ser um obstáculo em vez de uma ajuda, porque a documentação deixa de corresponder ao produto. Este é o modo de falha mais comum, e é organizacional e não técnico.

## Checklist de lançamento de um site
https://websitedevelopment.biz/pt/guides/checklist-de-lancamento-de-site
Atualizado a 2026-08-07 · Planeamento do site

O lançamento é o momento em que erros pequenos ficam públicos. A maioria é banal e completamente evitável com uma lista, e é sempre a mesma meia dúzia que aparece.

Esta é essa lista, dividida por momento e ordenada pelo que apanha mais problemas primeiro.

### Antes do lançamento: técnico
Verificações no ambiente de testes, com o site ainda fechado ao público.
- Robots.txt de produção permite rastreio — a versão de testes não pode seguir.
- Nenhuma etiqueta noindex esquecida do ambiente de testes.
- HTTPS ativo com certificado válido e renovação automática configurada.
- Uma só versão canónica do domínio; todas as outras redirecionam com 301.
- Todos os formulários testados até ao fim, incluindo a chegada do e-mail.
- Cópias de segurança automáticas configuradas e uma restauração testada.
- Página 404 útil, com ligações para as secções principais.
- Análise instalada e a registar, verificada em tempo real.
- Velocidade medida nos modelos principais, num telemóvel real.
O robots.txt de testes em produção é o erro clássico deste dia. Verifique-o a partir de fora da sua rede, não do ambiente de trabalho.

### Antes do lançamento: conteúdo e SEO
Encontrar isto depois do lançamento é constrangedor e às vezes caro.
| Texto de exemplo removido | Aparece sempre numa página esquecida |
| Títulos e descrições únicos | Duplicados prejudicam e ficam mal nos resultados |
| Imagens com texto alternativo | Acessibilidade e pesquisa de imagens |
| Ligações internas verificadas | Ligações para o domínio de testes são comuns |
| Contactos e morada corretos | Erros aqui custam negócio diretamente |
| Mapa do site XML gerado | Acelera a descoberta |
| Mapeamento de URL antigos | Numa migração, é o que preserva tráfego |
| Imagens otimizadas | Peso da página é o que mais degrada rápido |

### Antes do lançamento: jurídico e acessos
A parte que ninguém quer verificar e que causa problemas reais.
- Política de privacidade que descreve os dados que recolhe efetivamente.
- Aviso de cookies que só carrega rastreio depois do consentimento.
- Termos e condições, obrigatórios se vende online.
- Dados da empresa visíveis, conforme a legislação aplicável.
- Domínio registado em nome da sua empresa, com acesso na sua posse.
- Alojamento, análise e contas de e-mail em contas suas.
- Código-fonte entregue e num repositório a que tem acesso.
- Credenciais transferidas e as do fornecedor removidas quando fizer sentido.
Verifique a propriedade do domínio e das contas antes do lançamento. Depois, resolver isto depende da boa vontade de quem as tem.

### No dia e nas semanas seguintes
O lançamento é curto; a janela de atenção não é.
- Lance num momento calmo, não a uma sexta-feira ao fim do dia.
- Verifique o robots.txt em produção como primeira ação depois de publicar.
- Percorra o site a partir de outra rede e de um telemóvel real.
- Submeta o mapa do site na consola de pesquisa.
- Volte a testar os formulários em produção — a configuração de e-mail difere do ambiente de testes.
- Se houve migração, corra o teste de redirecionamentos contra a lista completa de URL.
- Acompanhe os erros 404 nos primeiros dias e acrescente redirecionamentos conforme aparecem.
- Compare tráfego e posições durante quatro a seis semanas antes de tirar conclusões.

Q: Qual é o erro mais comum no lançamento?
A: O ficheiro robots.txt do ambiente de testes ir para produção e bloquear todo o rastreio. É invisível para os visitantes, por isso pode passar semanas despercebido enquanto o site simplesmente não aparece na pesquisa. Verifique-o como primeira ação depois de publicar, a partir de fora da sua rede.

Q: Devo lançar tudo de uma vez?
A: Para um site novo, sim — não há nada a preservar. Para uma migração, um lançamento faseado por secção reduz o risco e permite ver o efeito de cada parte. O que não deve fazer é lançar metade e deixar a outra metade no domínio antigo durante meses: duas versões do mesmo conteúdo competem entre si.

Q: Quanto tempo demora a aparecer na pesquisa?
A: Dias a semanas para indexação, meses para posições que signifiquem alguma coisa num domínio novo. Numa migração de um site existente com redirecionamentos limpos, conte com duas a seis semanas de oscilação antes de estabilizar perto do nível anterior. Não tire conclusões na primeira semana.

Q: O que faço se algo correr mal depois de publicar?
A: Tenha decidido antes qual é o critério para reverter e quem toma essa decisão. Se for grave e recente, reverter primeiro e diagnosticar depois é quase sempre mais barato. Para problemas menores, uma lista priorizada e correções ao longo dos primeiros dias funciona melhor do que corrigir em pânico durante a noite.

## O que é um CMS e se precisa mesmo de um
https://websitedevelopment.biz/pt/guides/o-que-e-um-cms
Atualizado a 2026-08-07 · CMS

Um sistema de gestão de conteúdos é software que permite a pessoas sem conhecimentos de código alterar o conteúdo de um site. É essa a definição inteira; o resto é desenvolvimento.

Este guia cobre o que um CMS realmente resolve, os tipos que existem, e a pergunta que é saltada mais vezes do que feita: precisa mesmo de um?

### O que um CMS realmente faz
Por baixo da interface de edição, um CMS resolve um pequeno conjunto de problemas concretos. Vale a pena enumerá-los, porque assim consegue ver se os tem.
- Editar sem código: alterar texto, imagens e páginas a partir de um navegador.
- Estrutura: guardar conteúdo como campos em vez de como marcação, para poder ser reutilizado.
- Permissões: quem escreve, quem publica, quem altera definições.
- Fluxo de trabalho: rascunhos, agendamento, revisões e regressar a uma versão anterior.
- Multimédia: carregar, gerar tamanhos, e uma biblioteca para reencontrar ficheiros.
- Modelos: um modelo que apresenta cem páginas, mantendo conteúdo e desenho separados.
- Multilingue: o mesmo conteúdo em vários idiomas, ligado e gerível.
Se não reconhecer nesta lista um problema que tenha, provavelmente não precisa de um CMS — e a maioria dos sites pequenos genuinamente não precisa.

### Os tipos de CMS
As categorias distinguem-se por quem constrói o front-end e de onde o conteúdo é servido.
| Tradicional | O CMS guarda o conteúdo e apresenta as páginas | A maioria dos sites de empresa e blogues |
| Headless | O CMS entrega conteúdo por API; você constrói o front-end | Vários canais, ou aplicação própria |
| Construtor de sites | Edição visual, plataforma alojada | Sites pequenos sem equipa técnica |
| Baseado em ficheiros | Conteúdo em ficheiros de texto sob controlo de versões | Documentação e equipas técnicas |
| À medida | Exatamente os campos que este projeto precisa | Modelos de conteúdo invulgares |
| Sem CMS | Páginas estáticas, alterações via programador | Sites pequenos que raramente mudam |

### Quando precisa mesmo de um
A pergunta não é se um CMS é útil — é — mas se a comodidade compensa a complexidade que passa a assumir.
| Publicar semanalmente | Sim, claramente |
| Vários editores | Sim — permissões e fluxo são o essencial |
| Alteração de texto uma vez por mês | Não — um programador sai mais barato que a manutenção |
| Cinco páginas que nunca mudam | Não |
| Produtos que mudam diariamente | Sim |
| Site multilingue em crescimento | Sim — gerir à mão descarrila depressa |
| Páginas de campanha | Sim, se marketing as tiver de criar sozinho |
Um CMS de que não precisa não é gratuito: é software que tem de ser atualizado, protegido e copiado. É esse o custo real do «por precaução».

### O que verificar mesmo ao escolher
As listas de funcionalidades dos CMS parecem-se muito. Estas são as coisas que fazem diferença ao fim de um ano.
- Peça à pessoa que vai lá trabalhar todos os dias para criar uma página durante a avaliação. A reação dela prevê mais do que qualquer lista.
- Verifique se o seu modelo de conteúdo encaixa: campos, blocos repetíveis, relações entre tipos.
- Verifique o funcionamento multilingue se precisar dele — é onde os CMS mais diferem.
- Verifique o controlo de SEO: títulos editáveis, descrições, canónicos, redirecionamentos.
- Verifique quem o mantém e quanto custa, por mês, em horas ou euros.
- Verifique o caminho de saída: consegue exportar todo o conteúdo em formato utilizável?
- Verifique se escala para o número de páginas que prevê ter daqui a três anos.

Q: O WordPress é um CMS?
A: Sim, e é o CMS tradicional mais usado. Guarda o conteúdo, apresenta as páginas e oferece edição, permissões e multimédia. As críticas que recebe não são sobre se é um CMS, mas sobre a manutenção de extensões e a disciplina de segurança que exige.

Q: Posso ter um site sem CMS?
A: Claro, e para um site que raramente muda é muitas vezes a melhor escolha. Páginas estáticas são mais rápidas, mais seguras e praticamente sem manutenção. O compromisso é que qualquer alteração de texto passa por alguém com acesso aos ficheiros. Se muda uma frase por mês, isso sai mais barato do que manter um CMS.

Q: Qual a diferença entre CMS e construtor de sites?
A: Um construtor é uma plataforma alojada que junta edição, alojamento e modelos num só produto, dentro dos limites deles. Um CMS é software de gestão de conteúdo que pode alojar e personalizar. Construtores são mais fáceis de começar; CMS levam-se mais longe e são mais fáceis de abandonar.

Q: Um CMS torna o site mais lento?
A: Pode, porque há trabalho em cada pedido: consultar a base de dados, apresentar o modelo, executar extensões. Com cache, essa diferença fica pequena o suficiente para não decidir a escolha. O que torna um site verdadeiramente lento não costuma ser o CMS mas o que lhe carregam dentro — imagens grandes e scripts a mais.

## SEO no desenvolvimento: o que se constrói de raiz
https://websitedevelopment.biz/pt/guides/seo-basico-no-desenvolvimento-web
Atualizado a 2026-08-07 · SEO

Uma parte substancial do SEO não é marketing — são decisões tomadas durante o desenvolvimento, baratas durante a construção e caras depois. Estrutura de URL, forma de renderizar, ligações internas e metadados editáveis pertencem todos a essa categoria.

Este guia cobre o que se constrói desde o início, aproximadamente por ordem de quanto custa acrescentar mais tarde.

### Garantir que o site é rastreado e indexado
Tudo o resto é irrelevante se os motores de busca não conseguirem chegar às páginas nem lê-las. É também onde se acumulam os erros do dia de lançamento.
- O robots.txt de produção permite rastreio. A versão do ambiente de testes não pode seguir.
- Nenhuma etiqueta noindex esquecida do ambiente de testes.
- Cada página tem URL canónico autorreferente, e existe uma só versão canónica do domínio.
- O conteúdo vem no HTML ou é gerado no servidor. Se só aparecer depois do JavaScript correr, a indexação fica mais lenta e menos fiável.
- Mapa do site XML apenas com URL indexáveis e canónicos — sem variantes filtradas ou paginadas.
- Cada página indexável tem pelo menos uma ligação interna. Páginas órfãs quase não são rastreadas.
- Códigos de estado coerentes: 200 para páginas reais, 404 para inexistentes, 301 para movidas.
O erro de lançamento mais frequente desta lista é o robots.txt de testes ir para produção. Verifique-o no dia, a partir de fora da sua rede.

### Estrutura que os motores conseguem ler
As decisões estruturais são as que doem a mudar depois, porque mudar implica redirecionamentos e perda de sinais acumulados.
| Padrão de URL | Curto, minúsculas, hífenes, estável | Alto — redirecionamentos e sinais perdidos |
| Hierarquia de títulos | Um H1, sem saltar níveis | Baixo |
| Ligações internas | Páginas centrais que ligam a detalhe e de volta | Médio |
| Paginação | Ligações rastreáveis, não só JavaScript | Médio |
| Navegação por filtros | noindex nas combinações | Alto — o índice limpa devagar |
| Versões por idioma | URL com prefixo e hreflang recíproco | Muito alto |

### Metadados que a sua equipa consegue editar
Um erro comum é gerar títulos e descrições a partir de um modelo sem forma de os substituir. Seis meses depois, marketing precisa de mudar o título de uma página e a resposta é abrir um pedido de desenvolvimento.
- Título editável por página, com um valor gerado sensato por omissão.
- Descrição editável, com contagem de caracteres visível no CMS.
- Título, descrição e imagem de Open Graph editáveis para ligações partilhadas.
- Dados estruturados nos modelos que os suportam: Article, Product, FAQ, Breadcrumb, Organization.
- Interruptor de noindex por página, para páginas que devem existir sem posicionar.
- URL canónico automático, com possibilidade de substituição manual no caso raro em que é preciso.
Marque apenas o que está efetivamente visível na página. Dados estruturados a descrever conteúdo que o visitante não vê são uma violação das diretrizes, não um atalho.

### Velocidade e estabilidade como requisitos de construção
A experiência de página pertence à construção, não a um projeto de otimização posterior. Acrescentar velocidade a um site terminado significa quase sempre reverter decisões em vez de acrescentar código.
| Largest Contentful Paint | Abaixo de 2,5 s | Priorizar a imagem principal, evitar ficheiros bloqueantes |
| Cumulative Layout Shift | Abaixo de 0,1 | width e height nas imagens, espaço reservado |
| Interaction to Next Paint | Abaixo de 200 ms | Menos JavaScript, não bloquear a thread principal |
| Peso da página | O mais baixo que o desenho permitir | Formatos modernos, sem bibliotecas por usar |
| Time to First Byte | Abaixo de 800 ms | Cache, CDN e consultas sensatas |

Q: O SEO deve estar no contrato de desenvolvimento?
A: A parte técnica, sim — rastreio, estrutura de URL, metadados editáveis, dados estruturados, objetivos de velocidade e a lista de redirecionamentos. Estratégia de conteúdo e construção de ligações são trabalho separado, com outro perfil. Ter os requisitos técnicos no contrato significa que são orçamentados em vez de descobertos depois do lançamento, quando custam um múltiplo.

Q: Um framework de JavaScript prejudica o SEO?
A: Pode, se as páginas só forem renderizadas no navegador. Os motores executam JavaScript mas com atraso e nem sempre por completo, por isso renderizar apenas no cliente torna a indexação mais lenta e menos fiável. Renderizar no servidor ou gerar estaticamente elimina o problema. Para um site de conteúdo, a resposta mais simples é pôr o conteúdo no HTML.

Q: Quanto tempo até ver tráfego de pesquisa?
A: Num domínio novo, semanas até indexação e meses até posições relevantes — sites novos não posicionam depressa, por melhor que seja a técnica. Num relançamento de um site existente com redirecionamentos limpos, conte com duas a seis semanas de oscilação antes de estabilizar perto do nível anterior.

Q: Preciso de uma extensão de SEO?
A: Num CMS, uma extensão é uma forma prática de dar aos editores controlo sobre títulos, descrições, canónicos e mapas do site. Não é uma estratégia, e a configuração por omissão não substitui alguém que decida do que trata cada página. Num site à medida, a mesma funcionalidade costuma ser escrita diretamente e fica mais leve.

## Site à medida ou modelo: como decidir
https://websitedevelopment.biz/pt/guides/site-a-medida-ou-modelo
Atualizado a 2026-08-07 · Desenvolvimento web

A escolha entre modelo e desenvolvimento à medida é apresentada como uma questão de qualidade e é sobretudo uma questão de encaixe. Ambas as abordagens produzem sites excelentes e ambas produzem desastres.

Este guia compara-as nos pontos que importam ao fim de um ano e dá um critério de decisão prático.

### A comparação
As diferenças que se sentem na prática, não as que aparecem nos argumentos de venda.
| Custo inicial | Baixo | Alto |
| Prazo | Semanas | Meses |
| Aparência | Reconhecível, ajustável | Exatamente a sua marca |
| Desempenho | Carrega o que não usa | Só o necessário |
| Flexibilidade | Limitada ao previsto | Total |
| Manutenção | Depende do autor do modelo | Depende de si |
| Risco | O modelo ser abandonado | Quem construiu desaparecer |

### Quando o modelo é a escolha certa
Modelos são subestimados por quem vende desenvolvimento e são frequentemente a decisão mais racional.
- O orçamento é limitado e o site precisa de existir depressa.
- O tipo de site é comum: institucional, blogue, portefólio, restaurante.
- A marca não depende de uma identidade visual muito própria.
- Você quer poder alterar coisas sem contratar ninguém.
- É uma primeira versão para validar o negócio.
- Escolha um modelo bem avaliado, atualizado recentemente e com autor ativo.
- Evite modelos com dezenas de funcionalidades embutidas: carregam peso que nunca vai usar.
O critério mais importante ao escolher um modelo é a data da última atualização. Um modelo abandonado torna-se um problema de segurança.

### Quando o desenvolvimento à medida se justifica
À medida compensa quando existe uma exigência concreta que um modelo não satisfaz.
- O site é o produto, ou o principal canal de receita.
- Precisa de funcionalidade que não existe pronta.
- Tem exigências de desempenho que um modelo genérico não cumpre.
- A identidade visual é um ativo real do negócio.
- Integra sistemas internos de forma profunda.
- Prevê evolução contínua durante anos, com equipa dedicada.
- Se não conseguir apontar qual destes se aplica, provavelmente um modelo chega.

### O meio-termo, que é o que a maioria faz
A escolha raramente é binária, e as opções intermédias costumam ser as mais sensatas.
| Modelo sem alterações | Instalar e preencher | Validação rápida, orçamento mínimo |
| Modelo personalizado | Cores, tipos, algumas secções | A maioria das pequenas empresas |
| Tema base leve | Estrutura mínima, desenho próprio por cima | Bom equilíbrio custo-controlo |
| Tema próprio sobre CMS | CMS conhecido, tema construído de raiz | Empresas médias |
| Totalmente à medida | Tudo construído | Produtos e casos exigentes |
«Tema base leve com desenho próprio» é a opção que mais vezes acerta: dá aparência única sem o custo de reconstruir gestão de conteúdos.

Q: Os modelos prejudicam o SEO?
A: Não por serem modelos. Prejudicam quando são pesados, carregam scripts que não usa e são lentos — o que é comum em modelos com muitas funcionalidades embutidas. Um modelo leve e bem construído posiciona tão bem como um site à medida, porque o que conta é a velocidade, a estrutura e o conteúdo.

Q: Consigo distinguir um site feito com modelo?
A: Quem trabalha na área, às vezes; os seus clientes, quase nunca. E, mais importante, não decidem com base nisso. O que notam é se a página carrega depressa, se percebem o que você faz e se encontram o que procuram. Nenhuma dessas coisas depende da origem do desenho.

Q: Posso começar com um modelo e mudar depois?
A: Sim, e é um percurso comum e sensato. Se mantiver o conteúdo bem estruturado no CMS, substituir o tema mais tarde é um projeto contido. O que torna a mudança difícil é conteúdo embutido em construtores visuais proprietários, que não sai limpo do sistema onde foi criado.

Q: Quanto mais caro é à medida?
A: Tipicamente três a dez vezes mais do que adaptar um modelo, consoante a complexidade. A pergunta útil não é se é mais caro — é sempre — mas o que compra com essa diferença. Se a resposta for «aparência mais original», reconsidere. Se for «funcionalidade que não existe pronta», justifica-se.

## Acessibilidade web: guia prático para sites
https://websitedevelopment.biz/pt/guides/guia-de-acessibilidade-web
Atualizado a 2026-08-07 · Design web

Acessibilidade é a diferença entre um site que toda a gente consegue usar e um que exclui uma parte dos visitantes sem que ninguém se aperceba. A maioria dos requisitos é simples e barata se for tratada durante a construção.

Este guia cobre o que verificar, como testar sem ferramentas caras, e o que é obrigação legal em vez de boa prática.

### O essencial, por ordem de impacto
Cumprir estes pontos resolve a maior parte das barreiras reais, e nenhum é caro durante a construção.
- HTML semântico. Títulos, listas, botões e ligações com as etiquetas corretas — é a base de tudo.
- Navegação por teclado. Tudo o que se faz com o rato tem de ser possível com Tab e Enter.
- Indicador de foco visível. Nunca remova o contorno sem pôr algo melhor no lugar.
- Contraste suficiente. 4,5:1 para texto normal, 3:1 para texto grande.
- Texto alternativo nas imagens. Descritivo nas informativas, vazio nas decorativas.
- Rótulos nos formulários. Associados ao campo, não apenas texto de espaço reservado.
- Erros claros. Junto ao campo, a dizer o que corrigir, não só a vermelho.
- Não usar só a cor para transmitir informação.
- Legendas em vídeo, e transcrição em áudio.
HTML semântico resolve sozinho uma proporção enorme dos problemas. Um botão que é um <div> falha imediatamente em teclado e em leitores de ecrã.

### Testar sem ferramentas caras
Cinco testes que qualquer pessoa pode fazer e que apanham a maior parte dos problemas.
| Só teclado | Guardar o rato e navegar com Tab | Armadilhas de foco, elementos inacessíveis |
| Zoom a 200 % | Ampliar no navegador | Disposição que parte, texto cortado |
| Verificador automático | Extensão gratuita de acessibilidade | Contraste, rótulos, estrutura |
| Leitor de ecrã | O que já vem no sistema operativo | Se a página faz sentido em voz |
| Escala de cinzentos | Filtro do sistema | Informação transmitida só por cor |
Os verificadores automáticos apanham cerca de um terço dos problemas. O teste de teclado apanha muitos dos restantes e demora dois minutos.

### Erros frequentes
Padrões que aparecem repetidamente e que são fáceis de evitar.
- Remover o contorno de foco por razões estéticas — torna o site inutilizável com teclado.
- Usar <div> com um clique em vez de <button>, perdendo teclado e semântica.
- Texto de espaço reservado em vez de rótulo: desaparece quando se começa a escrever.
- Contraste baixo em texto secundário, muito comum em cinzentos claros.
- Imagens com texto embutido, ilegíveis para leitores de ecrã e para tradução.
- Carrosséis automáticos sem controlo de pausa.
- Modais que não devolvem o foco ao elemento que os abriu.
- Ícones sem rótulo acessível, sobretudo em menus e botões de fecho.

### Obrigação legal e âmbito
O enquadramento varia por país e por tipo de organização, mas a direção é a mesma em todo o lado.
| Setor público na União Europeia | Obrigatório, com declaração de acessibilidade |
| Serviços digitais e comércio | Cada vez mais abrangido por legislação europeia |
| Empresas fornecedoras do Estado | Frequentemente exigido em concurso |
| Norma de referência | WCAG 2.1 nível AA |
| Sites privados sem contrato público | Boa prática, com risco legal a aumentar |
| Aplicações móveis | Abrangidas pelas mesmas orientações |
Independentemente da obrigação legal, o argumento prático é simples: uma parte significativa da população tem alguma limitação, e limitações temporárias afetam toda a gente em algum momento.

Q: A acessibilidade encarece o projeto?
A: Durante a construção, pouco — a maior parte é escrever HTML correto e escolher cores com contraste suficiente. Corrigir depois de o site estar feito custa muito mais, porque implica mexer em estrutura já construída. É por isso que deve estar nos requisitos, não numa auditoria posterior.

Q: As ferramentas automáticas chegam?
A: Não. Apanham cerca de um terço dos problemas: contraste, rótulos em falta, estrutura de títulos. Não conseguem avaliar se um texto alternativo é útil, se a ordem de tabulação faz sentido, ou se a página é compreensível em voz. Combine automático com teste de teclado e com leitor de ecrã.

Q: Acessibilidade ajuda no SEO?
A: Ajuda, por sobreposição real: HTML semântico, títulos bem estruturados, texto alternativo e vídeo legendado servem ambos os objetivos. Não é uma tática de SEO, mas as duas coisas puxam na mesma direção porque ambas dependem de o conteúdo ser compreensível sem depender da apresentação visual.

Q: Preciso de conformidade total?
A: Se estiver legalmente obrigado, sim, ao nível exigido. Caso contrário, trabalhe por prioridade: corrija primeiro o que bloqueia utilização — teclado, contraste, rótulos, formulários — e trate depois os pontos mais finos. Um site com o essencial resolvido é utilizável; a conformidade formal completa é um passo seguinte.

## Estrutura e mapa de um site: como organizar as páginas
https://websitedevelopment.biz/pt/guides/estrutura-e-mapa-de-um-site
Atualizado a 2026-08-07 · Planeamento do site

A estrutura de um site determina se as pessoas encontram o que procuram e se os motores de busca conseguem perceber do que trata cada página. É também das coisas mais caras de mudar depois, porque mudar estrutura significa mudar URL.

Este guia mostra como decidir a estrutura, como validá-la antes de construir, e os padrões que funcionam.

### Comece pelas páginas, não pelo menu
O menu é uma consequência da estrutura, não a estrutura em si. Decidir o menu primeiro leva a espremer conteúdo em categorias que não servem.
- Liste todas as páginas que precisam de existir, sem se preocupar com hierarquia.
- Marque cada uma com a intenção que serve: informar, convencer, converter, apoiar.
- Agrupe por semelhança de intenção e de assunto, não por departamento interno.
- Nomeie os grupos com as palavras que os clientes usam, não com o vocabulário da empresa.
- Verifique se algum grupo tem uma só página — normalmente pertence a outro sítio.
- Só então desenhe o menu, escolhendo o que merece estar no primeiro nível.
- Confirme que qualquer página importante está a dois ou três cliques da entrada.
Organizar o site pelo organograma da empresa é o erro mais comum e o mais invisível para quem está dentro dela.

### Profundidade, largura e cliques
A regra que importa é a profundidade de cliques a partir da página principal, não quantas barras tem o URL.
| Página a 5 cliques da entrada | Poucos visitantes, pouco rastreio | Ligar a partir de páginas relevantes |
| Menu com 12 entradas de topo | Ninguém lê; decide-se pior | Agrupar em 5 a 7 |
| Categoria com 200 itens | Impossível navegar | Subcategorias ou filtros |
| Categoria com 1 item | Estrutura artificial | Fundir com outra |
| URL com 5 níveis | Praticamente irrelevante | Não reestruture só por isso |
| Página órfã sem ligações | Quase nunca rastreada | Ligar a partir de algum sítio |

### Padrões de estrutura que funcionam
A maioria dos sites cabe num destes padrões, e escolher o certo poupa reinventar.
- Institucional simples: entrada, serviços, sobre, casos, contacto, blogue. Funciona para a maioria das empresas.
- Centro e satélites: uma página forte por tema, com artigos de apoio a ligar de volta. Bom para conteúdo.
- Catálogo: categorias, subcategorias, itens. Filtros para o resto.
- Por serviço e por setor: duas entradas para o mesmo conteúdo, útil em B2B — com cuidado para não duplicar.
- Por localização: uma página por cidade ou região, com conteúdo genuinamente diferente em cada.
- Evite: uma página por palavra-chave sem conteúdo distinto. É a forma mais rápida de encher o site de páginas fracas.

### Validar antes de construir
A estrutura é barata de testar em papel e cara de corrigir depois do lançamento.
- Peça a cinco pessoas fora da empresa para dizer onde procurariam três coisas concretas.
- Dê-lhes a lista de páginas e peça que a agrupem — vai descobrir nomes melhores do que os seus.
- Verifique se cada página tem um objetivo claro; se não tiver, provavelmente não devia existir.
- Confirme que a ação principal está acessível a partir de qualquer página.
- Verifique quais páginas do site atual têm tráfego, e garanta que têm destino no novo.
- Só depois desenhe. Estrutura primeiro, ecrãs depois.
O teste de agrupamento com cinco pessoas demora uma hora e é a hora com melhor retorno em todo o projeto.

Q: Quantos níveis deve ter um site?
A: Dois a três chegam para a maioria dos sites. O critério não é o número de níveis mas a distância em cliques: qualquer página importante deve estar a dois ou três cliques da entrada, e páginas mais fundas precisam de ligações a partir de sítios relevantes para serem encontradas e rastreadas.

Q: O mapa do site XML é o mesmo que a estrutura?
A: Não. O mapa XML é um ficheiro que lista os URL para os motores de busca; a estrutura é a organização lógica das páginas e das ligações entre elas. O ficheiro ajuda a descoberta, mas não substitui ligações internas — uma página que só existe no mapa XML e mais em lado nenhum é praticamente ignorada.

Q: Devo criar uma página por cidade onde atuo?
A: Só se cada página tiver conteúdo genuinamente diferente: equipa local, casos locais, informação útil daquela zona. Cinquenta páginas iguais com o nome da cidade trocado são páginas fracas que não posicionam e diluem o site. Duas ou três páginas bem feitas superam cinquenta geradas.

Q: Como decido o que vai no menu principal?
A: O que serve o maior número de visitantes, não o que a empresa considera mais importante. «Sobre nós» costuma ocupar espaço nobre com pouco tráfego, enquanto páginas de serviço com muito tráfego ficam escondidas. Olhe para os dados do site atual e ordene por utilidade real, não por hierarquia interna.

## Processo de desenvolvimento de um site, fase a fase
https://websitedevelopment.biz/pt/guides/processo-de-desenvolvimento-de-um-site
Atualizado a 2026-08-07 · Desenvolvimento web

Um projeto de site tem uma sequência que funciona, e a maior parte dos problemas vem de fases saltadas ou de responsabilidades que ninguém assumiu.

Este guia percorre o processo completo, com o que cada fase entrega, quanto demora, e o que se espera de si em cada momento.

### As fases e as entregas
Prazos indicativos para um site institucional com CMS. Projetos maiores escalam, mas a sequência mantém-se.
| Descoberta | Objetivos, âmbito, estrutura | 1 semana | Decisões e acesso a informação |
| Desenho | Modelos aprovados | 2 a 4 semanas | Feedback consolidado, sem contradições |
| Construção | Site funcional em testes | 3 a 6 semanas | Disponibilidade para dúvidas |
| Conteúdo | Textos e imagens introduzidos | Em paralelo | Entrega dos textos — o ponto crítico |
| Testes | Lista de correções fechada | 1 semana | Revisão sua com feedback concreto |
| Lançamento | Site no ar | 1 a 2 dias | Acessos e decisão de data |
| Acompanhamento | Correções e ajustes | 30 dias | Reportar o que encontrar |
A coluna da direita é a que mais determina o prazo real. Projetos atrasam do lado do cliente mais vezes do que do lado de quem constrói.

### O que corre mal em cada fase
Os problemas são previsíveis, o que significa que são evitáveis.
- Descoberta: ninguém decide quem é o responsável, e cada reunião reabre discussões fechadas.
- Desenho: feedback contraditório de várias pessoas sem hierarquia entre elas.
- Construção: pedidos novos entram sem ajustar prazo nem orçamento.
- Conteúdo: os textos não chegam, e todo o resto fica à espera.
- Testes: feedback vago do tipo «não está bem» em vez de URL e captura de ecrã.
- Lançamento: acessos a domínio ou alojamento que ninguém sabe onde estão.
- Acompanhamento: confusão entre correção de erro e pedido novo.

### Dar feedback útil
A qualidade do feedback afeta o prazo tanto como a velocidade de quem constrói.
- Consolide o feedback de todos numa lista única antes de enviar.
- Indique sempre o URL exato e o dispositivo onde viu o problema.
- Junte captura de ecrã; poupa uma troca de mensagens em cada ponto.
- Separe erro de preferência: «o formulário não envia» e «prefiro este azul» são coisas diferentes.
- Priorize: bloqueante, importante, cosmético.
- Evite reabrir decisões já aprovadas sem assumir que é uma alteração de âmbito.
- Responda dentro do prazo combinado; feedback atrasado empurra tudo o resto.
Uma lista consolidada e priorizada pode poupar uma semana de calendário num projeto de três meses.

### Depois do lançamento
A fase mais esquecida no planeamento e a que dura mais tempo.
| Primeiros dias | Erros 404, formulários, verificações finais |
| Primeiras semanas | Correções de garantia, ajustes pequenos |
| Primeiro mês | Oscilação de tráfego a estabilizar |
| Primeiros três meses | Primeiros dados úteis para decidir melhorias |
| Contínuo | Manutenção, conteúdo novo, monitorização |
| Anual | Revisão de conteúdo e de desempenho |
Combine a manutenção antes do lançamento, não depois. Negociar acompanhamento com o site já no ar e uma avaria em curso é a pior altura possível.

Q: Quanto tempo demora um site do início ao fim?
A: Seis a dez semanas para um site institucional com CMS, se os textos chegarem a tempo. Três a seis meses com desenho à medida, migração ou integrações. Loja online e aplicações escalam a partir daí. A variável que mais frequentemente determina a data real é a entrega de conteúdo.

Q: Posso acelerar o processo?
A: Sim, e sobretudo do seu lado: tenha os textos prontos antes de a construção começar, nomeie um único decisor, e responda a feedback dentro do prazo. Do lado técnico, reduzir âmbito acelera; acrescentar pessoas a meio raramente acelera e frequentemente atrasa.

Q: O que acontece se eu não gostar do resultado?
A: Se seguiu o processo, isso não devia surgir no fim — a direção visual foi aprovada cedo e viu o progresso a cada duas semanas. Quando acontece, é quase sempre porque alguém saltou a aprovação da direção visual ou porque um decisor só apareceu no fim. Esse é o argumento prático para as fases existirem.

Q: Devo pagar por fases?
A: Sim, ligado a entregas visíveis: adiantamento, desenho aprovado, construção entregue, site no ar. Isto alinha incentivos e dá-lhe pontos de controlo naturais. Evite ligar pagamentos a datas de calendário, porque as datas movem-se por razões de ambos os lados e os pagamentos deixam de refletir progresso.

## Design responsivo: guia prático
https://websitedevelopment.biz/pt/guides/guia-de-design-responsivo
Atualizado a 2026-08-07 · Design web

Design responsivo deixou de ser uma técnica especial para ser o modo normal de construir. O que continua a distinguir bons resultados é a ordem de trabalho e o teste em dispositivos reais.

Este guia cobre a abordagem, as decisões técnicas e os problemas que só se veem num telemóvel a sério.

### Móvel primeiro, e porquê
Desenhar primeiro para o ecrã pequeno não é uma preferência estética: é uma restrição que produz decisões melhores.
- Cabe menos, por isso é obrigatório decidir o que é essencial.
- O que sobreviver ao ecrã pequeno é o que realmente importa na página.
- Acrescentar espaço para ecrãs maiores é fácil; retirar conteúdo é doloroso.
- A maior parte do tráfego chega de telemóvel na maioria dos setores — verifique a sua análise.
- O desempenho fica melhor por consequência, porque se carrega menos por omissão.
- A navegação simplificada em móvel costuma revelar-se melhor também em desktop.
O padrão inverso — desenhar em desktop e «adaptar» no fim — produz o móvel improvisado que se reconhece imediatamente.

### Pontos de rutura e disposição
Os pontos de rutura devem seguir o conteúdo, não modelos de dispositivos que mudam todos os anos.
| Onde colocar pontos de rutura | Onde a disposição parte, não em larguras de dispositivos |
| Quantos | Três a quatro chegam para a maioria dos sites |
| Sistema de grelha | CSS Grid para a página, flexbox para componentes |
| Larguras | Relativas com máximo, não valores fixos |
| Tipografia | Fluida com clamp entre um mínimo e um máximo |
| Espaçamento | Escala consistente, não valores avulsos |
| Contentores | Largura máxima para o texto não esticar em ecrãs largos |

### Os elementos que costumam partir
Estes são responsáveis pela maioria dos problemas visuais em ecrãs pequenos.
- Tabelas. Não encolhem. Ou fazem scroll horizontal no seu contentor, ou viram cartões.
- Imagens. Precisam de srcset e sizes para que o telemóvel não descarregue a versão de desktop.
- Títulos longos. Teste com o título mais comprido que existirá, não com o do exemplo.
- Formulários. Campos a toda a largura, teclado correto por tipo de campo, rótulos visíveis.
- Navegação. O menu compactado tem de fechar-se e ser navegável por teclado.
- Modais e sobreposições. Devem caber no ecrã e permitir scroll interno.
- Elementos fixos. Uma barra fixa num ecrã baixo pode ocupar metade da área útil.
- Vídeos e mapas incorporados. Precisam de contentor com proporção definida.

### Testar como deve ser
O simulador do navegador apanha problemas de disposição e esconde tudo o resto.
- Teste em telemóveis reais, incluindo um aparelho antigo e lento.
- Teste com ligação limitada, não com a rede do escritório.
- Teste em modo horizontal — é onde as barras fixas costumam falhar.
- Teste com o texto aumentado nas definições do sistema.
- Teste o toque com o polegar, não com o rato num ecrã simulado.
- Verifique se algo provoca scroll horizontal; é o defeito mais visível que existe.
- Verifique os alvos de toque: 44 px mínimos, com espaço entre eles.
O scroll horizontal é o defeito que os visitantes notam de imediato e que os simuladores escondem com facilidade.

Q: Quantos pontos de rutura preciso?
A: Três a quatro chegam para a maioria dos sites. O critério é onde a disposição deixa de funcionar, não a largura de um telemóvel específico. Larguras de dispositivos mudam todos os anos; o conteúdo, não. Redimensione a janela lentamente e coloque um ponto de rutura onde algo começar a ficar mau.

Q: Devo ter um site móvel separado?
A: Não. Sites móveis separados exigem manutenção dupla, dividem sinais de pesquisa e são uma abordagem praticamente abandonada. Um site responsivo serve todos os ecrãs a partir dos mesmos URL, que é também o que os motores de busca esperam encontrar hoje.

Q: Como trato tabelas em ecrãs pequenos?
A: Duas opções funcionam: scroll horizontal dentro do próprio contentor da tabela, que preserva a comparação entre colunas, ou transformar cada linha num cartão empilhado. A escolha depende de se as pessoas precisam de comparar valores entre colunas. O que nunca funciona é deixar a tabela empurrar a página para o lado.

Q: Design responsivo torna o site mais lento?
A: Não por si. Torna se enviar as imagens de desktop para telemóveis, o que acontece quando falta srcset. Com imagens servidas no tamanho certo e CSS bem organizado, um site responsivo é mais leve em móvel do que uma versão separada mal mantida.

## Documento de requisitos de um site: o que escrever
https://websitedevelopment.biz/pt/guides/documento-de-requisitos-de-um-site
Atualizado a 2026-08-07 · Planeamento do site

Um documento de requisitos existe para uma coisa: garantir que você e quem constrói o site estão a falar do mesmo projeto. Não precisa de ser longo. Precisa de ser específico nos sítios certos.

Este guia mostra o que incluir, o que deixar de fora, e as secções que evitam as discussões mais frequentes.

### As secções que não podem faltar
Cada uma destas existe porque a sua ausência causa um problema previsível.
- Contexto e objetivos. O que faz a empresa e o que o site tem de conseguir, em números.
- Público. Quem visita e com que dúvida.
- Lista de páginas. Todas, agrupadas por modelo, com indicação de quais são novas.
- Funcionalidades. Formulários, pesquisa, filtros, área reservada, o que for.
- Integrações. Cada sistema externo, com quem é responsável por dar acesso.
- Conteúdo. Quem escreve, quem fotografa, quem introduz, e até quando.
- Requisitos técnicos. Idiomas, acessibilidade, desempenho, navegadores suportados.
- Fora do âmbito. A secção mais importante do documento.
- Prazos e responsáveis. Quem decide, e o que acontece se algo atrasar.
A secção «fora do âmbito» evita mais discussões do que todas as outras juntas. Escreva-a mesmo que pareça óbvia.

### Como escrever requisitos que se conseguem verificar
Um requisito vago não é verificável, e o que não é verificável discute-se no fim do projeto.
| O site tem de ser rápido | LCP abaixo de 2,5 s nas páginas principais em 4G |
| Tem de funcionar em telemóvel | Utilizável a partir de 360 px, testado em dispositivos reais |
| Tem de ser acessível | Conforme WCAG 2.1 nível AA nos modelos principais |
| Fácil de gerir | A equipa cria e publica uma página sem programador |
| Desenho moderno | Segue o manual de marca; três propostas iniciais |
| Otimizado para SEO | Títulos editáveis, mapa do site, dados estruturados, redirecionamentos |
| Suporta vários idiomas | PT e EN no lançamento; estrutura para acrescentar mais |

### O que deixar de fora
Documentos demasiado detalhados custam tempo a escrever, tempo a ler, e retiram a quem constrói a possibilidade de propor melhor.
- Não especifique tecnologias sem razão. Diga o problema; deixe a solução para a proposta.
- Não escreva o texto de cada botão. Isso resolve-se com ecrãs à frente.
- Não desenhe o site em palavras. Referências visuais funcionam melhor do que descrições.
- Não inclua funcionalidades «para o futuro» sem as marcar claramente como fase dois.
- Não copie requisitos de outro documento sem verificar se se aplicam.
- Não peça o que não vai usar. Cada funcionalidade tem custo de construção e de manutenção.
Se o documento passa das dez páginas para um site institucional, provavelmente está a especificar a solução em vez do problema.

### Usar o documento durante o projeto
O documento não é para arquivar depois de assinado. É a referência que resolve discussões.
- Envie o mesmo documento a todos os candidatos, para obter propostas comparáveis.
- Anexe-o ao contrato, para que o âmbito acordado seja o âmbito escrito.
- Quando alguém pedir algo novo, verifique se está no documento antes de discutir prazo.
- Registe as alterações de âmbito por escrito, com estimativa, antes de o trabalho começar.
- Use a lista de páginas como lista de verificação de conteúdo durante a construção.
- Na entrega, percorra os requisitos verificáveis um a um.

Q: Que extensão deve ter o documento?
A: Para um site institucional, cinco a dez páginas chegam. Para um projeto grande com integrações, vinte a trinta. Se estiver a passar muito disso, é provável que esteja a especificar a solução em vez do problema — e documentos assim tendem a ser ignorados por todos, incluindo por quem os escreveu.

Q: Devo dizer qual é o orçamento?
A: Sim. Quem constrói pode então propor o melhor projeto possível dentro desse valor, em vez de adivinhar. Quem não indica orçamento recebe propostas que variam por um fator de dez e não consegue compará-las. Indicar um intervalo é suficiente; não é preciso revelar o limite exato.

Q: Quem deve escrever o documento?
A: Alguém do lado do cliente que conheça o negócio, idealmente com apoio de quem percebe de web. Se pedir a uma agência que o escreva, é normal que descreva o projeto que essa agência gosta de fazer — o que pode até ser bom, mas deixa de servir para comparar propostas. Se o fizer assim, pague essa fase à parte.

Q: E se os requisitos mudarem a meio?
A: Mudam quase sempre, e o documento não impede isso — organiza-o. Tenha um procedimento de alteração: cada pedido novo recebe uma estimativa escrita antes de começar. O problema não são as alterações, é as alterações entrarem sem que ninguém ajuste prazo nem orçamento.

## Como funciona o desenvolvimento web na prática
https://websitedevelopment.biz/pt/guides/como-funciona-o-desenvolvimento-web
Atualizado a 2026-08-07 · Desenvolvimento web

Do lado de fora, o desenvolvimento parece uma caixa negra: aprova-se o desenho, espera-se algumas semanas, aparece um site. Perceber o que acontece lá dentro ajuda a fazer as perguntas certas e a reconhecer sinais de problema cedo.

Este guia explica o funcionamento prático, para quem contrata em vez de para quem programa.

### Ambientes: onde o trabalho acontece
Um projeto sério tem pelo menos dois ambientes, e frequentemente três. Se só houver um, isso por si é um sinal.
| Local | A máquina de quem programa | A equipa |
| Testes | Versão partilhada para rever | Equipa e cliente |
| Pré-produção | Cópia igual à de produção | Equipa, antes de publicar |
| Produção | O site público | Toda a gente |
Alterações feitas diretamente em produção são a origem mais comum de avarias inesperadas. Se lhe disserem que não há ambiente de testes, pergunte porquê.

### O ciclo de trabalho
A maioria das equipas trabalha em ciclos curtos, com algo revisível no fim de cada um.
- O trabalho é dividido em tarefas pequenas, cada uma com um resultado verificável.
- Cada tarefa é desenvolvida separadamente, com controlo de versões.
- Outra pessoa revê o código antes de ser integrado, quando a equipa tem dimensão para isso.
- O resultado vai para o ambiente de testes, onde pode ser visto.
- Você revê e dá feedback concreto, com URL e captura de ecrã.
- Correções entram no ciclo seguinte, salvo se forem bloqueantes.
- A cada uma ou duas semanas há uma versão para rever, não apenas no fim.
Um projeto em que só vê o resultado no fim é um projeto de risco. Peça acesso ao ambiente de testes desde a primeira semana.

### Testes antes de publicar
O que deve estar verificado antes de qualquer publicação, independentemente da dimensão do projeto.
- Funcionalidade: cada formulário, cada percurso, cada botão que faz alguma coisa.
- Navegadores: os que os seus visitantes usam realmente, segundo a análise.
- Dispositivos: telemóveis reais, incluindo um antigo e lento.
- Desempenho: medido, não estimado, nos modelos principais.
- Acessibilidade: teclado, contraste, rótulos, estrutura de títulos.
- Conteúdo: sem texto de exemplo, sem ligações para o domínio de testes.
- Regressão: o que já funcionava continua a funcionar.
- Segurança: validação de entradas, permissões, HTTPS.

### Publicação e reversão
Publicar deve ser rotineiro e aborrecido. Quando é um acontecimento tenso, é sinal de que o processo está frágil.
| Publicação automatizada | Elimina passos manuais esquecidos |
| Reversão em minutos | Transforma um erro grave num incidente pequeno |
| Cópia de segurança antes de publicar | Rede de segurança para a base de dados |
| Migrações de dados versionadas | Alterações à base de dados reproduzíveis |
| Verificação depois de publicar | Apanha o que só falha em produção |
| Publicar em momento calmo | Menos utilizadores afetados, mais atenção disponível |
| Registo do que foi publicado | Permite relacionar problemas com alterações |
Pergunte quanto tempo demora reverter. Se a resposta for «depende» ou «nunca precisámos», o plano de reversão não existe.

Q: Com que frequência devo ver o progresso?
A: De uma a duas semanas, com algo visível no ambiente de testes. Ciclos mais longos aumentam o risco de descobrir tarde que houve um mal-entendido. Ciclos muito curtos com feedback constante também têm custo, porque interromper trabalho a meio é ineficiente. Uma cadência quinzenal funciona bem para a maioria dos projetos.

Q: O que faço se o projeto atrasar?
A: Primeiro perceba a causa: conteúdo em falta, âmbito que cresceu, ou estimativa otimista. As três resolvem-se de maneiras diferentes, e a primeira é frequentemente do lado do cliente. Depois decida entre cortar âmbito ou mover a data — acrescentar pessoas a meio de um projeto atrasado costuma atrasá-lo ainda mais.

Q: Preciso de perceber de código para gerir isto?
A: Não. Precisa de saber que perguntas fazer: há ambiente de testes, como se publica, quanto demora reverter, o que está testado, quem tem acesso ao código. As respostas dizem-lhe muito sobre a solidez do processo sem que precise de ler uma linha.

Q: O que é controlo de versões e porque importa?
A: É o sistema — quase sempre Git — que guarda o histórico de todas as alterações ao código e permite voltar atrás. Importa por três razões: permite reverter um erro, permite várias pessoas trabalharem em paralelo, e é a prova de que o código é seu e transferível. Um projeto sem controlo de versões é um projeto sem histórico.

## Princípios de design de sites que funcionam
https://websitedevelopment.biz/pt/guides/principios-de-design-de-sites
Atualizado a 2026-08-07 · Design web

Muito do que se diz sobre design de sites é preferência apresentada como princípio. Há, no entanto, um pequeno conjunto de regras que aguenta o teste da prática e que se nota quando falta.

Este guia percorre essas regras, com o que cada uma resolve e como verificar se está a ser cumprida.

### Hierarquia: dizer o que é mais importante
A hierarquia é o princípio que mais afeta se as pessoas percebem a página, e o mais fácil de verificar.
- Uma coisa é a mais importante em cada ecrã. Se houver três, o visitante não escolhe nenhuma.
- O tamanho, o peso e o espaço à volta comunicam importância melhor do que a cor.
- A ação principal deve destacar-se visualmente de tudo o resto na página.
- Agrupe o que está relacionado com proximidade; a distância comunica separação.
- Não use mais de dois ou três níveis de título. Mais níveis deixam de ser lidos como hierarquia.
- Teste franzindo os olhos: o que continua legível é o que as pessoas veem primeiro.
O teste dos olhos semicerrados demora cinco segundos e apanha a maioria dos problemas de hierarquia.

### Espaço, contraste e legibilidade
Três coisas mensuráveis que separam páginas confortáveis de páginas cansativas.
| Comprimento de linha | 60 a 80 caracteres | Linhas a toda a largura do ecrã |
| Tamanho do corpo | 16 px ou mais em móvel | 14 px «para caber mais» |
| Entrelinha | 1,5 no corpo de texto | Entrelinha apertada, texto denso |
| Contraste de texto | Pelo menos 4,5:1 | Cinzento claro sobre branco |
| Espaço entre secções | Generoso e consistente | Tudo colado, sem respiração |
| Alvos de toque | Mínimo 44 px | Ligações pequenas em móvel |
| Número de tipos de letra | Um ou dois | Quatro tipos numa página |

### Consistência e clareza
A consistência é o que permite às pessoas aprenderem o site uma vez em vez de o reaprenderem em cada página.
- O mesmo elemento comporta-se sempre da mesma maneira em todo o site.
- Botões de igual importância têm sempre o mesmo aspeto.
- As ligações são identificáveis como ligações sem ser preciso passar o rato por cima.
- Os rótulos dizem o que acontece: «Pedir orçamento» em vez de «Enviar».
- Escreva em linguagem de cliente, não em linguagem interna.
- Erros de formulário aparecem junto ao campo e dizem como corrigir.
- Elementos que não são clicáveis não devem parecer clicáveis.
A regra dos rótulos é a que dá mais retorno: mudar «Enviar» para «Pedir orçamento» aumenta conversões sem alterar mais nada.

### O que é gosto e não princípio
Regras repetidas que não resistem aos dados e que custam tempo a discutir.
| Tudo tem de estar acima da dobra | As pessoas fazem scroll; a clareza importa mais |
| Menos cliques é sempre melhor | Cliques certos batem cliques poucos |
| O carrossel na entrada é obrigatório | Costuma ter interação muito baixa |
| Minimalismo é sempre melhor | Contexto insuficiente prejudica a decisão |
| Nunca abrir ligações em nova janela | Depende do contexto; documentos são exceção |
| O vermelho é agressivo | Depende inteiramente do setor e da cultura |
| A página tem de ser original | A familiaridade ajuda a usar o site |
Padrões familiares não são falta de criatividade: são o motivo pelo qual as pessoas sabem usar um site que nunca viram.

Q: Um site bonito converte mais?
A: Um site claro converte mais; a beleza ajuda pela credibilidade que transmite nos primeiros segundos. Onde a estética falha é quando compete com a compreensão — animações que atrasam, contrastes baixos em nome da elegância, rótulos criativos que ninguém percebe. Clareza primeiro, estética a servir a clareza.

Q: Quantas cores devo usar?
A: Uma cor de marca, uma cor de destaque para ações, e uma escala de cinzentos. Depois disso, cada cor extra precisa de justificação funcional — estados de erro, de sucesso, de aviso. Paletas grandes tornam difícil destacar o que importa, porque tudo compete com tudo.

Q: Devo seguir tendências de design?
A: Com moderação. Tendências datam o site e obrigam a redesenhos por razões estéticas em vez de funcionais. O que envelhece bem é tipografia clara, espaço generoso e hierarquia sólida — princípios com décadas. Adote tendências onde são baratas de reverter e evite-as na estrutura.

Q: Como sei se o meu design está a funcionar?
A: Olhe para o comportamento: as pessoas chegam à ação principal, ou abandonam? Onde param nos formulários? Gravações de sessão e análise de formulários mostram isto em minutos. A opinião interna sobre estética é o pior indicador disponível, porque a equipa vê o site todos os dias e os visitantes uma vez.

## Quanto custa um site? Uma resposta honesta
https://websitedevelopment.biz/pt/guides/quanto-custa-um-site
Atualizado a 2026-08-07 · Planeamento do site

A resposta honesta é que depende — mas depende de coisas concretas que se podem enumerar, e é isso que torna a pergunta respondível.

Este guia dá ordens de grandeza reais, explica o que move o preço, enumera os custos recorrentes que raramente aparecem nas propostas, e mostra como comparar orçamentos que parecem incomparáveis.

### Ordens de grandeza por tipo de projeto
Valores indicativos para o mercado europeu. Variam com o país e com quem faz o trabalho, mas as proporções entre categorias mantêm-se.
| Página única | Centenas de euros | Modelo adaptado, conteúdo fornecido |
| Site institucional simples | Baixos milhares | 5 a 10 páginas, desenho sobre modelo |
| Site com CMS e blogue | Milhares | Desenho próprio, gestão de conteúdos |
| Loja online | Milhares a dezenas de milhares | Catálogo, pagamentos, envios, IVA |
| Site à medida | Dezenas de milhares | Desenho e desenvolvimento próprios |
| Aplicação web | Muito acima | Autenticação, lógica de negócio, dados |
Se receber um orçamento muito abaixo destas ordens de grandeza, não conclua que é uma pechincha — leia o que está fora do âmbito. Normalmente é conteúdo, testes ou manutenção.

### O que move realmente o preço
O número de páginas é a variável que menos importa e a que toda a gente pergunta primeiro.
- Número de modelos únicos. Cinquenta páginas em quatro modelos é um projeto pequeno.
- Desenho à medida ou tema adaptado. Esta é a maior variável isolada.
- Integrações. Cada sistema externo é um projeto pequeno dentro do projeto.
- Conteúdo. Quem escreve, quem fotografa, quem introduz no sistema.
- Migração. Conteúdo antigo, URL antigos, redirecionamentos.
- Idiomas. Cada idioma acrescenta tradução, revisão e manutenção contínua.
- Requisitos de acessibilidade e desempenho, quando são exigências formais.
- Quem faz o trabalho. Um freelancer, uma agência local e uma agência internacional têm estruturas de custo diferentes.

### Custos recorrentes que ninguém orçamenta
O preço de construção é uma parcela. Estes custos continuam durante toda a vida do site e são a origem das surpresas.
| Domínio | Anual | Baixo, mas esquecer custa o site |
| Alojamento | Mensal ou anual | Varia muito com o tipo de site |
| Certificado | Anual | Normalmente gratuito e automático |
| Manutenção | Mensal | Atualizações, cópias, segurança, testes |
| Licenças de extensões | Anual | Somam mais do que parece |
| Conteúdo novo | Contínuo | Um site que não cresce perde posições |
| Pequenas alterações | Conforme necessário | Combine um valor à hora antes de precisar |
Uma regra prática útil: reserve um a dois por cento do custo de construção por mês para manutenção. Muito abaixo disso, pergunte o que está incluído.

### Como comparar propostas
Três orçamentos com valores muito diferentes normalmente descrevem três projetos diferentes. O objetivo é descobrir qual.
- Peça os três com base no mesmo documento escrito. Sem isso, não há comparação possível.
- Compare o que está fora do âmbito, não o que está dentro. É aí que estão as diferenças.
- Verifique quem escreve os textos em cada proposta.
- Verifique se a migração e os redirecionamentos estão incluídos.
- Verifique o que acontece depois do lançamento: garantia, correções, manutenção.
- Verifique a propriedade: código, desenho, domínio, alojamento, contas.
- Pergunte quem faz efetivamente o trabalho e quantos projetos tem em paralelo.
Uma proposta que enumera explicitamente o que não inclui vale mais do que uma mais barata sem âmbito definido.

Q: Porque é que os orçamentos variam tanto?
A: Porque descrevem trabalhos diferentes com o mesmo nome. Um inclui desenho à medida, textos, migração e três meses de acompanhamento; outro inclui um tema instalado com o conteúdo que você fornecer. Ambos são «um site». A diferença de preço reflete diferença de âmbito muito mais vezes do que diferença de margem.

Q: Vale a pena um site barato?
A: Para validar uma ideia ou ter presença mínima, sim, e não há vergonha nisso. O risco é quando o negócio depende do site: um site barato costuma ser lento, difícil de alterar e sem manutenção, e a reconstrução acaba por custar mais do que ter feito bem à primeira. Decida pelo peso que o site tem no negócio.

Q: Devo pagar tudo adiantado?
A: Não. Um adiantamento de um quarto a um terço é habitual e razoável. O resto deve estar ligado a entregas visíveis — desenho aprovado, construção entregue, site no ar. Pagar a totalidade adiantado remove qualquer incentivo para terminar, e é o padrão mais comum nos projetos que ficam a meio.

Q: Quanto custa manter um site?
A: Entre pouco e algumas centenas de euros por mês, consoante o que inclui. Alojamento e domínio são a base. Manutenção a sério — atualizações, cópias de segurança testadas, monitorização, pequenas alterações — custa mais e vale mais. Peça sempre a lista do que está incluído; «manutenção» sem discriminação costuma significar apenas correr atualizações.

## O que é desenvolvimento web
https://websitedevelopment.biz/pt/guides/o-que-e-desenvolvimento-web
Atualizado a 2026-08-07 · Desenvolvimento web

Desenvolvimento web é o trabalho de transformar um desenho e um conjunto de requisitos em algo que funciona num navegador. Envolve mais camadas do que parece de fora, e perceber quais são ajuda a falar com quem constrói.

Este guia explica as partes, quem trata de cada uma, e o que distingue um site que funciona de um site que se consegue manter.

### As camadas de um site
Todo o site tem estas camadas, mesmo os mais simples — a diferença está em quanto de cada uma existe.
| Front-end | O que o visitante vê e com que interage | HTML, CSS, JavaScript |
| Back-end | Lógica no servidor, regras de negócio | PHP, Python, Node, Java |
| Base de dados | Guarda conteúdo, utilizadores, encomendas | MySQL, PostgreSQL |
| Alojamento | O servidor onde tudo corre | Partilhado, VPS, nuvem |
| Domínio e DNS | O endereço e como se resolve | Registrar, servidores de nomes |
| Serviços externos | Pagamentos, e-mail, análise, mapas | APIs de terceiros |
Um site estático pode não ter back-end nem base de dados. É por isso que é mais rápido, mais seguro e mais barato de manter.

### Quem faz o quê
Os papéis sobrepõem-se, e em projetos pequenos a mesma pessoa faz vários.
- Front-end: transforma o desenho em interface, trata de responsividade, acessibilidade e desempenho no navegador.
- Back-end: escreve a lógica do servidor, modela os dados, integra sistemas externos.
- Full-stack: faz ambos, com maior ou menor profundidade em cada.
- DevOps: trata de servidores, publicação, monitorização e cópias de segurança.
- Designer: define aparência e comportamento antes de existir código.
- Gestor de projeto: coordena, protege prazos e traduz entre cliente e equipa.
- Num projeto pequeno, uma ou duas pessoas cobrem tudo isto. Pergunte quem faz o quê antes de assinar.

### Como as partes comunicam
Perceber o percurso de um pedido explica a maior parte das decisões técnicas que lhe vão apresentar.
- O visitante escreve o endereço; o DNS traduz o domínio num endereço de servidor.
- O navegador pede a página ao servidor por HTTPS.
- O servidor responde com HTML — pronto a apresentar, ou gerado no momento a partir da base de dados.
- O navegador lê o HTML e pede os ficheiros associados: estilos, imagens, scripts.
- O JavaScript executa e acrescenta comportamento — menus, formulários, conteúdo dinâmico.
- Ações do utilizador podem gerar novos pedidos ao servidor em segundo plano.
- O servidor grava ou lê da base de dados e devolve o resultado.
Se o HTML já vem pronto do servidor, a página aparece mais depressa e é indexada de forma mais fiável. Se só existe depois de o JavaScript correr, ambas as coisas pioram.

### O que distingue construção sólida
Dois sites podem parecer iguais e ser muito diferentes de manter. Estes são os sinais.
| Estrutura do código | Organizada, com convenções | Tudo num ficheiro gigante |
| Controlo de versões | Git, com histórico legível | Ficheiros copiados com data no nome |
| Ambiente de testes | Existe e é usado | Alterações direto em produção |
| Publicação | Automatizada e reversível | FTP manual |
| Dependências | Poucas e atualizadas | Muitas e desatualizadas |
| Documentação | Como instalar e publicar | Só na cabeça de uma pessoa |
| Testes | Pelo menos nos percursos críticos | Nenhum |

Q: Qual é a diferença entre web design e desenvolvimento web?
A: Design decide o aspeto e o comportamento; desenvolvimento constrói o que funciona. Há sobreposição — um front-end toma decisões visuais todos os dias e um designer que perceba de limitações técnicas produz desenhos melhores. Em projetos pequenos, a mesma pessoa faz frequentemente ambos.

Q: Preciso de back-end?
A: Só se o site precisar de guardar ou processar dados: contas de utilizador, encomendas, conteúdo editável, formulários com lógica. Um site institucional com conteúdo fixo pode ser inteiramente estático, o que o torna mais rápido, mais seguro e quase sem manutenção.

Q: Quanto tempo demora desenvolver um site?
A: Duas a quatro semanas para um site institucional simples depois do desenho aprovado; dois a três meses com CMS, integrações e migração; mais para lojas e aplicações. O que determina o prazo é o número de modelos e integrações, não o número de páginas — e, na prática, muitas vezes é o conteúdo.

Q: Posso fazer um site sem saber programar?
A: Sim, com construtores visuais ou com um CMS e um tema. Funciona bem para sites institucionais e blogues. Os limites aparecem quando precisa de algo que a ferramenta não prevê, quando o desempenho importa muito, ou quando quer sair da plataforma — nessa altura, o que parecia poupança revela-se dependência.

## Processo de web design: das ideias aos ecrãs finais
https://websitedevelopment.biz/pt/guides/processo-de-web-design
Atualizado a 2026-08-07 · Design web

Um bom processo de web design não é burocracia: é a ordem que evita refazer trabalho. Cada fase produz uma decisão que a fase seguinte assume como resolvida.

Este guia percorre as fases, o que cada uma entrega, quanto tempo demora, e os pontos em que os projetos de desenho costumam travar.

### As fases e o que cada uma entrega
A ordem importa. Saltar uma fase não a elimina — apenas empurra a decisão para mais tarde, quando já custa mais mudar.
| Descoberta | Objetivos, público, restrições | 3 a 5 dias |
| Estrutura | Lista de páginas e navegação | 3 a 5 dias |
| Esquemas | Disposição sem estilo visual | 1 a 2 semanas |
| Direção visual | Tipografia, cor, tom — numa página | 3 a 5 dias |
| Ecrãs finais | Modelos aplicados, desktop e móvel | 2 a 4 semanas |
| Protótipo | Percursos clicáveis para teste | 2 a 4 dias |
| Entrega | Sistema, exportações, especificações | 3 a 5 dias |
A direção visual numa única página é a fase que mais poupa tempo. Aprovar o tom antes de aplicar a trinta ecrãs evita refazer trinta ecrãs.

### Esquemas antes de estilo
Esquemas sem cor nem tipografia forçam a discussão sobre conteúdo e hierarquia, que é a discussão que importa.
- Desenhe primeiro o móvel. Cabe menos, por isso obriga a decidir prioridades.
- Use conteúdo real, ou o mais próximo possível. Texto de exemplo esconde problemas de espaço.
- Mostre os estados vazios, de erro e de carregamento — costumam ser esquecidos e depois improvisados.
- Marque o que é a ação principal em cada ecrã. Se houver três, não há nenhuma.
- Não discuta cores nesta fase. Se surgir, é sinal de que os esquemas estão detalhados demais.
- Valide a estrutura de conteúdo com quem o vai escrever, antes de avançar.

### Onde o processo costuma travar
Os bloqueios são quase sempre os mesmos, e quase todos são organizacionais e não criativos.
| Feedback contraditório | Vários decisores sem hierarquia | Um responsável único pela decisão |
| Rondas infinitas | Rondas não definidas no contrato | Número fixo, com critério de aprovação |
| Conteúdo em falta | Ninguém foi nomeado | Nome próprio e data por página |
| «Não é o que imaginei» | Direção visual saltada | Aprovar tom numa página primeiro |
| Ecrãs impossíveis de construir | Desenho sem contacto com quem constrói | Rever cedo com o programador |
| Móvel improvisado no fim | Desenhado só para desktop | Desenhar móvel primeiro |
«Rondas infinitas» é quase sempre um problema de contrato, não de desenho. Defina o que é uma ronda e quantas existem.

### Entregar desenho que se consegue construir
A entrega decide se a construção corre bem ou se se transforma em interpretação.
- Entregue um pequeno sistema, não apenas ecrãs: cores, tipos, espaçamentos, componentes.
- Documente os estados de cada componente: normal, foco, ativo, desativado, erro.
- Especifique o comportamento entre pontos de rutura, não apenas duas larguras fixas.
- Inclua os estados vazios e de erro de cada ecrã.
- Exporte imagens em formatos modernos e nos tamanhos em que serão usadas.
- Marque o que é fixo e o que pode adaptar-se — quem constrói vai encontrar casos que não previu.
- Faça uma sessão de entrega ao vivo. Meia hora poupa uma semana de perguntas.

Q: Quantas rondas de revisão são normais?
A: Duas a três por fase é o habitual e deve estar no contrato, com definição do que conta como ronda. Sem esse limite, o desenho tende a expandir-se indefinidamente porque cada nova pessoa que vê os ecrãs tem uma opinião. Um responsável único pela decisão vale mais do que qualquer limite numérico.

Q: Preciso de esquemas se já tenho referências?
A: Sim, porque as referências mostram estilo e os esquemas resolvem estrutura. Passar diretamente de referências para ecrãs finais costuma resultar em discussões sobre cor quando o problema real é a hierarquia da informação. Os esquemas são rápidos de fazer e ainda mais rápidos de mudar.

Q: Devo desenhar todas as páginas?
A: Desenhe os modelos, não as páginas. Um site de cinquenta páginas costuma ter cinco ou seis modelos distintos. Desenhe cada modelo com o caso mais difícil de conteúdo — o título mais longo, a lista mais comprida — e as páginas restantes seguem sem trabalho adicional.

Q: Quem deve aprovar o desenho?
A: Uma pessoa, com autoridade real. Pode recolher opiniões de várias, mas a decisão tem de ser de alguém. Aprovação por comité produz desenhos que ninguém detesta e ninguém defende, e é a causa mais frequente de projetos que se arrastam meses na fase visual.

## Planeamento de um site: o guia completo
https://websitedevelopment.biz/pt/guides/guia-de-planeamento-de-um-site
Atualizado a 2026-08-07 · Planeamento do site

A maioria dos projetos de sites que correm mal não falha na construção. Falha no planeamento, quando ninguém decidiu o que o site tinha de fazer nem quem escrevia os textos.

Este guia percorre o trabalho que antecede o desenho e o código, pela ordem em que compensa fazê-lo, com atenção às decisões que são baratas agora e caras depois.

### Comece pelo que o site tem de fazer
«Precisamos de um site» não é um objetivo. Um objetivo é algo que se pode medir e que permite decidir entre duas alternativas quando surgir a dúvida.
- Escreva a ação principal que quer que um visitante faça — pedir orçamento, comprar, candidatar-se, ligar.
- Escreva a segunda ação, para quem não está pronto para a primeira.
- Defina como vai saber se está a funcionar: pedidos por mês, vendas, candidaturas.
- Anote o que o site não tem de fazer. Esta lista poupa mais tempo do que a primeira.
- Registe os números atuais, se existirem, para poder comparar depois.
- Identifique quem decide. Um projeto com quatro decisores e nenhum responsável atrasa sempre.
Se não conseguir escrever a ação principal numa frase, o problema ainda não é o site — é a proposta comercial.

### Quem vai visitar e o que precisa de saber
Não é preciso um estudo formal. É preciso saber quem chega, com que dúvida e em que estado de decisão.
| Quem compra realmente? | Vendas, faturação, clientes atuais | Define o tom e os exemplos |
| O que perguntam sempre? | E-mails, telefone, apoio ao cliente | Torna-se conteúdo das páginas |
| O que os faz hesitar? | Negócios perdidos | Preço, prazos, referências |
| Como chegam até si? | Análise, perguntar aos clientes | Define as páginas de entrada |
| Que dispositivo usam? | Análise | Define a prioridade do desenho |
| Com quem o comparam? | Perguntar aos clientes recentes | Define o que destacar |
As perguntas que recebe por telefone são o melhor plano de conteúdos que existe, e são gratuitas.

### Conteúdo: o que atrasa quase todos os projetos
O conteúdo é a causa mais frequente de atraso e a mais subestimada no orçamento. Decida isto antes de assinar seja o que for.
- Decida quem escreve cada página, com nome próprio, não com departamento.
- Defina uma data de entrega para os textos e trate-a como trata a data de lançamento.
- Conte quantas páginas precisam realmente de texto novo — é sempre mais do que parece.
- Decida sobre fotografia: sessão própria, banco de imagens ou uma mistura. A sessão precisa de agenda.
- Verifique o que pode reaproveitar do site atual sem reescrever.
- Se ninguém internamente tem tempo, contrate quem escreva. É mais barato do que o projeto parado.
- Escreva primeiro as páginas principais; as secundárias podem entrar depois do lançamento.

### Orçamento, prazo e o que os faz derrapar
Ordens de grandeza realistas, e as variáveis que realmente movem os números.
| Site institucional simples | 4 a 8 semanas | Textos em atraso |
| Site com blogue e CMS | 6 a 12 semanas | Número de modelos, não de páginas |
| Loja online | 8 a 16 semanas | Catálogo, integrações, regras de IVA |
| Site multilingue | Acrescenta 30 a 50 % | Tradução e revisão |
| Migração de site existente | Acrescenta 2 a 4 semanas | Mapeamento de URL e conteúdo antigo |
| Integração com sistemas internos | Muito variável | Documentação do outro sistema |
Peça orçamentos que separem desenho, construção, conteúdo e integrações. Um valor único impede comparação e esconde onde está o risco.

Q: Quanto tempo demora planear um site?
A: Para um site institucional, uma a duas semanas de trabalho concentrado chegam para objetivos, público, estrutura e inventário de conteúdos. Para projetos maiores, três a quatro semanas. O planeamento raramente é o que atrasa — o que atrasa é adiar decisões que depois surgem a meio da construção, quando já custam dez vezes mais.

Q: Preciso de um documento de requisitos?
A: Precisa de algo escrito, mesmo que sejam duas páginas. Objetivos, lista de páginas, funcionalidades, quem escreve o quê e o que fica de fora. A extensão importa menos do que existir: sem documento, o âmbito muda sem que ninguém repare, e a discussão sobre o que estava combinado acontece no pior momento possível.

Q: Devo planear tudo antes de começar?
A: Planeie o suficiente para decidir estrutura, âmbito e responsabilidades. Não planeie ao nível do texto de cada botão — isso resolve-se melhor durante a construção, com ecrãs à frente. A regra prática é planear o que é caro mudar depois e deixar em aberto o que é barato ajustar.

Q: E se o orçamento não chegar para tudo?
A: Reduza o âmbito, não a qualidade. Menos páginas bem feitas superam um site completo mal executado, e é sempre possível acrescentar depois. Corte primeiro o que não serve a ação principal: galerias, animações, secções que ninguém pediu. O que não deve cortar é conteúdo, velocidade e o percurso até ao contacto.