O que encontrámos em 109 sites de alojamentos do Sotavento

Em novembro de 2026 verificámos os 109 sites que os empreendimentos turísticos do Sotavento indicam no Registo Nacional de Turismo, e em 15 o endereço não abriu. Nos sites que abriram, a página inicial levou em mediana 9,5 segundos a mostrar o conteúdo principal no teste de laboratório Lighthouse (perfil móvel), 67% dos domínios de e-mail não pedem aos servidores de correio que travem mensagens falsificadas e 31% dos sites não mostram na página inicial uma ligação ao Livro de Reclamações.

Como fizemos o estudo

Partimos do Registo Nacional dos Empreendimentos Turísticos (RNET), a lista do Turismo de Portugal com os empreendimentos que têm título de abertura válido, consultada através do serviço de dados abertos. Escolhemos os sete concelhos do Sotavento (Faro, Olhão, São Brás de Alportel, Tavira, Vila Real de Santo António, Castro Marim e Alcoutim) e ficámos com todos os empreendimentos que indicam um site no registo: 109. Outros 45 empreendimentos destes concelhos não indicam site nenhum. O alojamento local não está incluído, porque o registo do AL não tem campo para o site.

Os 109 são 35 hotéis, 23 casas de campo, 18 agroturismos, 9 hotéis-apartamentos, 6 hotéis rurais, 5 parques de campismo, 4 apartamentos turísticos, 3 pousadas, 3 aldeamentos turísticos e 3 casas de turismo de habitação.

Fizemos uma única passagem no dia 8 de novembro de 2026, entre a 01:00 e as 01:58 (hora de Lisboa). A verificação foi só passiva e limitada ao que qualquer visitante ou as ferramentas do Google veem: a página inicial (e a página que o botão de reservar abre), os ficheiros públicos que orientam os robôs de pesquisa (robots.txt, llms.txt e o mapa do site), os registos DNS do domínio (as definições públicas que dizem que servidores tratam do site e do correio), o certificado de segurança que dá o cadeado no navegador e os cabeçalhos que o servidor envia com a página. Não entrámos em contas, não fizemos varrimentos e não procurámos páginas escondidas.

Para a velocidade usámos o Google Lighthouse 12.8, o motor que o PageSpeed Insights usa nos testes de laboratório, com o perfil móvel e uma ligação 4G lenta simulada. Um teste de laboratório costuma dar tempos piores do que uma visita real numa boa ligação. Serve para comparar sites nas mesmas condições e não prevê quanto tempo espera cada hóspede. A métrica principal é o LCP (Largest Contentful Paint), o momento em que aparece a imagem ou o bloco de texto principal. Segundo a Google, um LCP até 2,5 segundos é "bom" e acima de 4 segundos é "fraco".

Os avisos legais foram procurados apenas na página inicial. Um site pode tê-los noutra página, e por isso escrevemos sempre "não encontrámos na página inicial".

Não publicamos nomes nem classificações. É a mesma verificação do Raio-X gratuito, em que o resultado de cada site vai só para o respetivo proprietário.

Os números principais

A coluna "Base" indica sobre quantos endereços, sites ou domínios de e-mail foi feita cada conta.

Páginas lentas e poucos motores de reservas

Dos 94 sites que abriram, 91 completaram o teste Lighthouse, e o LCP mediano foi de 9,5 segundos. Em 78 dos 91 sites (86%) passou dos 4 segundos que a Google classifica como "fraco", e só 6 ficaram abaixo dos 2,5 segundos. A pontuação mediana de desempenho do Lighthouse foi 50 em 100, com 44 sites abaixo de 50. A página inicial mediana pesa 4,0 MB, e 41 páginas passam dos 5 MB. Para comparação, o livinstaysalgarve.com, um site de cliente que construímos, teve um LCP de 1,8 segundos no mesmo teste (piloto de 7 de novembro de 2026).

A velocidade pesa nas reservas. O estudo Milliseconds make millions, encomendado pela Google e feito pela 55 e pela Deloitte em 37 sites de marcas europeias e americanas no fim de 2019, mediu que uma melhoria de 0,1 segundos em várias métricas de velocidade, em todas as páginas do percurso, deu aos sites de viagens uma taxa de reservas 10% melhor. São marcas grandes, e num alojamento com oito quartos o efeito pode ser maior ou menor.

