WordPress에서 푸드 블로그를 운영 중이라면 이미 잘 알고 있을 것입니다. Mediavine이나 AdThrive 광고, WP Recipe Maker나 Tasty Recipes 같은 레시피 카드 플러그인, 800개 이상의 게시물과 구조화된 데이터가 있는데도 모바일 PageSpeed Insights에서 34점을 받고 있습니다. 캐싱 플러그인으로 최선을 다했음에도 말이죠. "이미지만 최적화하면 된다"는 말을 약 50번은 들었을 겁니다. 한편 Core Web Vitals는 검색 순위를 떨어뜨리고 있고, 매번 플러그인 업데이트는 마치 레이아웃에 대한 도박 같습니다.

지난 2년간 WordPress에서 Next.js로 여러 레시피 블로그를 마이그레이션했으며, 결과는 매우 극적이었습니다. 페이지 로드 속도가 2~3배 빨라졌고, Lighthouse 점수가 완벽했으며, 가장 중요하게도 Google이 성능을 보상하기 때문에 실제로 증가하는 트래픽을 얻었습니다. 하지만 마이그레이션은 간단하지 않습니다. 레시피 블로그는 표준 WordPress에서 Next.js로의 마이그레이션 가이드에서 다루지 않는 독특한 과제들이 있습니다. 이 글에서는 데이터 추출부터 레시피 스키마, 광고 통합까지 전체 프로세스를 설명합니다.

목차

WordPress 레시피 블로그를 Next.js로 마이그레이션: 실전 가이드

왜 푸드 블로거들이 WordPress를 떠나고 있는가

솔직히 말하자면 WordPress 자체가 문제가 아닙니다. WordPress에서 레시피 블로깅이 어떻게 변했는지가 문제입니다. 일반적인 푸드 블로그 WordPress 설치는 다음과 같습니다:

  • 프리미엄 테마 (보통 Flavor, Flavor Pro, 또는 Flavor 기반 자식 테마)
  • 레시피 카드용 WP Recipe Maker 또는 Tasty Recipes
  • 광고 관리 플러그인 (또는 Mediavine/AdThrive 스크립트 주입)
  • 캐싱 플러그인 (WP Rocket, W3 Total Cache, 또는 LiteSpeed)
  • 이미지 최적화 플러그인 (ShortPixel, Imagify, 또는 EWWW)
  • Yoast SEO 또는 Rank Math
  • 소셜 공유 플러그인
  • 이메일 옵트인 플러그인
  • 점프-투-레시피 버튼 플러그인
  • 인쇄 친화적 레시피 플러그인

글을 쓰기도 전에 이미 10개 이상의 플러그인이 있습니다. 각각은 JavaScript, CSS, 데이터베이스 쿼리, 그리고 잠재적 충돌을 추가합니다. 결과적으로 모바일에서 34MB의 자산을 로드하고 상호작용까지 68초가 걸리는 페이지가 됩니다.

Google은 2024년 Core Updates 이후 페이지 경험이 그 어느 때보다 중요하다고 명확히 했습니다. 레시피 검색은 매우 경쟁이 심합니다. 수백 개의 다른 블로그를 상대로 특별 스니펫과 레시피 캐러셀을 놓고 경쟁하고 있습니다. 사이트가 느리면 진출합니다.

플러그인 의존성의 실제 비용

충분히 논의되지 않는 부분이 있습니다. 당신은 레시피 데이터 형식을 소유하지 않습니다. WP Recipe Maker를 사용하면 레시피는 해당 플러그인에만 적용되는 커스텀 포스트 타입과 커스텀 필드에 저장됩니다. 플러그인이 중단되거나 인수되거나 주요 변경이 있으면 당신은 진출합니다. 이런 일이 일어났습니다. Tasty Recipes는 WP Tasty에 인수되었고, 가격이 변경되었으며, 기능이 변경되었습니다. 당신의 콘텐츠는 다른 사람의 데이터 구조 안에 갇혀 있습니다.

Headless 접근 방식을 사용하면 레시피 데이터는 당신이 제어하는 구조적이고 이식 가능한 형식으로 존재합니다.

