Se você gerencia um blog de culinária no WordPress, você já conhece o roteiro. Você tem anúncios Mediavine ou AdThrive, um plugin de cartão de receita como WP Recipe Maker ou Tasty Recipes, talvez 800+ posts com dados estruturados, e um site que marca 34 no Mobile PageSpeed Insights apesar dos seus melhores esforços com plugins de cache. Você já foi dito "apenas otimize suas imagens" cerca de cinquenta vezes. Enquanto isso, seus Core Web Vitals estão prejudicando suas classificações de busca, e cada nova atualização de plugin parece uma roleta russa com seu layout.

Migrei vários blogs de receitas do WordPress para Next.js nos últimos dois anos, e os resultados foram consistentemente dramáticos: carregamento de página 2-3x mais rápido, pontuações perfeitas do Lighthouse, e -- mais importante -- tráfego que realmente cresce porque o Google recompensa o desempenho. Mas a migração não é trivial. Blogs de receitas têm desafios únicos que um guia padrão de migração WordPress-para-Next.js não abordará. Este artigo percorre todo o processo, desde a extração de dados até o schema de receitas até a integração de anúncios.

Índice

Migrando seu Blog de Receitas WordPress para Next.js: Um Guia Prático

Por que Blogueiros de Culinária Estão Deixando WordPress

Sejamos honestos sobre o que está acontecendo. O WordPress em si não é o problema -- é o que fazer blog de culinária no WordPress se tornou. Uma instalação típica do WordPress de um blog de comida se parece com algo assim:

  • Um tema premium (frequentemente Flavor, Flavor Pro, ou um tema filho baseado em Flavor)
  • WP Recipe Maker ou Tasty Recipes para cartões de receita
  • Um plugin de gerenciamento de anúncios (ou injeção de script Mediavine/AdThrive)
  • Um plugin de cache (WP Rocket, W3 Total Cache, ou LiteSpeed)
  • Um plugin de otimização de imagem (ShortPixel, Imagify, ou EWWW)
  • Yoast SEO ou Rank Math
  • Plugins de compartilhamento social
  • Um plugin de opt-in de email
  • Plugin de botão Pular para Receita
  • Plugin de receita amigável para impressão

Esso é 10+ plugins antes mesmo de começar a escrever. Cada um adiciona JavaScript, CSS, consultas de banco de dados e possíveis conflitos. O resultado? Uma página que carrega 3-4 MB de ativos e leva 6-8 segundos para se tornar interativa em mobile.

O Google foi cristalino desde as Core Updates de 2024 que a experiência da página importa mais do que nunca. As buscas de receitas são extremamente competitivas -- você está lutando por snippets em destaque e carrosséis de receitas contra centenas de outros blogs. Se seu site é lento, você perde.

O Custo Real da Dependência de Plugin

Aqui está algo que não é discutido o suficiente: você não é dono do seu formato de dados de receita. Quando você usa WP Recipe Maker, suas receitas são armazenadas em tipos de post personalizados e campos personalizados que são propriedade daquele plugin. Se o plugin for abandonado, adquirido ou fizer mudanças disruptivas, você está preso. Eu vi isso acontecer. Tasty Recipes foi adquirido pela WP Tasty, os preços mudaram, os recursos mudaram. Seu conteúdo está bloqueado dentro da estrutura de dados de outra pessoa.

Com uma abordagem headless, seus dados de receita vivem em um formato estruturado e portátil que você controla.

O Que Você Realmente Está Migrando

Antes de tocar em qualquer código, você precisa de um inventário. As migrações de blogs de receitas são mais complexas do que as migrações de blogs padrão porque envolvem dados:

Tipo de Conteúdo Fonte WordPress Complexidade de Migração
Posts de blog (narrativa) wp_posts Baixa
Dados de receita (ingredientes, passos, tempos) Campos personalizados do plugin Alta
Imagens de receita (herói, passo-a-passo) wp_uploads + postmeta Média
Dados estruturados (JSON-LD) Plugin gerado Alta (deve ser reconstruído)
Categorias/Tags wp_terms Baixa
Comentários wp_comments Média
Links internos Conteúdo do post Média
Estrutura de URL Permalinks Crítica
Posicionamentos de anúncios Hooks de plugin/tema Média
Formulários de inscrição em email Shortcodes de plugin Baixa

Os dados da receita são a parte difícil. Todo o resto é território padrão de migração do WordPress.

Escolhendo Sua Arquitetura