Detetámos um motor de reservas (o sistema que mostra a disponibilidade e aceita a reserva no próprio site) em 43 dos 94 sites (46%): GuestCentric em 12, Cloudbeds, D-EDGE e MotoPress em 5 cada, SiteMinder e Amenitiz em 4 cada, e outros. Os restantes mandam o hóspede para o e-mail, o telefone, um formulário ou uma agência online como a Booking, ou usam um motor que não conseguimos detetar. Nove páginas iniciais têm uma ligação direta para a Booking.com e dez mostram uma ligação para WhatsApp. Sem motor de reservas, o hóspede não vê a disponibilidade nem paga no momento: tem de escrever e esperar pela resposta.

E-mails falsificados em nome do alojamento

O DMARC é uma das definições públicas do domínio (um registo DNS) e diz aos servidores de correio o que fazer com uma mensagem que usa o nome do domínio mas falha as verificações. Segundo a documentação da Google, com p=none a mensagem é entregue normalmente, com p=quarantine vai para a pasta de spam e com p=reject é recusada.

Dos 83 domínios distintos, 33 (40%) não têm registo DMARC e 23 (28%) têm DMARC em p=none, que só observa. Juntos são 56 de 83 (67%) que não dão aos servidores que recebem o correio nenhuma instrução para rejeitar ou pôr em quarentena um e-mail falsificado com o nome do seu domínio. Só 15 (18%) pedem quarentena e 12 (14%) pedem rejeição. Há ainda 12 domínios (14%) sem registo SPF, a lista dos servidores autorizados a enviar e-mail em nome do domínio.

Num alojamento, o hóspede espera receber e-mails sobre pagamentos e tende a confiar numa mensagem que parece vir do endereço do hotel. As burlas que usam o nome dos alojamentos estão no artigo sobre burlas com contas da Booking, e o caminho de p=none até p=reject está no artigo sobre SPF, DKIM e DMARC.

Na noite de 7 de novembro de 2026 fizemos esse percurso no livinstaysalgarve.com: passou de p=none para p=quarantine depois de confirmarmos que os dois remetentes reais (a Resend, que envia os e-mails da aplicação aos hóspedes, e as caixas de correio Titan) passavam na verificação DKIM, a assinatura que prova que a mensagem saiu de um remetente autorizado pelo domínio.

Seis dos 94 sites mostram como contacto um endereço de correio gratuito (Gmail, Hotmail e semelhantes). Qualquer pessoa pode criar nesses serviços um endereço quase igual, e o hóspede não tem como saber qual é o verdadeiro.

Avisos legais que não estão na página inicial

Não encontrámos na página inicial uma ligação ao Livro de Reclamações em 29 dos 94 sites (31%). O Decreto-Lei 156/2005, no artigo 5.º-B, n.º 2, diz que os fornecedores de bens e prestadores de serviços "devem divulgar nos respetivos sítios na Internet, em local visível e de forma destacada, o acesso à Plataforma Digital" do livro de reclamações eletrónico.

Não encontrámos menção a uma entidade de resolução alternativa de litígios (RAL) em 76 sites (81%). O artigo 18.º da Lei 144/2015, na redação dada pelo Decreto-Lei 102/2017, obriga a informar os consumidores sobre as entidades de RAL a que o fornecedor está vinculado, por adesão ou por arbitragem necessária, e a indicar o site dessas entidades. No Algarve, o centro de arbitragem de conflitos de consumo é o CIMAAL.

Não encontrámos uma ligação para a política de privacidade em 17 sites (18%). Um site ainda aponta para a plataforma europeia de resolução de litígios em linha (ODR), que o Regulamento (UE) 2024/3228 encerrou a 20 de julho de 2025.

O mesmo aconteceu num site que construímos. A 7 de novembro de 2026, ao preparar o Raio-X, verificámos o livinstaysalgarve.com e faltavam a ligação ao Livro de Reclamações e a linha do CIMAAL. Ficaram no rodapé nessa mesma noite. As regras, os casos em que se aplicam e as coimas estão no artigo sobre avisos legais obrigatórios no site de um alojamento.

O que o Google e os assistentes de IA encontram

Só 20 dos 94 sites (21%) se descrevem, em dados estruturados, como hotel ou outro tipo de alojamento (os tipos Hotel, LodgingBusiness, BedAndBreakfast, Resort, VacationRental e semelhantes do schema.org). Os dados estruturados são código que o hóspede não vê e que diz às máquinas, num formato fixo, o nome, a morada, o tipo de negócio e as horas de check-in. A Google escreve no seu guia para as funcionalidades de IA da Pesquisa que não são obrigatórios para aparecer nas respostas geradas por IA e que não há marcação especial a acrescentar. Deixam os factos escritos de forma que uma máquina não tenha de os adivinhar.