실제로 마이그레이션해야 할 것

코드를 건드리기 전에 인벤토리가 필요합니다. 레시피 블로그 마이그레이션은 포함된 데이터 때문에 표준 블로그 마이그레이션보다 더 복잡합니다:

콘텐츠 타입 WordPress 소스 마이그레이션 복잡도
블로그 게시물 (본문) wp_posts 낮음
레시피 데이터 (재료, 단계, 시간) 플러그인 커스텀 필드 높음
레시피 이미지 (대표, 단계별) wp_uploads + postmeta 중간
구조화된 데이터 (JSON-LD) 플러그인 생성 높음 (재구축 필요)
카테고리/태그 wp_terms 낮음
댓글 wp_comments 중간
내부 링크 게시물 콘텐츠 중간
URL 구조 퍼머링크 중요
광고 배치 플러그인/테마 훅 중간
이메일 가입 양식 플러그인 숏코드 낮음

레시피 데이터가 어려운 부분입니다. 그 외 모든 것은 표준 WordPress 마이그레이션 영역입니다.

아키텍처 선택하기

몇 가지 경로가 있으며, 올바른 경로는 기술 수준과 예산에 따라 다릅니다.

옵션 A: Next.js + Headless WordPress

WordPress를 순수 콘텐츠 백엔드로 유지하되 REST API 또는 WPGraphQL을 통해 사용합니다. Next.js 프론트엔드는 빌드 시간이나 요청 시 WordPress에서 데이터를 가져옵니다.

장점: WordPress 에디터를 유지합니다. 작가들이 새로운 것을 배울 필요가 없습니다. WP Recipe Maker 데이터는 API를 통해 접근 가능합니다.

단점: 여전히 WordPress 설치를 유지해야 합니다. 여전히 호스팅 비용을 지불합니다. REST API는 복잡한 레시피 쿼리에서 느릴 수 있습니다.

옵션 B: Next.js + 현대식 Headless CMS

WordPress에서 모든 것을 Sanity, Contentful, 또는 Payload CMS 같은 목적별 headless CMS로 마이그레이션합니다. Next.js에서 프론트엔드를 구축합니다.

장점: 깔끔한 단절. 레시피를 위한 더 나은 콘텐츠 모델링. WordPress 유지보수 필요 없음. 더 빠른 API 응답.

단점: 더 큰 초기 마이그레이션 작업. 콘텐츠 편집자들이 새로운 CMS를 배워야 함. CMS 선택에 따라 비용이 다름.

옵션 C: Next.js + Markdown/MDX

더 작은 블로그 (200개 미만의 게시물)의 경우 모든 것을 MDX 파일로 내보내고 완전히 정적이 될 수 있습니다.

장점: CMS 비용 없음. 매우 빠름. 모든 것이 버전 제어에 있음.

단점: 잘 확장되지 않음. 기술적이지 않은 편집자는 사용할 수 없음. 실시간 미리보기 없음.

200개 이상의 레시피가 있는 대부분의 푸드 블로거의 경우 옵션 B와 Sanity를 CMS로 권장합니다. 콘텐츠 모델링 유연성은 레시피에 완벽하고, 편집 경험은 개발자가 아닌 사람들을 위해 훌륭하며, 가격은 합리적입니다 (대부분의 푸드 블로그를 커버하는 무료 티어). 우리는 headless CMS 개발 작업을 통해 여러 설정을 구축했으며, 결과는 스스로를 말합니다.

WordPress 레시피 블로그를 Next.js로 마이그레이션: 실전 가이드 - 아키텍처

WordPress에서 레시피 데이터 추출하기

이제 흥미로운 부분이 시작됩니다. 레시피 플러그인은 데이터를 다르게 저장하므로 정확히 무엇을 작업하고 있는지 알아야 합니다.

WP Recipe Maker 내보내기