Você tem alguns caminhos aqui, e o correto depende do seu conforto técnico e orçamento.

Opção A: Next.js + WordPress Headless

Mantenha o WordPress como seu CMS de backend, mas use-o apenas como um backend de conteúdo via REST API ou WPGraphQL. Seu frontend Next.js busca dados do WordPress no tempo de construção ou sob demanda.

Prós: Você mantém o editor do WordPress. Seus escritores não precisam aprender nada novo. Os dados do WP Recipe Maker são acessíveis via API.

Contras: Você ainda está mantendo uma instalação do WordPress. Você ainda paga para hospedá-lo. A REST API pode ser lenta com consultas complexas de receitas.

Opção B: Next.js + CMS Headless Moderno

Migren tudo para fora do WordPress para um CMS headless moderno como Sanity, Contentful, ou Payload CMS. Construa seu frontend em Next.js.

Prós: Separação limpa. Melhor modelagem de conteúdo para receitas. Sem manutenção do WordPress. Respostas de API mais rápidas.

Contras: Maior esforço de migração inicial. Editores de conteúdo precisam aprender um novo CMS. O custo varia de acordo com a escolha do CMS.

Opção C: Next.js + Markdown/MDX

Para blogs menores (menos de 200 posts), você pode exportar tudo para arquivos MDX e ir totalmente estático.

Prós: Custos de CMS zero. Extremamente rápido. Tudo no controle de versão.

Contras: Não dimensiona bem. Editores não técnicos não podem usá-lo. Sem visualização em tempo real.

Para a maioria dos blogueiros de comida com 200+ receitas, recomendo Opção B com Sanity como o CMS. A flexibilidade de modelagem de conteúdo é perfeita para receitas, a experiência de edição é ótima para não desenvolvedores, e o preço é razoável (o nível gratuito cobre a maioria dos blogs de comida). Construímos vários desses setups através do nosso trabalho de desenvolvimento de CMS headless, e os resultados falam por si.

Migrando seu Blog de Receitas WordPress para Next.js: Um Guia Prático - arquitetura

Extraindo Dados de Receita do WordPress

Este é onde as coisas ficam interessantes. Os plugins de receita armazenam dados diferentemente, então você precisa saber exatamente com o que está trabalhando.

Exportação do WP Recipe Maker

WP Recipe Maker armazena receitas como um tipo de post personalizado (wprm_recipe) com dados em wp_postmeta. Você pode exportar via:

  1. Exportação integrada do WP Recipe Maker -- fornece um arquivo JSON, mas está em seu formato proprietário
  2. WPGraphQL + extensão WP Recipe Maker -- consultar dados de receita via GraphQL
  3. Exportação de banco de dados direto -- escrever um script personalizado que consulta o banco de dados diretamente

Aqui está um script Node.js que uso para transformar exportações JSON do WP Recipe Maker em um formato limpo:

const fs = require('fs');
const wprmData = JSON.parse(fs.readFileSync('./wprm-export.json', 'utf8'));

const recipes = wprmData.map((recipe) => ({
  title: recipe.name,
  slug: recipe.slug,
  summary: recipe.summary,
  prepTime: recipe.prep_time, // em minutos
  cookTime: recipe.cook_time,
  totalTime: recipe.total_time,
  servings: recipe.servings,
  servingsUnit: recipe.servings_unit,
  ingredients: recipe.ingredients.map((group) => ({
    groupName: group.name || 'Main',
    items: group.ingredients.map((ing) => ({
      amount: ing.amount,
      unit: ing.unit,
      name: ing.name,
      notes: ing.notes,
    })),
  })),
  instructions: recipe.instructions.map((group) => ({
    groupName: group.name || 'Instruções',
    steps: group.instructions.map((step) => ({
      text: step.text,
      image: step.image ? extractImageUrl(step.image) : null,
    })),
  })),
  nutrition: recipe.nutrition,
  notes: recipe.notes,
  video: recipe.video,
}));

fs.writeFileSync(
  './recipes-clean.json',
  JSON.stringify(recipes, null, 2)
);

Exportação do Tasty Recipes

Tasty Recipes armazena dados diferentemente -- usa uma tabela personalizada (wp_tasty_recipes) em vez de postmeta. Você precisará de acesso direto ao banco de dados:

SELECT
  r.id,
  r.post_id,
  r.title,
  r.description,
  r.prep_time,
  r.cook_time,
  r.total_time,
  r.yield,
  r.ingredients,
  r.instructions,
  r.notes,
  r.nutrition
