Sites

A quem pertence o seu site? A pergunta que ninguém faz

Domínio, conteúdo, código, acessos: o seu site é um conjunto de 4 ativos que podem pertencer a pessoas diferentes. Como verificar quem possui o quê.

Por InlevenAtualizado a 24 de junho de 20268 min de leitura
Chave de vidro luminosa pousada sobre um cubo translúcido, imagem da propriedade do seu site

Um site não é um objeto. É um conjunto de quatro ativos distintos (o nome de domínio, o conteúdo, o código e os acessos aos serviços que o fazem funcionar) que podem pertencer a pessoas diferentes. Se um deles estiver em nome do seu prestador em vez do seu, está cativo sem o saber. No dia em que quiser recuperar os seus ativos para os levar para outro lado, descobre que « o seu » site não o é tanto quanto pensava. Eis como verificar quem possui o quê, e o que exigir a um prestador antes que seja tarde de mais.

Um « site », na verdade, são 4 ativos separados

Quando diz « o meu site », está na realidade a falar de quatro coisas:

  1. O nome de domínio, a-sua-empresa.pt. O endereço onde o encontram.
  2. O conteúdo, os seus textos, fotos, vídeos, logótipos. A matéria do site.
  3. O código, os ficheiros técnicos (HTML, CSS, JS, base de dados) que fazem o site funcionar.
  4. Os acessos, contas de alojamento, base de dados, serviços de terceiros (Google Analytics, formulários, pagamento…). As chaves do motor.

Cada um destes ativos pode, legalmente, pertencer a uma pessoa diferente. Numa montagem limpa, os quatro são seus. Numa montagem menos limpa, basta um ao prestador para o manter preso.

Quem possui o nome de domínio?

É o ponto que mais surpreende, do dirigente de uma pequena empresa ao responsável informático de uma PME que descobre que o domínio histórico da casa nunca esteve em seu nome. Um nome de domínio não é « vendido », é alugado, em geral por um a dez anos, junto de um registador (OVH, Gandi, Cloudflare, GoDaddy, etc.). E é a pessoa inscrita como titular (« owner » nas bases públicas whois) que decide tudo: transferência, renovação, redirecionamento, rescisão.

Três cenários frequentes:

  • O domínio está em seu nome (ou no da sua empresa). É o bom caso. Pode transferi-lo para outro registador a qualquer momento, sem pedir autorização a quem quer que seja.
  • O domínio está em nome do seu prestador. Enquanto continuar com ele, nenhum problema visível. No dia em que quiser recuperá-lo, pede a transferência, e ele recusa, fatura custos de saída, ou deixa de responder.
  • O domínio está num registador « caseiro » do prestador. O pior caso: sem procedimento de transferência padrão, dependência técnica enxertada na dependência comercial.

Verificar demora dois minutos. Escreva whois a-sua-empresa.pt em qualquer ferramenta whois online (a AFNIC oferece uma gratuita para os .fr). O campo « Titular » deve mostrar o seu nome ou o da sua empresa. Se for outra coisa, é o momento de agir, e não daqui a dois anos.

E quando já gerimos os nossos DNS e as nossas contas cloud?

O que precede continua a ser um lembrete útil, mesmo quando julgamos saber. Um patamar acima, a nuance que apanha as equipas técnicas reside na distinção entre titular e gestor. Na consola de um registador ou de um alojador, a conta « owner » (a que detém juridicamente o recurso e o pode encerrar ou transferir) não é a conta « admin » que administra no dia a dia. Um prestador pode perfeitamente dar-lhe um acesso admin confortável e, ao mesmo tempo, guardar a propriedade real. Verifique o papel, não apenas o facto de ter um login.

Mais dois pontos para uma direção de sistemas de informação:

  • DNS delegados. O domínio pode estar em seu nome mas com os respetivos servidores DNS delegados no prestador (ou apontados para a infraestrutura dele). É proprietário, mas a resolução depende dele. Idealmente, a zona DNS está alojada numa conta que controla (Cloudflare, o registador, o seu próprio DNS gerido).
  • Contas cloud e transferência de propriedade. Quando a infraestrutura corre em AWS, GCP ou Cloudflare, a verdadeira pergunta não é « tenho acesso? » mas « a conta de faturação e a organização estão em meu nome? ». Migrar um projeto entre duas contas AWS ou transferir a propriedade de uma organização Cloudflare não é trivial: mais vale que esteja definido desde o início do que na urgência do fim de uma relação.

Quem possui o conteúdo e o código?

Legalmente, é o autor do que escreve e proprietário das fotos que tirou ou encomendou. Para o conteúdo que fornece, a questão é clara: é seu. Peça apenas que o contrato o recorde, preto no branco.

Quanto ao código, é mais subtil. Existem três casos típicos.

Site à medida desenvolvido para si. O contrato deve prever explicitamente que o código-fonte lhe é entregue no fim do projeto ou a pedido, e que lhe pertence. Sem essa cláusula, o prestador continua proprietário do seu trabalho, e o senhor tem um direito de utilização, não de propriedade.

Site montado sobre um CMS de código aberto (WordPress, Astro, etc.). O código do CMS não lhe pertence (está sob licença livre, acessível a toda a gente). Já o código específico do seu site, tema, configuração, plugins desenvolvidos à medida, esse deve ser-lhe entregue.

Site numa plataforma proprietária (Wix, Squarespace, Webflow, ou um construtor caseiro do prestador). Não possui o código, aluga o uso da plataforma. É aceitável desde que os outros ativos (domínio, conteúdo, acessos) sejam seus, e que a plataforma o deixe exportar o seu conteúdo se sair.