WP Recipe Maker는 레시피를 커스텀 포스트 타입 (wprm_recipe)으로 저장하고 데이터는 wp_postmeta에 저장합니다. 다음을 통해 내보낼 수 있습니다:

  1. WP Recipe Maker의 내장 내보내기 -- JSON 파일을 제공하지만 독점 형식입니다
  2. WPGraphQL + WP Recipe Maker 확장 -- GraphQL을 통해 레시피 데이터 쿼리
  3. 직접 데이터베이스 내보내기 -- 데이터베이스를 직접 쿼리하는 커스텀 스크립트 작성

WP Recipe Maker JSON 내보내기를 깔끔한 형식으로 변환하는 Node.js 스크립트입니다:

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, // 분 단위
  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 || 'Instructions',
    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)
);

Tasty Recipes 내보내기

Tasty Recipes는 다르게 저장합니다. postmeta 대신 커스텀 테이블 (wp_tasty_recipes)을 사용합니다. 직접 데이터베이스 접근이 필요합니다:

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';

ingredients와 instructions 필드는 HTML 문자열로 저장되므로 구조화된 데이터로 분석해야 합니다. 이를 위해 cheerio를 사용합니다:

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;
}

Next.js 레시피 블로그 설정하기

Next.js 15 (2026년 현재 안정적인 릴리스)를 사용하면 렌더링 전략에 탁월한 옵션이 있습니다. 레시피 블로그의 경우 하이브리드 접근 방식을 권장합니다:

  • 정적 생성 (SSG) - 모든 레시피 페이지용 (자주 변경되지 않음)
  • ISR (Incremental Static Regeneration) - 1시간 재검증으로 카테고리/태그 페이지용
  • Server Components - 레이아웃과 네비게이션용
npx create-next-app@latest my-recipe-blog --typescript --tailwind --app

기본 레시피 페이지 구조:

// 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} | My Recipe Blog`,
    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} />
      {/* 본문 콘텐츠 (블로그 게시물 부분) */}
      <div className="prose lg:prose-xl" dangerouslySetInnerHTML={{ __html: recipe.narrativeContent }} />
      {/* 실제 레시피 카드 */}
      <RecipeCard recipe={recipe} />
    </article>
  );
}

Next.js 개발이 처음이거나 마이그레이션에 대한 전문가의 도움을 원하면 Next.js 개발 기능을 확인해보세요.

구조화된 데이터를 포함한 레시피 컴포넌트 구축

구조화된 데이터는 레시피 블로그에서 필수입니다. 유효한 Recipe 스키마 마크업이 없으면 Google의 레시피 캐러셀, 리치 스니펫 또는 Google Discover에 나타나지 않습니다. 마이그레이션이 잘못되는 많은 이유입니다. 사람들이 WP Recipe Maker가 자동으로 생성하던 구조화된 데이터를 재구축하는 것을 잊기 때문입니다.

레시피에 대해 유효한 JSON-LD를 생성하는 컴포넌트입니다:

// 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: `Step ${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) }}
    />
  );
}

매번 변경 후 Google의 Rich Results 테스트를 사용하여 구조화된 데이터를 검증합니다. 올바르게 보인다고 해서 올바르다고 가정하지 마세요.

이미지 및 미디어 처리

푸드 블로그는 이미지가 많습니다. 단일 레시피 게시물에 15~25개의 이미지가 있을 수 있습니다. 실제로 이것이 Next.js가 가장 뛰어나게 빛나는 부분입니다. 기본 제공 next/image 컴포넌트는 반응형 크기 조정, 형식 변환 (WebP/AVIF), 그리고 지연 로딩을 자동으로 처리합니다.

하지만 기존 이미지에 대한 전략이 필요합니다:

  1. wp-content/uploads/에서 모든 이미지 내보내기 -- 일반적으로 연도/월로 조직됨
  2. CDN 또는 클라우드 저장소로 업로드 -- Cloudinary, Vercel Blob Storage, 또는 AWS S3 + CloudFront
  3. 콘텐츠의 모든 이미지 참조 업데이트 새 URL을 가리키도록