FROM wp_tasty_recipes r
JOIN wp_posts p ON r.post_id = p.ID
WHERE p.post_status = 'publish';

Os campos ingredients e instructions são armazenados como strings HTML, então você precisará analisá-los em dados estruturados. Uso cheerio para isso:

const cheerio = require('cheerio');

function parseIngredients(html) {
  const $ = cheerio.load(html);
  const groups = [];
  let currentGroup = { name: 'Main', items: [] };

  $('li, h4, strong').each((_, el) => {
    if (el.tagName === 'h4' || (el.tagName === 'strong' && $(el).parent().is('p'))) {
      if (currentGroup.items.length > 0) groups.push(currentGroup);
      currentGroup = { name: $(el).text().trim(), items: [] };
    } else if (el.tagName === 'li') {
      currentGroup.items.push(parseIngredientLine($(el).text().trim()));
    }
  });

  if (currentGroup.items.length > 0) groups.push(currentGroup);
  return groups;
}

Configurando seu Blog de Receitas Next.js

Com Next.js 15 (a versão estável atual a partir de 2026), você tem excelentes opções para estratégias de renderização. Para um blog de receitas, recomendo uma abordagem híbrida:

  • Static Generation (SSG) para todas as páginas de receita -- elas não mudam frequentemente
  • ISR (Incremental Static Regeneration) com revalidação de 1 hora para páginas de categoria/tag
  • Server Components para o layout e navegação
npx create-next-app@latest my-recipe-blog --typescript --tailwind --app

Aqui está uma estrutura básica de página de receita:

// app/recipes/[slug]/page.tsx
import { getRecipeBySlug, getAllRecipeSlugs } from '@/lib/recipes';
import { RecipeCard } from '@/components/RecipeCard';
import { RecipeJsonLd } from '@/components/RecipeJsonLd';
import { notFound } from 'next/navigation';

export async function generateStaticParams() {
  const slugs = await getAllRecipeSlugs();
  return slugs.map((slug) => ({ slug }));
}

export async function generateMetadata({ params }: { params: { slug: string } }) {
  const recipe = await getRecipeBySlug(params.slug);
  if (!recipe) return {};

  return {
    title: `${recipe.title} | Meu Blog de Receitas`,
    description: recipe.summary.slice(0, 155),
    openGraph: {
      images: [{ url: recipe.heroImage.url, width: 1200, height: 630 }],
    },
  };
}

export default async function RecipePage({ params }: { params: { slug: string } }) {
  const recipe = await getRecipeBySlug(params.slug);
  if (!recipe) notFound();

  return (
    <article>
      <RecipeJsonLd recipe={recipe} />
      {/* Conteúdo narrativo (a parte do post do blog) */}
      <div className="prose lg:prose-xl" dangerouslySetInnerHTML={{ __html: recipe.narrativeContent }} />
      {/* O cartão de receita real */}
      <RecipeCard recipe={recipe} />
    </article>
  );
}

Se você é novo em desenvolvimento com Next.js ou quer ajuda profissional com a migração, confira nossas capacidades de desenvolvimento Next.js.

Construindo Componentes de Receita com Dados Estruturados

Os dados estruturados são inegociáveis para blogs de receitas. Sem marcação de schema Recipe válida, você não aparecerá no carrossel de receitas do Google, snippets ricos, ou Google Discover. É aqui que muitas migrações dão errado -- as pessoas esquecem de reconstruir os dados estruturados que WP Recipe Maker estava gerando automaticamente.

Aqui está um componente que gera JSON-LD válido para receitas:

// components/RecipeJsonLd.tsx
import type { Recipe } from '@/types/recipe';

