Um cliente me pediu pra separar “depoimentos” dos posts normais do blog dele, sem misturar tudo na mesma listagem. A resposta certa quase sempre é criar um Custom Post Type (CPT) — um tipo de conteúdo próprio, com sua própria tela de cadastro, seus próprios campos e sua própria URL, sem depender da categoria “post” padrão do WordPress. Depoimentos, portfólio, produtos, imóveis, cases de sucesso: qualquer coisa que se repete com uma estrutura parecida é candidata a virar um CPT.
Tem duas formas de fazer isso: escrevendo código no functions.php (ou, melhor ainda, num plugin próprio do site) ou usando um plugin pronto tipo o Custom Post Type UI. Vou mostrar as duas, porque cada uma serve pra um cenário diferente.
Antes de tudo: por que não editar direto o functions.php do tema
Isso é chato de admitir, mas já perdi um CPT inteiro porque atualizei o tema e o WordPress substituiu o arquivo. Se o seu tema não for um tema-filho (child theme), qualquer código que você colocar no functions.php some na próxima atualização. A prática mais segura é criar um plugin bem simples, só com esse código, e ativar ele separado do tema. Isso não muda em nada o resultado final — o post type aparece no menu do mesmo jeito — mas garante que ele sobrevive a uma troca de tema ou atualização.
Se for só um teste rápido em ambiente local, tudo bem colocar no functions.php mesmo. Em produção, evite.
Método 1: registrando o Post Type via código
Esse é o código base pra registrar um post type de “Serviços”, por exemplo:
function post_type_servicos() {
register_post_type( 'servicos', array(
'labels' => array(
'name' => __( 'Serviços' ),
'singular_name' => __( 'Serviço' ),
),
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => true,
'rewrite' => array( 'slug' => 'servicos' ),
'capability_type' => 'post',
'has_archive' => true,
'hierarchical' => false,
'menu_icon' => 'dashicons-admin-multisite',
'menu_position' => 5,
'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt' ),
) );
}
add_action( 'init', 'post_type_servicos' );Uma pegadinha boba que já me pegou: se você copiar código de um site, do Word ou até do próprio editor visual do WordPress, as aspas retas podem virar aspas curvas sem você perceber. O PHP não entende aspas curvas como delimitador de string e você recebe um erro de sintaxe inesperado — tela branca, site fora do ar. Sempre cole o código num editor de texto puro (Notepad++, VS Code) antes de subir pro servidor, nunca direto do navegador ou de um Word.
Depois de salvar, entre em Configurações → Links Permanentes e clique em “Salvar alterações” sem mudar nada. Isso força o WordPress a atualizar as regras de rewrite — sem esse passo, é comum a página do novo post type dar 404 mesmo com tudo certo no código.
Adicionando uma taxonomia própria (opcional, mas útil)
Se além do post type você quiser categorias específicas pra ele (tipo “Categoria de Serviço”, separada das categorias do blog), registre uma taxonomia customizada junto:
function taxonomia_servicos() {
register_taxonomy( 'categoria_servico', 'servicos', array(
'label' => 'Categoria de Serviço',
'rewrite' => array( 'slug' => 'categoria-servico' ),
'hierarchical' => true,
) );
}
add_action( 'init', 'taxonomia_servicos' );Isso evita o erro comum de tentar reaproveitar a taxonomia “category” padrão pra um conteúdo que não tem nada a ver com os posts do blog.
Método 2: usando um plugin (mais rápido, sem tocar em código)
Se você não quer mexer com PHP, o Custom Post Type UI (gratuito, no repositório oficial) faz a mesma coisa por uma tela de configuração: você define o nome, o slug, o ícone e o que o post type suporta, sem escrever uma linha de código. A desvantagem é que ele fica registrado por um plugin de terceiros — se você desativar o plugin, os posts continuam no banco de dados, mas somem da interface até reativar. Pra sites simples ou pra quem edita bastante direto no wp-admin sem mexer em código, é a opção mais tranquila.
Sites que já usam algum plugin de tipos de conteúdo (como o CPO Content Types, comum em temas da SiteOrigin) também costumam ter uma tela parecida — vale checar em Plugins se já existe algo assim instalado antes de adicionar mais um.
Erros comuns depois de criar o Post Type
Uma lista rápida do que costuma dar errado:
- Post type não aparece no menu: geralmente é
show_uioupubliccomo false, ou o hookinitnão foi chamado corretamente. - URL do post type dá 404: falta salvar os links permanentes de novo (o passo que mencionei acima).
- Conflito de slug: se o slug escolhido já é usado por uma página ou por outro post type, o WordPress prioriza um dos dois e o outro quebra silenciosamente. Escolha slugs únicos.
- Post type some depois de atualizar o tema: sinal de que o código estava no functions.php do tema-pai, não num plugin — volte ao primeiro tópico deste post.
Perguntas frequentes
Preciso de um post type pra tudo que for diferente de “post”?
Não necessariamente. Se for só uma forma diferente de organizar posts (por assunto, por autor), uma categoria ou taxonomia resolve. Post type novo faz mais sentido quando o conteúdo tem uma estrutura de dados própria — campos diferentes, página de exibição diferente.
Dá pra usar Custom Post Type com Elementor ou page builders?
Sim, a maioria dos construtores de página modernos reconhece post types customizados sem configuração extra, desde que show_in_rest esteja como true no registro (necessário também pro editor de blocos nativo).
Preciso de plugin pra ter campos personalizados no post type?
Pra campos simples, o WordPress já tem “custom fields” nativos. Pra formulários mais elaborados (imagem, texto, seletor), o Advanced Custom Fields (ACF) é o padrão de mercado.
Se você mexe com WordPress no dia a dia, vale complementar isso com um guia de criação de widgets para Elementor — os dois assuntos costumam andar juntos em projetos de sites customizados. E se o objetivo final for montar uma loja ou catálogo usando esse post type, dá uma olhada em como criar uma loja virtual com WordPress.
