Melhor stack para o site de uma pequena empresa

O site de uma padaria, de um escritório de contabilidade ou de uma clínica tem um trabalho simples: mostrar o que a empresa faz, onde fica, quando abre e como entrar em contato. Mesmo assim, é comum ver pequenos negócios com stacks pesadas demais para isso, que ficam lentas, desatualizadas e caras de manter.

A escolha certa parte da necessidade do negócio, não da moda. Quase sempre a resposta é uma stack menor do que parece, completada por algumas peças de que todo site precisa: domínio, HTTPS, contato e métricas.

O que o site de uma pequena empresa realmente precisa?#

Quase todo negócio local precisa das mesmas coisas:

• Poucas páginas: início, serviços ou cardápio, sobre, contato. Às vezes um blog.
• Contato direto: botão de WhatsApp, telefone clicável, e-mail e endereço com mapa.
• Funcionar bem no celular, onde está a maior parte das visitas de busca local.
• Carregar rápido e ter HTTPS. Veja o que é SSL/TLS.
• Domínio próprio, que passa confiança e não depende de nenhum fornecedor de site.
• Dados que o Google entende: nome, endereço, telefone e horário marcados com dados estruturados.

Login de clientes, carrinho, agendamento e área administrativa são exceções. Se o seu caso não tem nenhuma delas, a stack pode ser bem simples.

Que critérios usar para escolher a stack?#

1. Quem vai editar o conteúdo, e com que frequência? Se o dono muda o horário duas vezes por ano, editar um arquivo resolve. Se a equipe publica posts toda semana, um painel de edição faz falta.
2. Há funcionalidade dinâmica? Pedidos, reservas e contas de clientes exigem servidor e banco de dados. Um formulário de contato sozinho, não.
3. Quanto de manutenção você aceita? Cada servidor, plugin e banco é algo para atualizar. Menos peças significa menos falhas de segurança.
4. Desempenho e busca. Páginas leves e HTML pronto ajudam a carregar rápido no celular.
5. Custo total. Some hospedagem, domínio, plugins ou temas pagos e as horas de quem mantém. Veja quanto custa hospedar um site.

Quais são as opções?#

Site estático feito à mão#

HTML e CSS escritos diretamente, publicados como arquivos. Sem servidor de aplicação, sem banco, sem plugin. Prós: o mais rápido, o mais seguro, custo mínimo. Contras: editar exige mexer no código, e repetir cabeçalho e rodapé em várias páginas fica trabalhoso. Veja o que é um site estático.

Gerador de site estático (Astro, Hugo, Eleventy)#

Você escreve páginas em Markdown ou componentes, e o gerador produz HTML estático no build. Com Astro, um projeto começa com npm create astro@latest. Prós: a velocidade e a segurança do estático, com layouts reutilizáveis e blog em Markdown. Contras: alguém precisa saber rodar o build e publicar. A diferença entre os modos de renderização está em SSR, SSG e estático.

WordPress#

Um CMS em PHP com banco MySQL ou MariaDB, com painel de edição, temas e milhares de plugins. A documentação oficial recomenda usar a versão mais nova do PHP sempre que possível, com MySQL ou MariaDB em uma versão ainda suportada, e suporte a HTTPS. Prós: qualquer pessoa edita pelo painel, há plugin para quase tudo, inclusive loja. Contras: núcleo, tema e plugins precisam de atualização constante, o banco precisa de cópias de segurança e muitos plugins deixam o site lento.

Construtor de sites (Wix, WordPress.com e afins)#

Editor visual, modelo e hospedagem num serviço só, cobrado por mês. Prós: sem código, sem servidor, no ar no mesmo dia. Contras: você aceita os limites da ferramenta, o custo mensal sobe com recursos extras e sair dela normalmente significa refazer o site.

Framework full-stack (Next.js, Laravel, Django)#

Uma aplicação com servidor, rotas e banco. Prós: faz qualquer coisa: pedidos, agendamento, área do cliente. Contras: é software para desenvolver e manter. Para um site institucional, é mais do que o problema pede. Veja a diferença em hospedagem de site ou de aplicação.