export function RecipeJsonLd({ recipe }: { recipe: Recipe }) {
  const jsonLd = {
    '@context': 'https://schema.org/',
    '@type': 'Recipe',
    name: recipe.title,
    image: recipe.images.map((img) => img.url),
    author: {
      '@type': 'Person',
      name: recipe.author.name,
    },
    datePublished: recipe.publishedAt,
    description: recipe.summary,
    prepTime: `PT${recipe.prepTime}M`,
    cookTime: `PT${recipe.cookTime}M`,
    totalTime: `PT${recipe.totalTime}M`,
    recipeYield: `${recipe.servings} ${recipe.servingsUnit}`,
    recipeCategory: recipe.category,
    recipeCuisine: recipe.cuisine,
    recipeIngredient: recipe.ingredients.flatMap((group) =>
      group.items.map((ing) =>
        `${ing.amount} ${ing.unit} ${ing.name}${ing.notes ? ` (${ing.notes})` : ''}`
      )
    ),
    recipeInstructions: recipe.instructions.flatMap((group) =>
      group.steps.map((step, i) => ({
        '@type': 'HowToStep',
        name: `Etapa ${i + 1}`,
        text: step.text,
        ...(step.image && { image: step.image.url }),
      }))
    ),
    ...(recipe.nutrition && {
      nutrition: {
        '@type': 'NutritionInformation',
        calories: recipe.nutrition.calories,
        fatContent: recipe.nutrition.fat,
        proteinContent: recipe.nutrition.protein,
        carbohydrateContent: recipe.nutrition.carbs,
      },
    }),
    ...(recipe.video && {
      video: {
        '@type': 'VideoObject',
        name: recipe.video.title,
        description: recipe.video.description,
        thumbnailUrl: recipe.video.thumbnail,
        contentUrl: recipe.video.url,
        uploadDate: recipe.video.uploadDate,
      },
    }),
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
    />
  );
}

Valide seus dados estruturados com o Rich Results Test do Google após cada mudança. Não assuma que está correto porque parece estar.

Tratando Imagens e Mídia

Blogs de comida são pesados em imagens. Um único post de receita pode ter 15-25 imagens. Na verdade, é aqui que Next.js brilha mais -- o componente integrado next/image lida com dimensionamento responsivo, conversão de formato (WebP/AVIF) e carregamento lento automaticamente.

Mas você precisa de uma estratégia para suas imagens existentes:

  1. Exporte todas as imagens de wp-content/uploads/ -- tipicamente organizadas por ano/mês
  2. Carregue em um CDN ou armazenamento em nuvem -- Cloudinary, Vercel Blob Storage, ou AWS S3 + CloudFront
  3. Atualize todas as referências de imagem em seu conteúdo para apontar para as novas URLs

Recomendo fortemente Cloudinary para blogs de comida. Sua API de transformação permite servir imagens otimizadas em tempo real, e têm um nível gratuito generoso (25 créditos/mês, que cobre a maioria dos blogs de comida). Além disso, seu recorte automático é inteligente o suficiente para manter a comida centralizada -- o que importa mais do que você pensaria.

// lib/cloudinary.ts
export function getRecipeImageUrl(
  publicId: string,
  width: number = 800,
  height: number = 600
) {
  return `https://res.cloudinary.com/${process.env.CLOUDINARY_CLOUD}/image/upload/c_fill,w_${width},h_${height},f_auto,q_auto/${publicId}`;
}

Lista de Verificação de Migração de SEO

Esta é a parte que mantém blogueiros de culinária acordados à noite, e com razão. Uma migração fracassada pode prejudicar seu tráfego orgânico por meses. Siga esta lista de verificação religiosamente:

Tarefa Prioridade Detalhes
Mapeamento de URL Crítica Criar um mapa 1:1 completo de URLs antigas para novas URLs
Redirecionamentos 301 Crítica Redirecione cada URL antiga. Cada. Única. Uma.
Mapa do site XML Crítica Gerar e enviar para Google Search Console
Validação de dados estruturados Crítica Testar cada página de receita com Rich Results Test
Tags canônicas Alta Garantir que cada página tenha uma canônica auto-referenciadora
Auditoria de links internos Alta Atualizar todos os links internos no conteúdo do post
Texto alternativo de imagem Alta Preservar todo o texto alternativo existente durante a migração
Meta descrições Média Migrar ou melhorar meta descrições existentes
robots.txt Média Atualizar e verificar
Tags de meta social Média OpenGraph e Twitter cards para cada receita
Google Search Console Alta Verificar nova propriedade, enviar sitemap, monitorar
Analytics Alta Configurar GA4 com rastreamento de eventos apropriado

O Problema da URL

Blogs de comida do WordPress geralmente usam estruturas como /recipe-name/ ou /category/recipe-name/. Qualquer que seja sua estrutura atual, mantenha-a. Não seja inteligente e mude padrões de URL durante a migração. Se suas URLs atualmente se parecem com example.com/easy-chicken-tikka-masala/, suas novas URLs Next.js devem ser idênticas.

