WordPress에서 Astro로 마이그레이션 가이드: 2026년 7단계
Astro는 2026년 콘텐츠 중심 사이트를 위한 최고의 WordPress 대체제입니다 -- 블로그, 문서, 마케팅 페이지. 기본적으로 JavaScript를 전혀 제공하지 않으며 Core Web Vitals에서 WordPress를 60-80포인트 능가합니다. 저는 지난 2년간 WordPress 사이트 12곳을 Astro로 마이그레이션했으며, 50개 게시물의 개인 블로그부터 3,000페이지의 문서 포털까지 범위가 다양합니다. 결과는 일관되게 극적입니다: 1초 미만의 로드 시간, Lighthouse 점수 95 이상, 월 $99에서 실질적으로 0으로 떨어진 호스팅 비용.
이것은 "XML을 내보내고 기도하는" 가이드가 아닙니다. 저는 제가 사용하는 정확한 프로세스를 안내하겠으며, 계획하지 않으면 문제가 될 수 있는 함정들도 포함합니다 -- 끊긴 URL, 누락된 이미지, 고아 숏코드, 모두를 혼동하게 하는 댓글 시스템 질문들.
목차
- WordPress 대신 Astro를 사용하는 이유
- WordPress 마이그레이션을 위한 Astro vs Next.js vs Gatsby
- 7단계 마이그레이션 플레이북
- WordPress 데이터 내보내기에서 Astro 콘텐츠 컬렉션으로
- SEO 보존: 301 리다이렉트, 사이트맵 및 스키마
- 호스팅 비용 비교
- FAQ
WordPress 대신 Astro를 사용하는 이유
WordPress는 대부분의 콘텐츠 사이트에 과도하게 엔지니어링되어 있습니다. PHP, MySQL, 웹 서버, 캐싱 레이어, 기본적으로 정적 콘텐츠를 제공하기 위해 거의 12개의 플러그인을 실행하고 있습니다. 모든 페이지 로드는 데이터베이스에 접근합니다. 모든 플러그인은 잠재적인 보안 허점입니다. 모든 업데이트는 아무것도 망가지지 않기를 바라는 기도입니다.
Astro는 이 모델을 뒤집습니다. 빌드 시간에 페이지를 정적 HTML로 사전 렌더링합니다. 데이터베이스가 없습니다. 서버 측 런타임이 없습니다. PHP가 없습니다. 출력은 순수 HTML, CSS, 그리고 -- 명시적으로 선택할 때만 -- JavaScript입니다.
마이그레이션 전반에서 일관되게 보는 것은 다음과 같습니다:
| 지표 | WordPress (관리형) | Astro (정적) | 개선 |
|---|---|---|---|
| Lighthouse 성능 | 34-55 | 95-100 | +60-80포인트 |
| First Contentful Paint | 2.8-4.2s | 0.4-0.8s | ~80% 더 빠름 |
| Total Blocking Time | 200-800ms | 0-10ms | ~98% 감소 |
| 페이지 크기 (일반적인 블로그 게시물) | 1.5-3.5 MB | 80-250 KB | ~90% 더 작음 |
| Time to Interactive | 4-8s | 0.5-1.0s | ~85% 더 빠름 |
| HTTP 요청 | 60-130 | 8-15 | ~85% 감소 |
이것들은 선별된 것이 아닙니다. 실제 마이그레이션의 평균입니다. 캐싱 플러그인과 CDN을 사용하는 WordPress 사이트도 정적 Astro 빌드에 도달할 수 없습니다. 요청당 근본적으로 더 많은 작업을 하고 있기 때문입니다.
보안 관점
WordPress는 인터넷에서 가장 많이 공격받는 CMS입니다. 나쁜 이유가 아니라 어디에나 있고 거대한 공격 표면을 가지고 있기 때문입니다 -- PHP 실행, 데이터베이스 접근, 파일 업로드, XML-RPC, REST API 엔드포인트, 관리자 로그인 페이지. 매달 새로운 플러그인 취약점이 나타납니다.
CDN에 배포된 Astro 사이트는 기본적으로 공격 표면이 거의 없습니다. 악용할 서버가 없고, 무차별 대입할 관리자 패널이 없고, SQL 주입할 데이터베이스가 없습니다. 당신의 사이트는 전역 엣지 네트워크에 앉아있는 HTML 파일 폴더입니다.
개발자 경험
WordPress 테마를 커스터마이징해본 적이 있다면 고통을 알고 있습니다: HTML과 혼합된 PHP 템플릿 태그, 암기가 필요한 템플릿 계층 구조, 관리할 수 없는 괴물로 자라나는 functions.php 파일, 끊임없는 플러그인 충돌.
Astro는 HTML에 초강력 기능을 제공하는 파일 형식의 컴포넌트 기반 아키텍처를 사용합니다. Astro 페이지 내에서 React, Vue, Svelte 또는 Solid 컴포넌트를 사용할 수 있습니다 -- 하지만 실제로 상호작용이 필요할 때만 사용합니다. 블로그나 마케팅 사이트의 경우 아마도 필요하지 않을 것입니다.
---
// src/pages/blog/[...slug].astro
import { getCollection } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';
export async function getStaticPaths() {
const posts = await getCollection('blog');
return posts.map(post => ({
params: { slug: post.slug },
props: { post },
}));
}
const { post } = Astro.props;
const { Content } = await post.render();
---
<BlogLayout title={post.data.title} description={post.data.excerpt}>
<article>
<h1>{post.data.title}</h1>
<time datetime={post.data.date.toISOString()}>
{post.data.date.toLocaleDateString()}
</time>
<Content />
</article>
</BlogLayout>
그것이 완전한 동적 블로그 게시물 페이지입니다. WordPress에서 같은 명확성으로 해보십시오.
WordPress 마이그레이션을 위한 Astro vs Next.js vs Gatsby
Astro
Astro는 콘텐츠 사이트를 위해 목적에 맞게 만들어졌습니다. "아일랜드 아키텍처"는 특정 컴포넌트에 필요한 경우를 제외하고 JavaScript를 제공하지 않는다는 의미입니다. 콘텐츠 컬렉션은 내장 스키마 검증을 포함한 타입-안전 마크다운 처리를 제공합니다. 빌드 시간이 빠르고, 정신 모델이 간단하며, React를 이해할 필요가 없습니다. 블로그, 문서, 마케팅 사이트의 경우 2026년에 명백한 선택입니다. 이 경로를 탐색하고 있다면, 저희 Astro 개발 팀은 모든 규모의 마이그레이션을 처리했습니다.
Next.js
Next.js는 전체 애플리케이션 프레임워크입니다. 인증, 서버 측 렌더링, API 경로, 미들웨어, 그리고 블로그에 필요하지 않은 100가지 다른 것들을 처리합니다. 상호작용이 필요한지 여부와 관계없이 모든 방문자에게 React 런타임을 제공할 것입니다 (App Router의 서버 컴포넌트가 도움이 되지만, 기본 번들은 여전히 더 무겁습니다). Next.js는 SaaS 제품을 구축하거나 무거운 동적 기능이 있는 사이트 -- 사용자 대시보드, 전자상거래, 실시간 기능 -- 을 구축할 때 의미가 있습니다. WordPress에서 콘텐츠를 마이그레이션하는 경우? 과도합니다. 즉, 당신의 사이트 가 그런 기능이 필요한 경우, 저희 Next.js 팀이 올바른 아키텍처를 파악하는 데 도움을 줄 수 있습니다.
Gatsby
Gatsby는 기본적으로 유지보수 모드에 있습니다. Netlify가 2023년에 인수했고, 개발이 느려졌습니다. 한때 영리해 보였던 GraphQL 데이터 레이어는 이제 불필요한 복잡성처럼 느껴집니다. 큰 사이트의 빌드 시간은 고통스럽습니다. 플러그인 생태계는 오래되었습니다. 2026년에는 새로운 Gatsby 프로젝트를 시작하지 않도록 강력히 권장합니다. 현재 Gatsby를 사용 중이라면, Astro로 마이그레이션하는 것은 WordPress에서 마이그레이션하는 것보다 실제로 더 쉽습니다. 당신의 콘텐츠는 아마도 이미 마크다운에 있을 것이기 때문입니다.
| 기능 | Astro | Next.js | Gatsby |
|---|---|---|---|
| 기본 JavaScript 제공 | 0 KB | ~85-100 KB | ~70-90 KB |
| 콘텐츠 컬렉션 | 내장, 타입-안전 | 수동 설정 | GraphQL 레이어 |
| 빌드 시간 (1000 게시물) | ~30-45s | ~60-90s | ~120-300s |
| 학습곡선 | 낮음 | 중간-높음 | 중간 |
| 최고 대상 | 콘텐츠 사이트 | 웹 앱 | 레거시 프로젝트 |
| 활성 개발 | 매우 활성 | 매우 활성 | 최소 |
| SSR 지원 | 선택 사항 | 기본값 | 제한됨 |
7단계 마이그레이션 플레이북
이것이 제가 따르는 정확한 프로세스입니다. 손 흔들기 없음.
단계 1: WordPress 사이트 감사
코드를 건드리기 전에 작업 대상을 알아야 합니다. WordPress 관리 페이지에 로그인하고 인벤토리를 작성하십시오.
# WP-CLI가 설치된 경우 (설치해야 합니다)
wp post list --post_type=post --format=csv --fields=ID,post_title,post_name,post_date > posts.csv
wp post list --post_type=page --format=csv --fields=ID,post_title,post_name,post_date > pages.csv
wp plugin list --format=table
wp theme list --format=table
모든 플러그인과 그 역할을 문서화하십시오. Astro 동등물을 찾거나 제거해야 합니다. 일반적인 것들:
- Yoast SEO → Astro의 내장
<head>관리 +@astrojs/sitemap - Contact Form 7 → Formspree, Formspark, 또는 서버리스 함수
- WP Super Cache / W3 Total Cache → 필요하지 않음 (사이트가 이미 정적임)
- Wordfence / Sucuri → 필요하지 않음 (보호할 서버가 없음)
- Google Analytics 플러그인 → 직접 스크립트 태그 또는 Partytown 통합
- WooCommerce → Snipcart, Shopify Buy Button, 또는 전담 전자상거래 플랫폼
단계 2: WordPress 콘텐츠 내보내기
두 가지 옵션이 있습니다: XML 내보내기 또는 REST API. 대부분의 사이트에 XML 내보내기를 권장합니다. 한 번에 모든 것을 캡처하기 때문입니다.
WordPress 관리: 도구 → 내보내기 → 모든 콘텐츠 → 내보내기 파일 다운로드
이는 모든 게시물, 페이지, 댓글, 사용자 정의 필드, 카테고리, 태그, 미디어 참조가 포함된 .xml 파일을 제공합니다.
더 큰 사이트 (1000+ 게시물)의 경우, REST API 접근이 더 신뢰할 수 있습니다:
// scripts/export-wp.mjs
import fs from 'fs/promises';
import path from 'path';
const WP_URL = 'https://your-wordpress-site.com/wp-json/wp/v2';
const PER_PAGE = 100;
async function fetchAllPosts() {
let page = 1;
let allPosts = [];
while (true) {
const res = await fetch(
`${WP_URL}/posts?per_page=${PER_PAGE}&page=${page}&_embed`
);
if (!res.ok) break;
const posts = await res.json();
if (posts.length === 0) break;
allPosts = allPosts.concat(posts);
console.log(`Fetched page ${page} (${allPosts.length} posts total)`);
page++;
}
return allPosts;
}
const posts = await fetchAllPosts();
await fs.writeFile('wp-posts.json', JSON.stringify(posts, null, 2));
console.log(`Exported ${posts.length} posts`);
단계 3: Astro 프로젝트 스캐폴딩
npm create astro@latest my-new-site
cd my-new-site
# 필요한 통합 추가
npx astro add mdx
npx astro add sitemap
npx astro add tailwind
# 추가 의존성 설치
npm install sharp @astrojs/rss
테마보다는 최소 설정으로 시작하는 것을 권장합니다. 테마는 마이그레이션 중에 필요하지 않은 복잡성을 추가합니다. 먼저 콘텐츠를 작동시키고, 그 다음 스타일링하십시오.
단계 4: 콘텐츠를 마크다운으로 변환
실제 작업이 일어나는 곳입니다. WordPress HTML 콘텐츠를 적절한 frontmatter를 가진 깨끗한 마크다운으로 변환해야 합니다.
HTML-마크다운 변환을 위해 turndown을 사용하는 사용자 정의 Node.js 스크립트를 사용합니다:
npm install turndown @wordpress/block-serialization-default-parser
// scripts/convert-posts.mjs
import TurndownService from 'turndown';
import fs from 'fs/promises';
import path from 'path';
const turndown = new TurndownService({
headingStyle: 'atx',
codeBlockStyle: 'fenced',
});
// WordPress 특정 HTML 처리
turndown.addRule('wpCaption', {
filter: (node) => {
return node.nodeName === 'DIV' &&
node.className.includes('wp-caption');
},
replacement: (content, node) => {
const img = node.querySelector('img');
const caption = node.querySelector('.wp-caption-text');
return `\n`;
},
});
const posts = JSON.parse(await fs.readFile('wp-posts.json', 'utf-8'));
for (const post of posts) {
const slug = post.slug;
const markdown = turndown.turndown(post.content.rendered);
const frontmatter = `---
title: "${post.title.rendered.replace(/"/g, '\\"')}"
date: ${post.date}
excerpt: "${(post.excerpt.rendered || '').replace(/<[^>]*>/g, '').trim().replace(/"/g, '\\"')}"
categories: [${(post._embedded?.['wp:term']?.[0] || []).map(c => `"${c.name}"`).join(', ')}]
tags: [${(post._embedded?.['wp:term']?.[1] || []).map(t => `"${t.name}"`).join(', ')}]
featuredImage: "${post._embedded?.['wp:featuredmedia']?.[0]?.source_url || ''}"
draft: false
---`;
const content = `${frontmatter}\n\n${markdown}\n`;
await fs.mkdir('src/content/blog', { recursive: true });
await fs.writeFile(`src/content/blog/${slug}.md`, content);
console.log(`Converted: ${slug}`);
}
단계 5: 미디어 다운로드 및 구성
WordPress는 wp-content/uploads/YYYY/MM/ 디렉토리에 미디어를 저장합니다. 모든 것을 다운로드하고 참조를 업데이트해야 합니다.
# 빠르고 대충: 업로드 디렉토리의 wget 미러
wget -r -np -nH --cut-dirs=2 -P public/uploads \
https://your-wordpress-site.com/wp-content/uploads/
# 그 다음 마크다운 파일의 이전 URL 찾기 및 바꾸기
find src/content/blog -name '*.md' -exec sed -i '' \
's|https://your-wordpress-site.com/wp-content/uploads/|/uploads/|g' {} +
프로덕션 마이그레이션의 경우, Astro의 이미지 최적화를 sharp 라이브러리와 함께 사용하여 모든 것을 WebP로 변환하고 빌드 시간에 반응형 크기를 생성합니다. 이것만으로 이미지 페이로드를 40-60% 줄일 수 있습니다.
단계 6: 레이아웃 및 컴포넌트 구축
WordPress 테마 구조와 일치하는 (또는 개선하는) Astro 레이아웃을 만드십시오. 최소한 다음이 필요합니다:
src/layouts/BaseLayout.astro-- HTML 셸,<head>, 네비게이션, 푸터src/layouts/BlogLayout.astro-- 단일 게시물 템플릿src/pages/blog/index.astro-- 페이지 매김이 있는 블로그 목록src/pages/blog/[...slug].astro-- 동적 게시물 페이지src/pages/index.astro-- 홈페이지
단계 7: 테스트, 리다이렉트, 배포
로컬에서 빌드하고 모든 것을 확인합니다:
npm run build
npm run preview
# 끊긴 링크 확인
npx linkinator http://localhost:4321 --recurse
리다이렉트를 설정하고 (아래에서 자세히 다룸), DNS를 구성하고, 배포합니다. 호스팅 옵션은 비용 비교 섹션에서 다루겠습니다.
WordPress 데이터 내보내기에서 Astro 콘텐츠 컬렉션으로
Astro의 콘텐츠 컬렉션은 최고의 기능 중 하나입니다. 스키마 검증을 통해 마크다운 콘텐츠에 대한 타입-안전 접근을 제공합니다. 다음은 마이그레이션된 WordPress 콘텐츠에 대해 적절하게 설정하는 방법입니다.
스키마 정의
// src/content.config.ts
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';
const blog = defineCollection({
loader: glob({ pattern: '**/*.{md,mdx}', base: './src/content/blog' }),
schema: z.object({
title: z.string(),
date: z.coerce.date(),
excerpt: z.string().optional(),
categories: z.array(z.string()).default([]),
tags: z.array(z.string()).default([]),
featuredImage: z.string().optional(),
draft: z.boolean().default(false),
}),
});
export const collections = { blog };
이것의 아름다움: 마이그레이션된 게시물 중 frontmatter가 누락되거나 잘못되었다면, Astro는 명확한 오류 메시지와 함께 빌드 시간에 알려줍니다. 더 이상 침묵하는 실패가 없습니다.
WordPress 숏코드 처리
이것이 대부분의 마이그레이션 가이드가 건너뛰는 함정입니다. WordPress 게시물이 [gallery], [caption], [embed], 또는 플러그인의 사용자 정의 숏코드 같은 숏코드를 사용한다면, 마크다운에 원본 텍스트로 나타날 것입니다.
세 가지 옵션이 있습니다:
- 변환 중 사전 처리 -- 변환 스크립트에서 정규 표현식 규칙을 작성하여 숏코드를 마크다운 또는 HTML 동등물로 변환
- MDX 사용 -- 영향을 받는 게시물을
.mdx로 변환하고 숏코드를 대체하는 Astro 컴포넌트 생성 - 수동으로 찾기 및 바꾸기 -- 작은 사이트의 경우, 때때로 가장 빠른 접근
// 예시: 변환 중 WordPress 갤러리 숏코드 변환
function convertShortcodes(content) {
// [gallery ids="1,2,3"]
content = content.replace(
/\[gallery ids="([^"]+)"\]/g,
(match, ids) => {
const imageIds = ids.split(',');
return imageIds.map(id => `}.jpg)`).join('\n');
}
);
// [youtube url="..."]
content = content.replace(
/\[youtube[^\]]*url="([^"]+)"[^\]]*\]/g,
(match, url) => `<iframe src="${url}" width="560" height="315" frameborder="0"></iframe>`
);
return content;
}
콘텐츠 쿼리
콘텐츠가 컬렉션에 있으면, 쿼리하기는 간단합니다:
---
// src/pages/blog/index.astro
import { getCollection } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';
const posts = (await getCollection('blog'))
.filter(post => !post.data.draft)
.sort((a, b) => b.data.date.valueOf() - a.data.date.valueOf());
---
<BlogLayout title="Blog">
<ul>
{posts.map(post => (
<li>
<a href={`/blog/${post.slug}/`}>
<h2>{post.data.title}</h2>
<time>{post.data.date.toLocaleDateString()}</time>
<p>{post.data.excerpt}</p>
</a>
</li>
))}
</ul>
</BlogLayout>
SEO 보존: 301 리다이렉트, 사이트맵 및 스키마
이 섹션은 중요합니다. 엉망이 된 마이그레이션은 수년간의 SEO 자산을 하루 밤 사이에 파괴할 수 있습니다. 이것을 건너뛰지 마십시오.
URL 구조 및 301 리다이렉트
WordPress는 기본값으로 /2024/03/my-post-title/ 또는 /?p=123 같은 URL을 사용합니다. 모든 이전 URL을 새로운 Astro 동등물에 매핑해야 합니다.
먼저 이전 URL의 완전한 목록을 생성합니다:
# WP-CLI 사용
wp post list --post_type=post,page --field=url > old-urls.txt
# 또는 사이트맵 크롤링
curl -s https://your-site.com/sitemap.xml | grep -oP '<loc>\K[^<]+'
Vercel의 경우, 프로젝트 루트에 vercel.json을 만듭니다:
{
"redirects": [
{ "source": "/2024/03/my-old-post/", "destination": "/blog/my-old-post/", "permanent": true },
{ "source": "/:year(\\d{4})/:month(\\d{2})/:slug/", "destination": "/blog/:slug/", "permanent": true },
{ "source": "/category/:slug/", "destination": "/blog/category/:slug/", "permanent": true },
{ "source": "/feed/", "destination": "/rss.xml", "permanent": true }
]
}
Netlify의 경우, public/ 폴더에 _redirects를 사용합니다:
/2024/03/my-old-post/ /blog/my-old-post/ 301
/category/* /blog/category/:splat 301
/feed/ /rss.xml 301
Cloudflare Pages의 경우, _redirects를 사용하거나 (Netlify와 같은 형식) 대시보드의 Bulk Redirects를 사용합니다.
사이트맵 생성
@astrojs/sitemap 통합은 자동으로 처리합니다:
// astro.config.mjs
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
site: 'https://your-new-site.com',
integrations: [sitemap()],
});
배포 후 즉시 Google Search Console에서 새로운 사이트맵을 제출합니다. 또한 더 이상 존재하지 않고 리다이렉트되지 않는 모든 URL에 대해 제거 요청을 제출합니다.
구조화된 데이터 / 스키마 마크업
Yoast가 스키마 마크업을 처리하고 있다면, 복제해야 합니다. 재사용 가능한 컴포넌트를 만드십시오:
---
// src/components/ArticleSchema.astro
const { title, date, excerpt, image, author = 'Your Name' } = Astro.props;
const schema = {
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": title,
"datePublished": date,
"description": excerpt,
"image": image,
"author": {
"@type": "Person",
"name": author
}
};
---
<script type="application/ld+json" set:html={JSON.stringify(schema)} />
RSS 피드
RSS 구독자를 잊지 마십시오:
// src/pages/rss.xml.js
import rss from '@astrojs/rss';
import { getCollection } from 'astro:content';
export async function GET(context) {
const posts = await getCollection('blog');
return rss({
title: 'Your Site',
description: 'Your description',
site: context.site,
items: posts.map(post => ({
title: post.data.title,
pubDate: post.data.date,
description: post.data.excerpt,
link: `/blog/${post.slug}/`,
})),
});
}
호스팅 비용 비교
이것이 마이그레이션의 비즈니스 케이스가 무시할 수 없게 되는 곳입니다.
| 호스팅 시나리오 | 월간 비용 | 연간 비용 | 주의 사항 |
|---|---|---|---|
| WP Engine (관리형 WordPress) | $30-60 | $360-720 | 스타트업-성장 플랜 |
| Kinsta (관리형 WordPress) | $35-70 | $420-840 | 스타터-비즈니스 플랜 |
| Flywheel (관리형 WordPress) | $15-30 | $180-360 | Tiny-Personal 플랜 |
| 자가 호스팅 (DigitalOcean + 유지보수) | $12-24 | $144-288 | 업데이트를 위한 시간 제외 |
| Vercel의 Astro (Hobby) | $0 | $0 | 월 100GB 대역폭 |
| Netlify의 Astro (무료) | $0 | $0 | 월 100GB 대역폭 |
| Cloudflare Pages의 Astro (무료) | $0 | $0 | 무제한 대역폭 |
| Vercel의 Astro (Pro) | $20 | $240 | 1TB 대역폭, 팀 기능 |
대부분의 콘텐츠 사이트 -- 블로그, 포트폴리오, 문서 사이트, 마케팅 사이트 -- Vercel, Netlify, 또는 Cloudflare Pages의 무료 티어가 충분합니다. 전역 CDN에서 정적 파일을 제공하고 있습니다. 월 100,000 페이지뷰를 받는 사이트도 무료 티어 제한을 거의 건드리지 않을 것입니다.
수학을 명확하게 하겠습니다. 관리형 WordPress 호스팅에 월 $50를 지불하고 있다면, 그것은 연간 $600입니다. 3년 동안 $1,800입니다. 프리미엄 플러그인 라이선스를 추가하면 (Yoast Premium $99/년, Elementor Pro $59/년, WP Rocket $59/년), 콘텐츠 사이트의 경우 연간 $800-$1,000을 찾고 있습니다. 이 사이트는 무료로 호스팅될 수 있습니다.
마이그레이션 자체는 일회성 비용입니다. 자체 처리하는 경우 시간입니다. 저희 헤드리스 CMS 개발 서비스를 통해 팀을 고용하는 경우, ROI는 호스팅 절감만으로 일반적으로 6-12개월 내에 회수됩니다 -- 성능 및 SEO 개선은 고려하지 않습니다. 자세한 내용은 가격 페이지를 확인하십시오.
동적 기능은 어떻게 되나요?
가장 일반적인 이의: "내 WordPress 사이트에는 연락처 양식, 검색, 댓글, 전자상거래가 있습니다."
- 연락처 양식: Formspree (무료 티어: 월 50개 제출), Formspark, 또는 간단한 서버리스 함수
- 검색: Pagefind (무료, 전적으로 클라이언트 측 실행, 정적 사이트용 내장) -- 놀랍습니다
- 댓글: Giscus (무료, GitHub 지원), 또는 필요하면 Disqus
- 전자상거래: Snipcart, Shopify Lite, 또는 Stripe Checkout
- 뉴스레터 가입: ConvertKit, Mailchimp, 또는 Buttondown으로의 직접 API 호출
이것들은 어느 것도 서버가 필요하지 않습니다. 이것들은 의미 있는 비용을 추가하지 않습니다.
FAQ
WordPress에서 Astro 마이그레이션에는 얼마나 걸립니까?
50-200개 게시물의 일반적인 블로그의 경우, 자체 처리하는 경우 1-2주의 파트타임을 예상하십시오. 콘텐츠 변환은 일반적으로 좋은 스크립트로 하루의 작업입니다. Astro 레이아웃 및 컴포넌트 구축은 디자인 복잡도에 따라 2-4일이 걸립니다. 테스트, 리다이렉트 설정, 배포는 추가로 1-2일이 걸립니다. 더 큰 사이트 (500+ 게시물) 또는 복잡한 사용자 정의 게시물 유형 및 플러그인 종속성이 있는 사이트의 경우 3-6주를 예산하십시오. 대신 넘기고 싶으면, 저희 팀에 연락하십시오 -- 저희는 일반적으로 2-4주 내에 마이그레이션을 완료합니다.
Astro는 1000+ 게시물이 있는 WordPress 블로그를 처리할 수 있습니까?
절대로. 저는 3,000개 이상의 게시물이 있는 사이트를 마이그레이션했으며 빌드 시간은 2분 미만으로 유지되었습니다. 콘텐츠 컬렉션은 대규모 데이터셋에 최적화되며, 모든 것이 정적 HTML로 컴파일되므로 콘텐츠 볼륨에 관계없이 런타임 성능 페널티가 없습니다. 빌드 단계는 스케일이 중요한 유일한 곳이며, Astro의 빌드 성능은 뛰어납니다 -- Gatsby 또는 Next.js보다 정적 콘텐츠 규모에서 훨씬 빠릅니다.
Astro는 WordPress 댓글을 지원합니까?
기본적으로 아니며, 솔직히 버그가 아니라 기능입니다. WordPress 댓글은 끊임없는 중재가 필요한 스팸 자석입니다. Astro 사이트의 경우 최고의 옵션: Giscus (GitHub Discussions 사용 -- 무료, 추적 없음, 개발자 청중에게 좋음), Disqus (오래된 표준, 무료 티어에 광고 있음), Commento (개인정보 보호 중심, 월 $5), 또는 Turso 또는 Supabase 같은 데이터베이스를 사용하는 사용자 정의 솔루션과 Astro API 경로. 기존 WordPress 댓글을 유지하려면 내보내고 정적 콘텐츠로 표시한 다음, 새 댓글을 위해 이러한 서비스 중 하나를 사용합니다.
Astro는 WordPress보다 빠릅니까?
비교가 되지 않습니다. 정적 Astro 사이트는 가장 최적화된 WordPress 설정도 능가할 것입니다. 기본적인 병목 현상을 제거하기 때문입니다: 서버 측 처리. WordPress는 PHP를 실행하고, 데이터베이스를 쿼리하고, 페이지를 조합하고, 보내야 합니다 -- 요청마다 (캐시되지 않는 한). Astro는 모든 것을 사전 구축합니다. 방문자는 자신 가까운 CDN 엣지 노드에서 사전 렌더링된 HTML을 직접 받습니다. 일반적인 개선은 로드 시간이 80-90% 더 빠르고 Lighthouse 점수가 60-80포인트 개선되는 것입니다.
WordPress 관리자와 WYSIWYG 편집기는 어떻게 되나요?
WordPress 관리 패널을 잃습니다. 대부분의 개발자에게 그것은 안도입니다. 마크다운 파일을 직접 편집하며, 더 빠르고 휴대하기 쉽습니다. 시각적 인터페이스가 필요한 비기술적 콘텐츠 편집자가 있다면, 헤드리스 접근을 고려하십시오: WordPress를 콘텐츠 백엔드로 계속 실행하고 Astro를 프론트엔드로 사용합니다. 또는 Astro를 Sanity, Contentful, Storyblok, 또는 Keystatic (GitHub 기반 편집기가 정말 좋음) 같은 헤드리스 CMS와 쌍을 이루십시오. 저희 헤드리스 CMS 개발 서비스는 팀에 맞는 올바른 콘텐츠 백엔드를 선택하는 데 도움을 줄 수 있습니다.
마이그레이션 후 Google 순위가 떨어질까요?
떨어지지 않아야 하며, 대부분의 경우 개선됩니다 -- 하지만 리다이렉트를 올바르게 처리한 경우에만. 모든 이전 URL은 여전히 작동하거나 새로운 동등물로 301-리다이렉트되어야 합니다. 실행한 같은 날에 Google Search Console에 새로운 사이트맵을 제출합니다. 처음 30일 동안 Index Coverage 보고서를 모니터링합니다. Google이 페이지 경험 신호를 순위 결정 요소로 사용하므로, 저는 마이그레이션 후 2-3개월 내에 유기 트래픽이 15-30% 증가하는 것을 봤습니다. Core Web Vitals 개선만으로 인해.
WordPress를 헤드리스 CMS로 유지하고 프론트엔드로 Astro를 사용할 수 있습니까?
예, 그리고 이것은 좋은 중간 지점 접근입니다. WordPress 관리자와 편집기 경험을 유지하지만 PHP 프론트엔드는 제거합니다. Astro는 WordPress REST API (또는 WPGraphQL)에서 빌드 시간에 콘텐츠를 가져오고 정적 페이지를 생성합니다. 여전히 어딘가에 WordPress를 호스팅해야 하므로 호스팅 비용 절감은 없지만, 프론트엔드 성능 이점을 모두 얻습니다. WordPress 편집 워크플로우에 많이 투자한 팀의 경우, 이것이 종종 실용적인 선택입니다.
Astro를 사용하기 위해 React나 다른 JavaScript 프레임워크를 알아야 합니까?
아니요. Astro 컴포넌트는 frontmatter 스크립트 블록이 있는 HTML처럼 보이는 .astro 파일 형식을 사용합니다. HTML과 CSS를 쓸 수 있으면 Astro 사이트를 구축할 수 있습니다. JavaScript 프레임워크 (React, Vue, Svelte)는 선택 사항입니다 -- 검색 위젯, 검증이 있는 양식, 또는 이미지 회전판 같은 클라이언트 측 대화형 컴포넌트가 필요한 경우에만 가져올 것입니다. 블로그나 마케팅 사이트의 경우 React를 건드리지 않고도 전체를 구축할 수 있습니다.