푸드 블로그의 경우 Cloudinary를 강력히 권장합니다. 변환 API를 사용하면 즉시 최적화된 이미지를 제공할 수 있으며, 무료 티어가 관대합니다 (월 25크레딧, 대부분의 푸드 블로그를 커버). 게다가 자동 자르기는 음식을 중앙에 유지하기에 충분히 지능적입니다. 당신이 생각하는 것보다 더 중요합니다.

// 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}`;
}

SEO 마이그레이션 체크리스트

이것은 푸드 블로거들을 밤에 깨우는 부분이며 당연합니다. 엉망이 된 마이그레이션은 수개월 동안 유기 트래픽을 떨어뜨릴 수 있습니다. 이 체크리스트를 종교처럼 따르세요:

작업 우선순위 세부사항
URL 매핑 중요 이전 URL과 새 URL의 완전한 1:1 맵 작성
301 리디렉션 중요 모든 이전 URL을 리디렉션. 모든. 단일. 것.
XML 사이트맵 중요 생성 및 Google Search Console에 제출
구조화된 데이터 검증 중요 Rich Results 테스트로 모든 레시피 페이지 테스트
정규화 태그 높음 모든 페이지에 자체 참조 정규화가 있는지 확인
내부 링크 감사 높음 게시물 콘텐츠의 모든 내부 링크 업데이트
이미지 alt 텍스트 높음 마이그레이션 중 모든 기존 alt 텍스트 유지
메타 설명 중간 기존 메타 설명 마이그레이션 또는 개선
robots.txt 중간 업데이트 및 검증
소셜 메타 태그 중간 모든 레시피의 OpenGraph 및 Twitter 카드
Google Search Console 높음 새 속성 확인, 사이트맵 제출, 모니터링
분석 높음 적절한 이벤트 추적을 사용하여 GA4 설정

URL 문제

WordPress 푸드 블로그는 일반적으로 /recipe-name/ 또는 /category/recipe-name/ 같은 구조를 사용합니다. 현재 구조가 무엇이든 유지하세요. 마이그레이션 중에 URL 패턴을 변경하지 마세요. 현재 URL이 example.com/easy-chicken-tikka-masala/ 같으면, 새 Next.js URL도 동일해야 합니다.

변경해야 할 URL이 있으면 next.config.js에서 리디렉션을 설정합니다:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // 예제: 카테고리 페이지 URL 변경
      {
        source: '/category/:slug',
        destination: '/recipes/:slug',
        permanent: true,
      },
      // WordPress 페이지네이션
      {
        source: '/page/:num',
        destination: '/?page=:num',
        permanent: true,
      },
    ];
  },
};

광고 네트워크 통합

이제 방 안의 코끼리를 말해봅시다. 대부분의 푸드 블로거는 Mediavine, Raptive (이전 AdThrive), 또는 유사한 네트워크를 통한 디스플레이 광고로 돈을 벌고 있습니다. 이 광고 네트워크는 WordPress를 위해 설계되었고, JavaScript 프레임워크로 마이그레이션하면 복잡성이 추가됩니다.

Next.js에서 Mediavine

Mediavine은 Universal Player를 출시했으며 WordPress가 아닌 사이트를 지원하지만, 다음이 필요합니다:

  1. 마이그레이션 전에 Mediavine 담당자에게 연락하여 알림
  2. Mediavine 스크립트 래퍼를 app/layout.tsx에 추가
  3. 요구사항을 준수하는 광고 배치 컴포넌트 생성
  4. 준비 환경에서 철저히 테스트
// components/AdPlacement.tsx
'use client';

import { useEffect, useRef } from 'react';

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

  useEffect(() => {
    // Mediavine이 이러한 div를 동적으로 채움
    if (window.__mediavine_ad_settings) {
      window.__mediavine_ad_settings.refreshAd(id);
    }
  }, [id]);

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

중요: 광고 네트워크에 연락하세요. 일부는 SPA (싱글 페이지 애플리케이션)에 대한 특정 기술 요구사항이 있습니다. 제 경험상 Mediavine 팀은 도움이 되었지만 무엇을 하는지 소통해야 합니다.

Raptive (AdThrive) 고려사항