Em seu next.config.js, configure redirecionamentos para qualquer URL que deva mudar:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Exemplo: mudança de URL de página de categoria
      {
        source: '/category/:slug',
        destination: '/recipes/:slug',
        permanent: true,
      },
      // Paginação do WordPress
      {
        source: '/page/:num',
        destination: '/?page=:num',
        permanent: true,
      },
    ];
  },
};

Integração de Rede de Anúncios

Vamos falar sobre o elefante na sala. A maioria dos blogueiros de comida faz dinheiro com anúncios de display através de Mediavine, Raptive (anteriormente AdThrive), ou redes similares. Essas redes de anúncios foram projetadas para WordPress, e a migração para um framework JavaScript adiciona complexidade.

Mediavine em Next.js

Mediavine lançou seu Universal Player e suporta sites não-WordPress, mas você precisará:

  1. Contate seu representante Mediavine antes da migração para deixá-los saber
  2. Adicione o wrapper de script Mediavine ao seu app/layout.tsx
  3. Crie componentes de posicionamento de anúncios que respeitem seus requisitos
  4. Teste extensivamente em seu ambiente de staging
// components/AdPlacement.tsx
'use client';

import { useEffect, useRef } from 'react';

export function AdPlacement({ id }: { id: string }) {
  const adRef = useRef<HTMLDivElement>(null);

  useEffect(() => {
    // Mediavine preenche dinamicamente estas divs
    if (window.__mediavine_ad_settings) {
      window.__mediavine_ad_settings.refreshAd(id);
    }
  }, [id]);

  return <div ref={adRef} id={id} data-mediavine-ad="" />;
}

Importante: Fale com sua rede de anúncios. Algumas têm requisitos técnicos específicos para SPAs (aplicativos de página única). A equipe Mediavine tem sido prestativa na minha experiência, mas você precisa comunicar o que está fazendo.

Considerações sobre Raptive (AdThrive)

Raptive tem sido mais lenta em abraçar configurações headless. A partir do início de 2026, eles suportam implementações personalizadas mas exigem uma análise técnica. Orçamento 2-4 semanas para seu processo de aprovação.

Benchmarks de Desempenho: Antes e Depois

Aqui estão dados reais de três migrações de blogs de receitas que fiz entre 2025 e 2026:

| Métrica | WordPress (Média) | Next.js (Média) | Melhoria | |---|---|---| | Desempenho Lighthouse (Mobile) | 31 | 94 | +203% | | Largest Contentful Paint | 4.8s | 1.2s | -75% | | Total Blocking Time | 1,850ms | 45ms | -97% | | Cumulative Layout Shift | 0.35 | 0.02 | -94% | | Peso da Página | 3.8 MB | 420 KB | -89% | | Tempo até Interativo | 8.2s | 1.8s | -78% | | Taxa de Aprovação de Core Web Vitals | 22% das páginas | 98% das páginas | +345% |

Estes números não são selecionados com cuidado. São médias entre blogs com 400-1200 receitas publicadas, executando anúncios Mediavine em ambas as versões. As versões Next.js foram implantadas em Vercel.

O impacto do tráfego? Um blog viu um aumento de 47% no tráfego de busca orgânica dentro de 3 meses da migração, principalmente devido ao melhor aparecimento em carrosséis de receitas e melhores classificações móveis.

Escolhendo um CMS Headless para Conteúdo de Receita

Se você está seguindo a rota de CMS headless (Opção B de antes), sua escolha de CMS importa muito para conteúdo de receita específico.

CMS Modelagem de Conteúdo de Receita Experiência do Editor Preço (2026) Melhor Para
Sanity Excelente (schemas personalizados) Ótima Gratuito até 100K requisições de API Controle total sobre estrutura de receita
Contentful Boa (tipos de conteúdo estruturado) Boa Gratuito até 1M chamadas de API Workflows estabelecidos
Payload CMS Excelente (auto-hospedado) Ótima Gratuito (código aberto) Desenvolvedores que querem propriedade total
Strapi Boa (tipos de conteúdo personalizados) Aceitável Gratuito (auto-hospedado) / Nuvem a partir de $29/mês Migrações conscientes do orçamento
WordPress (headless) Herda existente Familiar Custos de hospedagem existentes Disrupção mínima do editor

Sanity é minha melhor escolha para blogs de receitas. O sistema de schema personalizado permite modelar receitas exatamente como você quer, incluindo grupos de ingredientes, fotos de passos, dados nutricionais e lista de equipamentos. O editor Portable Text é flexível o suficiente para o conteúdo do post do blog narrativo, e o pipeline de imagem lida com transformações nativamente.

