Como usar HTML de forma estratégica, não como gambiarra

Se você já criou um blog em Django, sabe o problema.
Funciona, mas cresce rápido e vira bagunça.

HTML repetido.
SEO improvisado.
Templates cheios de lógica.

Na prática, o erro não está no Django.
Está na forma como usamos HTML sem arquitetura.

Neste artigo, vou te mostrar como pensar templates Django como sistema, não como arquivos soltos.
Tudo aqui eu já usei em projetos reais.
Testei, quebrei, refatorei e funcionou assim.

Por que HTML é arquitetura em Django

A imagem ilustra a ideia de que HTML é parte da arquitetura em Django ao mostrar, lado a lado, o código e o resultado final. De um lado, aparecem templates Django organizados, com herança (extends), blocos bem definidos e includes separados, representando decisões arquiteturais.

Muita gente trata template como “só HTML”.
Isso é o primeiro erro.

No Django, o template é a camada de apresentação.
Ele conversa com SEO, acessibilidade e UX.

Portanto, um HTML mal estruturado gera:

  • Código difícil de manter

  • SEO fraco

  • Layouts engessados

  • Retrabalho constante

Enquanto isso, um HTML bem arquitetado vira base para crescer.

Fundação: Herança de Templates

Tudo começa aqui:

 
{% extends "base.html" %}

Esse comando define uma regra simples e poderosa.

O que vai no base.html

  • <html>, <head>, <body>

  • Header global

  • Footer

  • Scripts e CSS

  • Blocos reutilizáveis

O template filho nunca repete estrutura global.

Regra de ouro:
Se você vê <html> em mais de um template, a arquitetura está errada.

Isso separa responsabilidades.
O base cuida da estrutura.
Os filhos cuidam do conteúdo.

SEO Profissional com Blocos Semânticos

SEO não é plugin.
É HTML bem usado.

No base.html, defina blocos:

 
<title>{% block title %}{% endblock %}</title> <meta name="description" content="{% block meta_description %}{% endblock %}">

No template da home:

 
{% block title %} Entre Bugs e Soluções | Blog {% endblock %} {% block meta_description %} Artigos práticos sobre programação, bugs reais e soluções aplicadas no dia a dia. {% endblock %}

Por que isso funciona

  • Cada página tem SEO próprio

  • Google entende contexto

  • Branding consistente

Insight real:
SEO estático bem feito é melhor que SEO dinâmico mal feito.

Componentização com {% include %}

Agora entramos no ponto que separa tutorial de projeto real.

 
{% include "blog/includes/hero.html" %}

Isso não é “organização”.
É arquitetura de UI.

Quando virar um include?

Sempre que um bloco visual tiver identidade própria.

Exemplos reais:

  • Hero

  • Grid de posts

  • Card de artigo

  • Paginação

Benefícios diretos:

  • Redesign sem quebrar páginas

  • Reutilização em landing pages

  • Testes isolados

Na prática, isso reduz bugs e acelera mudanças.

Controle de Fluxo Defensivo

Nunca assuma que haverá conteúdo.

 
{% if posts %}

Esse detalhe evita erro em produção.

Anti-pattern clássico:

 
{% if posts.count > 0 %}

Isso dispara query desnecessária.
Eu já vi isso virar gargalo real.

Template bom é defensivo.

HTML Semântico e Acessibilidade

Aqui entra o HTML de verdade.

 
<section aria-labelledby="home-posts-title"> <h2 id="home-posts-title">Últimos artigos</h2> </section>

Isso não é frescura.

  • Leitores de tela entendem a página

  • Google entende hierarquia

  • Código fica autoexplicativo

Insight prático:
Acessibilidade não é extra.
É arquitetura.

Use <header> do jeito certo

Dentro da section:

 
<header class="home-posts-header">

Por que não uma <div>?

Porque header descreve o conteúdo da section.

HTML semântico melhora:

  • SEO

  • Leitura por máquinas

  • Manutenção do código

Regra simples que sigo:
Se existe tag semântica, use.

URLs Desacopladas no Template

Nunca faça isso:

 
<a href="/blog/posts/">

Sempre use:

 
<a href="{% url 'blog:post_list' %}">

Benefícios reais:

  • Refatoração sem quebrar layout

  • URLs versionadas

  • Namespaces organizados

Isso evita bugs silenciosos no futuro.

Grid de Posts como Componente de Domínio

 
{% include "blog/includes/post_grid.html" %}

Esse grid não pertence à home.
Ele pertence ao domínio de posts.

Ele pode aparecer em:

  • Home

  • Categoria

  • Busca

  • Autor

Insight profissional:
Templates também seguem Domain-Driven Design.

Paginação Desacoplada

 
{% include "blog/includes/pagination.html" %}

Por que isolar?

Porque amanhã você pode trocar por:

  • Infinite scroll

  • HTMX

  • AJAX

  • Cache fragmentado

Quando a paginação está isolada, a evolução é simples.

Estado Vazio é Obrigatório

Sempre trate o vazio:

 
<p>Nenhum post publicado ainda.</p>

Isso salva você em:

  • Primeiro deploy

  • Ambiente de staging

  • Blog recém-criado

Regra prática:
Todo fluxo precisa de estado vazio tratado.

O que nunca deve estar no Template

Se você quer arquitetura limpa, o template não pode ter:

  • Queries

  • Regra de negócio

  • Lógica complexa

  • Decisão de domínio

Template só apresenta.

View decide.
Model organiza.

Quando isso está claro, o projeto escala.

Em resumo

HTML em Django não é detalhe visual.
É arquitetura de produto.

Quando você usa:

  • Herança correta

  • Blocos semânticos

  • Includes bem pensados

  • HTML acessível

  • Templates defensivos

Você cria base para crescer sem dor.

Na prática, foi assim que parei de refatorar blog toda semana.

 

FAQ — Arquitetura de Templates Django e HTML

HTML em Django é só apresentação?

Não. O HTML define semântica, acessibilidade, SEO e organização do layout. Isso impacta diretamente a manutenção e o crescimento do projeto.

Por que usar herança de templates (extends)?

Para centralizar a estrutura global e evitar repetição. Isso reduz bugs e facilita mudanças de layout.

Quando devo usar {% include %}?

Sempre que um bloco visual tiver identidade própria ou for reutilizável, como grids, cards, hero e paginação.

Posso colocar lógica no template?

Apenas lógica simples de apresentação. Regras de negócio, queries e decisões complexas ficam na view ou no model.

Por que evitar posts.count no template?

Porque pode disparar queries extras. Usar {% if posts %} é mais eficiente e seguro.

HTML semântico realmente ajuda no SEO?

Sim. Tags como header, section, article e títulos bem hierarquizados ajudam motores de busca e leitores de tela.

Vale a pena pensar em acessibilidade desde o início?

Sim. Acessibilidade é parte da arquitetura e evita retrabalho futuro.

Por que não hardcode URLs no HTML?

Usar {% url %} permite refatorar rotas sem quebrar templates e mantém o projeto desacoplado.

Paginação deve ficar no template principal?

Não. Ela deve ser um componente isolado para facilitar a troca por infinite scroll, HTMX ou AJAX.

Esse tipo de arquitetura é só para projetos grandes?

Não. Começar certo em projetos pequenos evita dívidas técnicas quando o sistema cresce.