Raptive는 headless 설정을 수용하는 데 있어 더 느립니다. 2026년 초 현재, 커스텀 구현을 지원하지만 기술 검토가 필요합니다. 승인 프로세스에 2~4주를 예상하세요.

성능 벤치마크: 마이그레이션 전후

2025년과 2026년 사이 작업한 세 개의 레시피 블로그 마이그레이션의 실제 데이터입니다:

메트릭 WordPress (평균) Next.js (평균) 개선
Lighthouse 성능 (모바일) 31 94 +203%
Largest Contentful Paint 4.8초 1.2초 -75%
Total Blocking Time 1,850ms 45ms -97%
Cumulative Layout Shift 0.35 0.02 -94%
페이지 가중치 3.8 MB 420 KB -89%
Time to Interactive 8.2초 1.8초 -78%
Core Web Vitals 통과율 22% 페이지 98% 페이지 +345%

이 숫자는 선택적이 아닙니다. 400~1200개의 게시된 레시피가 있는 블로그, 양쪽 버전에서 Mediavine 광고를 실행하는 블로그의 평균입니다. Next.js 버전은 Vercel에 배포되었습니다.

트래픽 영향은? 한 블로그는 마이그레이션 후 3개월 내에 유기 검색 트래픽이 47% 증가했으며, 주로 개선된 레시피 캐러셀 출현과 더 나은 모바일 순위로 인한 것입니다.

레시피 콘텐츠를 위한 Headless CMS 선택

Headless CMS 경로 (앞서 옵션 B)를 선택하면 CMS 선택이 레시피 콘텐츠 특히 중요합니다.

CMS 레시피 콘텐츠 모델링 편집자 경험 가격 (2026) 최고의 용도
Sanity 우수 (커스텀 스키마) 훌륭함 100K API 요청까지 무료 레시피 구조에 대한 완전한 제어
Contentful 좋음 (구조화된 콘텐츠 타입) 좋음 1M API 호출까지 무료 확립된 워크플로
Payload CMS 우수 (자체 호스팅) 훌륭함 무료 (오픈 소스) 완전한 소유권을 원하는 개발자
Strapi 좋음 (커스텀 콘텐츠 타입) 괜찮음 무료 (자체 호스팅) / 클라우드 $29/월부터 예산 의식 마이그레이션
WordPress (headless) 기존 상속 친숙함 기존 호스팅 비용 최소한의 편집자 중단

Sanity는 레시피 블로그의 최고 선택입니다. 커스텀 스키마 시스템을 사용하면 레시피를 원하는 방식으로 모델링할 수 있습니다. 재료 그룹, 단계 사진, 영양 데이터, 장비 목록 포함. Portable Text 편집기는 본문 블로그 게시물 콘텐츠에 충분히 유연하고, 이미지 파이프라인은 변환을 기본적으로 처리합니다.

우리는 상당히 많은 Sanity 기반 레시피 사이트를 설정했습니다. 이 경로를 탐색하고 싶으면 headless CMS 개발 서비스를 확인하거나 특정 상황을 논의하기 위해 연락하세요.

FAQ

WordPress에서 Next.js로 마이그레이션하면 Google 순위를 잃을까요?

제대로 하면 아닙니다. 핵심은 URL 동등성을 유지하는 것입니다 (URL 동일). 변경해야 할 URL의 경우 적절한 301 리디렉션을 구현하고 구조화된 데이터를 유지합니다. Google의 John Mueller는 반복해서 CMS 변경이 콘텐츠와 URL이 동일하면 순위에 영향을 주지 않아야 한다고 말했습니다. 실제로는 임시 변동 (1~2주) 후 Core Web Vitals 개선으로 인한 향상을 보았습니다.

Headless WordPress 설정에서 WP Recipe Maker를 사용할 수 있습니까?

네. WP Recipe Maker는 WordPress REST API를 통해 레시피 데이터를 노출합니다. 게시물 객체의 일부로 레시피 필드에 접근합니다. 그러나 레시피 카드를 렌더링하고 구조화된 데이터를 생성하는 것은 Next.js 쪽에서 당신의 책임입니다. 플러그인은 원시 데이터만 제공하고 프론트엔드 출력은 제공하지 않습니다.