Em 29 sites (31%) a página inicial não tem título principal (H1), e em 21 (22%) não tem meta descrição, o pequeno resumo que pode aparecer nos resultados de pesquisa. Têm mapa do site 74 sites (79%), e 58 (62%) declaram as versões noutras línguas (hreflang).

Encontrámos um ficheiro llms.txt (um resumo do site em texto simples, proposto para os assistentes de IA) em 22 sites, vários com ar de terem sido gerados automaticamente por plugins de SEO, e 1 site bloqueia os robôs de IA no robots.txt. Até novembro de 2026, nenhum dos grandes assistentes de IA disse publicamente que usa o llms.txt, e a Google escreve, no mesmo guia, que a Pesquisa não usa este tipo de ficheiros.

Sites que não abrem, ou abrem com avisos

Dos 109 endereços do registo, 15 (14%) não abriram. Em 11 o endereço não resolve: o domínio já não existe, mudou ou está mal escrito no registo. Um não respondeu a tempo e 3 devolveram um erro do servidor ou recusaram o pedido.

O RNET é público, e quem o consulta encontra o mesmo endereço morto que nós. Quando um domínio deixa de ser renovado e é apagado, as regras da ICANN para os domínios genéricos dão 30 dias para o recuperar e, ao fim de mais 5, o nome fica livre para quem o registar primeiro. Os passos, e o que acontece ao e-mail, estão no artigo sobre domínios expirados.

Entre os 94 sites que abriram, 8 não redirecionam http:// para https:// e 2 tinham um certificado inválido no dia da verificação, o que faz o navegador mostrar um aviso de segurança antes da página. O Lighthouse também mede a acessibilidade, e 26 dos 91 sites tiveram pontuação abaixo de 80.

O que corrigir primeiro

Por ordem de esforço, do mais rápido ao mais demorado:

1. Abra o endereço que o RNET tem para o seu empreendimento e confirme que é o site atual. Se mudou, peça a correção ao Turismo de Portugal.
2. Ponha no rodapé de todas as páginas a ligação ao Livro de Reclamações eletrónico, a entidade de resolução alternativa de litígios com o respetivo site (no Algarve, o CIMAAL) e a política de privacidade. Retire qualquer ligação à antiga plataforma ODR.
3. Publique um registo DMARC em p=none com endereço para relatórios e confirme o SPF. Quando os relatórios mostrarem que todos os seus remetentes legítimos passam, suba para p=quarantine e, mais tarde, para p=reject.
4. Troque o endereço Gmail ou Hotmail de contacto por um endereço do seu domínio.
5. Confirme em nome de quem está o domínio, ative a renovação automática e acrescente um segundo e-mail de contacto no registador.
6. Faça o site redirecionar sempre para https:// e verifique a data de validade do certificado.
7. Reduza o peso da página inicial (fotografias comprimidas e no tamanho em que aparecem, nenhum vídeo a arrancar sozinho no telemóvel) e repita o teste no PageSpeed Insights depois de cada alteração.
8. Acrescente dados estruturados de alojamento com os mesmos factos que a página mostra, um título principal (H1) e uma meta descrição.
9. Se o site não tem motor de reservas, escolha um que mostre a disponibilidade em tempo real e aceite o pagamento no momento.

O que este estudo não vê

Este estudo vê o que qualquer visitante vê, que é o lado de fora. O que protege um alojamento no dia a dia está do lado de dentro, e nenhuma verificação pública chega lá: se os computadores e os telemóveis da equipa têm o sistema, o navegador e as aplicações atualizados e uma proteção ativa; se ficaram instalados ou ligados programas de controlo remoto (AnyDesk, TeamViewer e semelhantes) que já ninguém usa; se o router tem a administração fechada e se há câmaras, gravadores ou discos de rede abertos à internet; se o Wi-Fi dos hóspedes está separado da rede da receção e das câmaras; se as cópias de segurança já foram restauradas pelo menos uma vez; se cada pessoa tem as suas próprias contas, se quem saiu perdeu o acesso e se a Booking, o Airbnb, o Google e o e-mail pedem verificação em dois passos.

As tentativas de ataque são automáticas e chegam a alojamentos de todos os tamanhos, incluindo os bem geridos, por isso estes pontos valem a pena em qualquer casa. No Raio-X no local verificamos este lado de dentro numa visita e deixamos um relatório escrito curto com um orçamento para o que for preciso corrigir; o preço da visita é dado a pedido.