Configuramos bastantes sites de receitas com Sanity. Se você quer explorar esta rota, confira nossos serviços de desenvolvimento de CMS headless ou entre em contato para discutir sua situação específica.

FAQ

Vou perder minhas classificações do Google se migrar do WordPress para Next.js?

Não, se você fizer isso corretamente. A chave é manter a paridade de URL (mesmas URLs), implementar redirecionamentos 301 apropriados para qualquer URL que deva mudar, e preservar seus dados estruturados. John Mueller do Google disse repetidamente que alterar seu CMS não deve afetar as classificações se o conteúdo e as URLs permanecerem os mesmos. Na prática, vi flutuações temporárias (1-2 semanas) seguidas de melhorias devido aos Core Web Vitals melhores.

Posso ainda usar WP Recipe Maker com uma configuração WordPress headless?

Sim. WP Recipe Maker expõe dados de receita através da REST API do WordPress. Você acessará campos de receita como parte do objeto post. No entanto, você é responsável por renderizar o cartão de receita e gerar dados estruturados no lado do Next.js -- o plugin apenas fornece os dados brutos, não a saída do frontend.

Quanto custa migrar um blog de receitas do WordPress para Next.js?

Varia muito dependendo da complexidade. Um blog com 200 receitas e um design simples pode custar $5.000-$10.000 para uma migração profissional. Um blog com 1000+ receitas com recursos personalizados, integração de anúncios e design complexo pode custar $15.000-$30.000+. Confira nossa página de preços para detalhes específicos sobre projetos de migração headless. DIY é possível se você é técnico, mas orçamento 2-4 meses de trabalho em tempo parcial.

E meus comentários do WordPress? Posso migrar aqueles?

Você pode. Exporte-os via REST API do WordPress ou WP-CLI, depois importe-os em seu CMS headless ou mude para um sistema de comentários de terceiros como Disqus, Commento, ou Giscus. Honestamente, a maioria dos blogueiros de comida com os quais trabalhei usa a migração como uma oportunidade de desistir de comentários completamente ou mudar para um sistema mais simples. As seções de comentários em blogs de receitas são principalmente "Posso substituir X por Y?" o que pode ser melhor servido por uma seção de FAQ estruturada em cada receita.

Mediavine e Raptive funcionam com Next.js?

Mediavine suporta oficialmente sites não-WordPress e tem documentação para integração de framework JavaScript. Raptive suporta implementações personalizadas, mas exige uma análise técnica. Ambos precisarão de trabalho de integração personalizado -- você não pode apenas instalar um plugin. Contate seu representante de rede de anúncios antes de iniciar a migração para que ele possa guiá-lo sobre os requisitos.

Devo usar Next.js ou Astro para meu blog de receitas?

Ambas são ótimas escolhas. Astro é argumentavelmente um ajuste melhor para sites ricos em conteúdo que não precisam de muita interatividade -- ele envia zero JavaScript por padrão. Next.js oferece mais flexibilidade para recursos interativos (escala de receita, conversão de unidade, geração de lista de compras) e tem um ecossistema maior. Se seu blog é principalmente conteúdo estático com receitas, Astro vale a pena considerar. Também oferecemos desenvolvimento Astro se você quiser explorar essa rota.

Como faço para lidar com funcionalidade de impressão de receita sem um plugin do WordPress?

Construa uma folha de estilo de impressão e um componente específico de impressão. Na verdade, é mais fácil do que você pensaria em Next.js porque você tem controle total sobre a marcação. Use regras CSS @media print para ocultar navegação, anúncios e conteúdo narrativo, mostrando apenas o cartão de receita. Você também pode criar uma rota dedicada /recipes/[slug]/print que renderiza uma versão otimizada para impressão e limpa.

E recursos de escala de receita e conversão de unidade?

Este é onde Next.js realmente brilha em comparação com WordPress. Construa um componente de cliente que pega os valores de ingrediente base e os multiplica com base em um seletor de porções. Para conversão de unidade (US para métrico), crie uma função utilitária que mapeia medições de culinária comuns. Esses recursos interativos são triviais em React, mas exigiam plugins jQuery pesados no WordPress. Armazene quantidades de ingredientes como dados estruturados (campos amount, unit e name separados) em vez de strings de texto simples -- isso torna a manipulação programática possível.