WordPress에서 Next.js로 레시피 블로그를 마이그레이션하는 데 비용이 얼마나 들까요?

복잡성에 따라 크게 다릅니다. 간단한 디자인의 200개 레시피 블로그는 $5,000~$10,000 정도일 수 있습니다. 1000개 이상의 레시피, 커스텀 기능, 광고 통합, 복잡한 디자인의 블로그는 $15,000~$30,000+ 달성할 수 있습니다. 가격 페이지에서 headless 마이그레이션 프로젝트의 구체적인 내용을 확인하세요. DIY는 기술적이면 가능하지만 파트타임으로 2~4개월을 예상하세요.

WordPress 댓글은 어떻게 되나요? 마이그레이션할 수 있습니까?

WP-CLI 또는 WordPress REST API를 통해 내보낼 수 있습니다. 그런 다음 headless CMS로 가져오거나 Disqus, Commento, 또는 Giscus 같은 타사 댓글 시스템으로 전환합니다. 솔직히, 마이그레이션을 기회로 활용하여 댓글을 완전히 제거하거나 더 간단한 시스템으로 전환하는 푸드 블로거가 많습니다. 레시피 블로그의 댓글 섹션은 주로 "X를 Y로 대체할 수 있을까요?"인데, 이것은 각 레시피의 구조화된 FAQ 섹션으로 더 잘 제공될 수 있습니다.

Mediavine과 Raptive는 Next.js에서 작동합니까?

Mediavine은 공식적으로 WordPress가 아닌 사이트를 지원하며 JavaScript 프레임워크 통합에 대한 문서가 있습니다. Raptive는 커스텀 구현을 지원하지만 기술 검토가 필요합니다. 둘 다 플러그인을 설치하기만 하면 되는 것이 아닙니다. 마이그레이션 시작 전에 광고 네트워크 담당자에게 연락하여 요구사항을 안내받으세요.

레시피 블로그에는 Next.js 또는 Astro를 사용해야 할까요?

둘 다 훌륭한 선택입니다. Astro는 상호작용이 많지 않은 콘텐츠 중심 사이트에 주장할 수 있는 더 나은 선택입니다. 기본적으로 JavaScript를 전혀 제공하지 않습니다. Next.js는 대화형 기능 (레시피 스케일링, 단위 변환, 쇼핑 목록 생성)에 더 많은 유연성을 제공하며 더 큰 생태계를 가지고 있습니다. 블로그가 주로 정적 콘텐츠이고 레시피라면 Astro를 고려할 가치가 있습니다. 우리는 또한 해당 경로를 탐색하고 싶으면 Astro 개발을 제공합니다.

WordPress 플러그인 없이 레시피 인쇄 기능을 어떻게 처리합니까?

인쇄 스타일시트와 인쇄 특정 컴포넌트를 구축합니다. Next.js에서 마크업을 완전히 제어할 수 있기 때문에 실제로는 WordPress보다 훨씬 쉽습니다. CSS @media print 규칙을 사용하여 네비게이션, 광고, 본문 콘텐츠를 숨기고 레시피 카드만 표시합니다. 깔끔한 인쇄 최적화 버전을 렌더링하는 전용 /recipes/[slug]/print 경로를 만들 수도 있습니다.

레시피 스케일링 및 단위 변환 기능은 어떻게 되나요?

Next.js가 WordPress와 비교하여 정말 빛나는 곳입니다. 서빙 선택자를 기준으로 기본 재료 양에 곱하는 클라이언트 컴포넌트를 구축합니다. 단위 변환 (미국에서 미터법)의 경우 일반적인 요리 측정값을 매핑하는 유틸리티 함수를 만듭니다. 이러한 대화형 기능은 React에서 간단하지만 WordPress에서 필요한 무거운 jQuery 플러그인입니다. 재료 양을 구조화된 데이터로 저장합니다 (별도 amount, unit, name 필드) 일반 텍스트 문자열이 아니라 프로그래밍 방식의 조작을 가능하게 합니다.