Como as opções se comparam?#

Qual stack escolher em cada cenário?#

• Restaurante, salão, oficina, prestador de serviço: site estático ou gerador, com botão de WhatsApp, mapa e dados estruturados. É o caso mais comum.
• Escritório ou consultório que publica artigos toda semana: WordPress, ou um gerador estático com blog em Markdown se quem escreve sabe usar Git.
• Pequena loja com poucos produtos: comece pelo catálogo estático com pedido pelo WhatsApp. Quando o volume justificar, migre para uma loja com carrinho e pagamento.
• Agendamento, área do cliente ou sistema próprio: framework full-stack com banco de dados. Veja como hospedar um site para os passos.
• Ninguém da empresa mexe com tecnologia e não há orçamento para alguém mexer: um construtor de sites é uma escolha honesta, sabendo que sair dele custa caro.

Que peças completam qualquer stack?#

Domínio e DNS. Registre o domínio no seu nome, num registrador, e aponte os registros DNS para a hospedagem. Veja como usar um domínio personalizado.

Contato e dados estruturados. Um link wa.me abre a conversa no WhatsApp com uma mensagem pronta (o número vai com código do país, sem + nem traços, e o texto precisa estar codificado para URL). Junto, marque os dados do negócio com o tipo LocalBusiness do schema.org, cujos campos obrigatórios para o Google são name e address:

<section id="contato">
  <h2>Fale com a gente</h2>
  <!-- Troque pelo seu número: código do país + DDD + número -->
  <a href="https://wa.me/5562900000000?text=Ol%C3%A1!%20Vim%20pelo%20site%20e%20quero%20um%20or%C3%A7amento.">Chamar no WhatsApp</a>
  <a href="tel:+556232000000">(62) 3200-0000</a>
  <a href="mailto:contato@example.com">contato@example.com</a>
</section>

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Bakery",
  "name": "Padaria Exemplo",
  "url": "https://www.example.com",
  "telephone": "+55 62 3200-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua Exemplo, 100",
    "addressLocality": "Goiânia",
    "addressRegion": "GO",
    "postalCode": "74000-000",
    "addressCountry": "BR"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"],
      "opens": "06:00",
      "closes": "20:00"
    }
  ]
}
</script>

Bakery é um subtipo de LocalBusiness; use o mais específico que existir para o seu negócio. Depois de publicar, valide a página no Teste de pesquisa aprimorada do Google.

E-mail profissional. E-mail com o seu domínio é um serviço separado do site, configurado com registros MX no DNS.

Métricas. Ferramentas de analytics que usam cookies de rastreamento podem exigir banner de consentimento pela LGPD. Analytics sem cookies evita parte desse atrito para quem só quer saber quantas pessoas visitam e de onde vêm.

Como fazer isso na Square Cloud#

A Square Cloud é hospedagem self-service: você publica o site e controla tudo. Para a stack mais comum deste artigo, use o runtime de sites estáticos: envie o HTML pronto (ou a pasta gerada pelo build do Astro, Hugo ou Eleventy) por upload de ZIP no painel, pela CLI ou pelo GitHub. Nesse runtime o nginx fica sempre no ar servindo os arquivos, e cada atualização entra no ar na hora. Se o site tiver servidor, há diversos runtimes, como Node.js, PHP e Python; veja os disponíveis hoje em Runtimes.

Toda aplicação web ganha um subdomínio *.squareweb.app com HTTPS em todo plano, e uma aplicação web usa no mínimo 512 MB do pool de RAM do plano. O domínio próprio começa no Standard, a partir de R$ 44,99 por mês: você cria no seu registrador os registros DNS mostrados no painel, acompanha a validação em tempo real e o TLS é emitido automaticamente. O domínio continua no seu nome, no seu registrador.

Todo plano inclui analytics web sem cookies, coletado no servidor, com visitas, rotas, países e códigos de status. Veja mais na página de Sites.