O ponto a reter: ser incapaz de recuperar o seu conteúdo num formato reutilizável (Markdown, HTML, CSV, base SQL…) é o verdadeiro sinal do aprisionamento. Não o facto de possuir o código em si.

Quatro objetos de vidro alinhados (globo, documento, chavetas de código, chave), imagem dos quatro ativos de um site

E os acessos de alojamento, e-mail, analítica?

A armadilha menos visível, e no entanto a mais frequente. Quatro contas a vigiar.

  • A conta de alojamento (OVH, Cloudflare, Netlify, Vercel…). Se estiver aberta em nome do prestador, ele pode cortar-lhe o site em dois cliques. Peça que seja aberta em seu nome, com os seus identificadores, e que o prestador seja adicionado como colaborador.
  • As caixas de e-mail ligadas ao domínio (contacto@a-sua-empresa.pt, etc.). O mesmo: conta em nome da sua empresa, prestador com acesso delegado.
  • Google Analytics ou equivalente. O histórico de tráfego é precioso. A conta deve estar em nome da sua empresa, com o senhor como administrador.
  • Serviços de terceiros, formulários, calendário de reservas, pagamento Stripe, etc. Todas estas contas devem estar em nome da sua empresa. O prestador é um convidado, não o proprietário.

Uma boa regra: se o seu prestador fechasse portas amanhã, seria capaz de recuperar todas as chaves do site em menos de um dia? Se a resposta for « não », falta algo por regularizar agora.

Como verificar em 5 minutos?

Um pequeno inquérito rápido:

  1. Faça um whois ao seu domínio. Anote o titular.
  2. Abra a sua última fatura de alojamento. Em que nome está?
  3. Inicie sessão na sua conta de alojamento. Tem um acesso de administrador, ou apenas « editor »?
  4. Pergunte a si próprio: se quisesse exportar todo o conteúdo do meu site esta semana, sei como fazê-lo?
  5. Tem algures, no seu computador, num e-mail, num drive, uma cópia do contrato com o seu prestador e a lista de acessos?

Se ficar bloqueado numa destas etapas, é um sinal, não uma catástrofe. Um prestador sério regulariza sem dificuldade: domínio entregue em seu nome, acessos transferidos, contrato clarificado. Uma relutância é, em si mesma, uma resposta.

As boas perguntas a fazer antes de assinar

Antes de arrancar com um novo prestador, peça por escrito (um e-mail basta):

  • O nome de domínio ficará em meu nome (ou no da minha empresa)?
  • O contrato precisa que o conteúdo e o código específico me pertencem?
  • Em que alojador será o site colocado, e a conta ficará em meu nome?
  • No dia em que decidir sair, qual é exatamente o procedimento para recuperar o meu domínio, o meu conteúdo e o meu código, e há custos de saída?

Os bons prestadores respondem depressa e com clareza, porque já ouviram a pergunta e ela joga a favor deles. Os outros andam às voltas. É precisamente a informação que procurava.

Estas perguntas aplicam-se seja qual for o formato, subscrição, pagamento único, freelancer ou agência. A armadilha não está no modo de faturação: um site pago de uma só vez pode perfeitamente deixá-lo cativo se o domínio ficar em nome do prestador, e uma subscrição pode deixá-lo sair com tudo. Se quiser aprofundar especificamente o formato subscrição, é por aqui. Para situar as verdadeiras faixas de custos por formato, o artigo sobre os preços completa o quadro.

Do lado da Inleven, quisemos tornar estes compromissos explícitos e públicos. A página Garantias lista preto no branco quem possui o quê: domínio, conteúdo e código são seus desde o primeiro dia, e sai com tudo, sem custos de saída nem penalização. É também o que detalha a nossa oferta: um primeiro ano que financia o trabalho à medida, em 12 vezes ou de uma vez, depois 180 €/ano com tudo incluído. É a leitura que gostaríamos de ter tido quando começámos.

Perguntas frequentes

O meu prestador pode ficar com o meu nome de domínio se eu deixar de trabalhar com ele?

Se for o titular (o campo « owner » nas bases whois), sim, tem o controlo jurídico sobre ele. É precisamente por isso que vale a pena verificar já agora se o domínio está registado em seu nome ou no da sua empresa. Se estiver, pode transferi-lo para outro registador quando quiser, sem o acordo dele.

Ter um acesso de administrador é o mesmo que ser proprietário?

Não, e é a confusão mais cara. Uma conta « admin » administra no dia a dia; uma conta « owner » detém o recurso e é a única que o pode transferir, encerrar ou alterar a faturação. Pode dispor de um acesso admin muito completo e, ao mesmo tempo, não ser proprietário de nada. Verifique o papel exato, não apenas o facto de ter um identificador.

Se o meu site está no Wix, Squarespace ou Webflow, fico cativo?

Não necessariamente. Não possui o código destas plataformas, mas isso é aceitável desde que o domínio, o conteúdo e os acessos estejam em seu nome, e que a plataforma o deixe exportar o seu conteúdo num formato reutilizável. O verdadeiro sinal de captividade não é a ausência de código, é a incapacidade de recuperar os seus dados.

O que pedir concretamente antes de assinar, para poder recuperar os ativos mais tarde?

Peça por escrito que o domínio fique em seu nome, que o contrato precise a propriedade do conteúdo e do código específico, que as contas de alojamento e serviços de terceiros sejam abertas em nome da sua empresa (com o prestador como colaborador), e qual é o procedimento exato de recuperação do domínio, do conteúdo e do código no dia em que sair, custos de saída incluídos. Um prestador sério põe tudo isto por escrito sem hesitar.

Tem um projeto?

Uma chamada de 15 minutos basta para começar. Sem compromisso.