Cách chuyển website WordPress sang headless CMS không mất SEO

Đội ngũ KDIGIĐăng 03/11/202615 phút đọc

Chuyển WordPress sang headless CMS không mất SEO là khả thi nếu bạn giữ được ba thứ: URL (hoặc redirect 301 đúng đích), nội dung và thẻ SEO tương đương (title, description, canonical, robots, schema), và HTML được render sẵn trên server. Thứ hạng chỉ giảm khi một trong ba thứ này bị gãy trong lúc cutover.

Tóm tắt nhanh

Headless CMS tách phần quản trị nội dung khỏi giao diện: nội dung nằm trong CMS, website công khai là một ứng dụng riêng đọc dữ liệu qua REST/GraphQL.

Rủi ro SEO lớn nhất không nằm ở "headless" mà ở URL đổi không có redirect, canonical trỏ sai host, noindex bị mang nhầm và trang render bằng JavaScript phía client.

Việc đầu tiên là chụp baseline: toàn bộ URL, status code, canonical, title/description của site cũ.

Redirect 301 phải trỏ thẳng đến đích cuối, không tạo chuỗi A → B → C.

Sau khi chuyển DNS, theo dõi Google Search Console 2–4 tuần trước khi tắt WordPress.

Bài này dùng KDIGI CMS (MIT, tự host) làm ví dụ cụ thể, nhưng nguyên tắc áp dụng cho mọi headless CMS.

Headless CMS là gì và vì sao người dùng WordPress chuyển sang

Headless CMS là hệ thống quản trị nội dung chỉ có phần "đầu vào" (soạn thảo, media, phân quyền, SEO fields) và không kèm theme. Website công khai là một ứng dụng riêng (Next.js, Astro, Nuxt…) gọi API để lấy nội dung rồi render ra HTML. Với WordPress truyền thống, theme, plugin và database nằm chung một ứng dụng PHP.

Lý do phổ biến để chuyển: một CMS phục vụ nhiều website, frontend hiện đại cho tốc độ tải, tách bảo mật (không còn wp-login.php công khai trên chính website), và quyền kiểm soát hoàn toàn đầu ra HTML. Lý do không nên chuyển: site nhỏ chạy ổn, không có developer, hoặc phụ thuộc nặng vào plugin (form, thương mại điện tử, membership). Nếu bạn đang cân nhắc, xem thêm so sánh KDIGI CMS và WordPress.

Một điểm cần nói thẳng: headless không tự làm SEO tốt hơn. Nó chỉ cho bạn quyền kiểm soát nhiều hơn, và cũng đòi hỏi bạn tự làm những việc WordPress từng làm hộ (sitemap, robots.txt, redirect, schema ở frontend).

Vì sao website mất thứ hạng sau khi chuyển CMS

Thứ hạng giảm sau migration hầu như luôn có nguyên nhân kỹ thuật cụ thể. Bảng dưới liệt kê các lỗi hay gặp và cách phòng.

Lỗi	Hậu quả	Cách phòng
URL đổi, không có redirect	Backlink và thứ hạng của URL cũ mất, người dùng gặp 404	Lập bảng URL cũ → mới, redirect 301 toàn bộ
Canonical còn trỏ về host WordPress cũ	Google coi bản cũ là bản gốc	Viết lại canonical sang domain mới trước khi lên production
`noindex` từ môi trường staging mang sang production	Trang bị loại khỏi chỉ mục	Kiểm `robots` meta và `robots.txt` ở production trước khi đổi DNS
Nội dung chỉ xuất hiện sau khi chạy JavaScript	Crawler thấy trang rỗng hoặc thiếu nội dung	Render phía server (SSR/SSG/ISR)
Mất schema, breadcrumb, Open Graph	Mất rich result, preview chia sẻ xấu	Sinh lại JSON-LD và OG ở frontend
Mất sitemap/robots.txt (trước đó do plugin sinh)	Google khám phá URL chậm	Frontend tự sinh `sitemap.xml`, `robots.txt`
Redirect chuỗi hoặc redirect về trang chủ hàng loạt	Tín hiệu yếu, soft-404	Redirect trỏ đích cuối; trang xóa để 404/410 thay vì dồn về trang chủ
Slug bị làm phẳng hoặc đổi theo ý muốn	URL thay đổi ngoài kế hoạch	Giữ slug; mọi thay đổi phải có redirect

Google nêu rõ cách xử lý trong tài liệu riêng về di chuyển site có thay đổi URL và redirect: dùng redirect phía server cho thay đổi vĩnh viễn, và giữ chúng đủ lâu. Chi tiết về redirect có trong bài Redirect 301 là gì và khi nào cần dùng.

Quy trình 9 bước chuyển WordPress sang headless CMS giữ SEO

Chụp baseline site cũ. Xuất toàn bộ URL từ sitemap.xml cũ, bổ sung URL có traffic hoặc backlink từ Google Search Console và log truy cập. Với mỗi URL ghi lại: status code, canonical, title, meta description, robots, H1. Đây là thước đo duy nhất để biết sau cutover có gì thay đổi.
Quyết định cấu trúc URL mới. Cách an toàn nhất là giữ nguyên permalink. Nếu buộc phải đổi (ví dụ bỏ /2024/05/ khỏi đường dẫn), lập bảng ánh xạ cũ → mới ngay từ bây giờ.
Chọn headless CMS và dựng môi trường staging. Staging phải chặn index (noindex hoặc xác thực), và bạn phải nhớ gỡ chặn này đúng lúc.
Di chuyển nội dung, media, taxonomy, menu, tác giả, dữ liệu SEO. Phần này nên dùng công cụ import có thể chạy lại (idempotent), không sao chép tay.
Rà soát nội dung đã import. Heading, bảng, ảnh, shortcode còn sót, canonical, robots, ngày xuất bản.
Dựng frontend render phía server với đầy đủ thẻ SEO, JSON-LD, sitemap, robots.txt, breadcrumb.
Cấu hình redirect. Áp bảng URL cũ → mới ở middleware hoặc ở tầng server/CDN.
Kiểm thử toàn bộ URL baseline trên staging, rồi cutover (đổi DNS), nộp sitemap mới.
Theo dõi 2–4 tuần trong Search Console (Pages, Performance, Crawl stats) trước khi tắt WordPress.

Các bước 4–5 là phần dễ làm sai nhất vì thủ công, nên phần dưới đi sâu vào cách KDIGI CMS tự động hoá chúng.

Bước 4–5 với KDIGI CMS: pipeline import 8 phase

KDIGI CMS có sẵn pipeline di chuyển từ bất kỳ site WordPress nào vào một site (tenant) của CMS. Dữ liệu đi qua WordPress → raw/ (bản sao bất biến) → staged/ (JSON chỉnh sửa được) → review gate → CMS, và không ghi gì vào database trước khi editor khoá dữ liệu staged bằng --gate lock. Nếu database đích không phải local, pipeline luôn chạy pg_dump trước và không có cờ bỏ qua. Toàn bộ mô tả nằm trong tài liệu migration và trang chuyển từ WordPress.

Pipeline chuyển được những gì (theo tài liệu của repo):

Nguồn WordPress	Đích trong KDIGI CMS
Bài viết (`post`), trang (`page`)	`posts`, `pages` (nội dung → Markdown, giữ ngày xuất bản)
Category, tag, taxonomy tùy biến	`taxonomies` (giữ cây cha/con)
Media Library	`media` (local-disk hoặc R2)
Menu, tác giả, bình luận	`menus`, `authors`, `comments`
Yoast SEO hoặc Rank Math	`seo.*` của từng tài liệu: title, description, canonical, robots, Open Graph, twitter, focus keyword
WooCommerce (tùy chọn)	`products` (một mức giá, không có giỏ hàng/đơn hàng)
Permalink cũ	`redirects` (301)

Không chuyển: theme, plugin, cấu hình form, tài khoản đăng nhập WordPress, nội dung page builder lưu ngoài post_content, custom field ACF. Đây là giới hạn thật, hãy đọc kỹ trước khi quyết định.

Các lệnh chính (chạy ở thư mục gốc repo kdigi-cms-open, Node ≥ 20):

# Đặt biến
SITE=my-site                       # Sites.siteKey
WP_URL=https://wp.example.com      # backend WordPress
DOMAIN=example.com                 # domain công khai MỚI

mig() { node --env-file=.env --import tsx src/importers/run-wp-migration.ts \
  --site "$SITE" --wp-url "$WP_URL" --domain "$DOMAIN" "$@"; }

mig                       # archive + normalize, dừng ở review gate
mig --gate lint           # in lỗi và cảnh báo
mig --gate lock           # khoá staged/ khi đã sạch lỗi
mig --dry-run --from schema --to redirects
mig --from schema --to redirects

Hai điểm liên quan trực tiếp đến SEO mà pipeline làm hộ:

Canonical được viết lại từ host WordPress sang --domain. Lint báo lỗi nếu canonical hoặc og:url còn trỏ về host WordPress (trừ khi bạn thay thế tại chỗ trên cùng host).
Redirect 301 từ permalink WordPress (ví dụ /2024/05/ten-bai/) sang đường dẫn mới được sinh tự động ở phase redirects.

Yoast và Rank Math: dữ liệu SEO nào mang sang

Cả hai plugin được chuẩn hoá về một dạng chung rồi nạp vào nhóm seo của tài liệu. Với site chỉ có REST API, Yoast có sẵn yoast_head_json nên đủ title, description, canonical, robots, OG. Rank Math nếu không có trường rank_math_* thì pipeline gọi GET /wp-json/rankmath/v1/getHead?url=<permalink> cho từng URL (có throttle) nên site lớn sẽ chậm hơn. Focus keyword của Yoast không công khai qua REST nên sẽ để trống.

Lưu ý quan trọng: JSON-LD không được import. KDIGI CMS sinh lại graph từ dữ liệu tài liệu và "knowledge graph" của site. Với site không dùng plugin SEO, trường seo rỗng và CMS dùng template SEO của site để sinh title/description lúc render.

Canonical tùy biến: cái bẫy ít người kiểm

Yoast và Rank Math cho phép đặt canonical khác URL của chính trang, nhưng nhiều site WordPress không phát giá trị đó ra frontend. Nếu importer mang nguyên sang seo.canonicalOverride, CMS sẽ áp dụng và có thể vô tình de-index trang đích. Cách kiểm: trước khi --gate lock, dùng curl lấy canonical của trang thật và so với staged/*/seo.canonicalOverride, xoá các giá trị chỉ tồn tại trong database WordPress.

Page builder: Elementor, Divi và giới hạn của import

Importer chỉ đọc HTML đã render của post_content rồi chuyển sang Markdown. Hệ quả: Classic Editor cho kết quả tốt nhất, Gutenberg tốt, còn Elementor/Divi/WPBakery bị làm phẳng: heading, đoạn, ảnh được giữ, còn layout cột, section, animation mất. Trang nào quan trọng với SEO (landing có nhiều traffic) cần rà lại bằng tay hoặc dựng lại bằng collection landings của CMS. --gate lint sẽ cảnh báo contentMd empty khi nội dung nằm ngoài post_content.

Redirect: phần quyết định thứ hạng sau cutover

Mỗi URL của site cũ phải có một trong ba kết cục: giữ nguyên URL, 301 đến URL mới tương đương, hoặc 404/410 có chủ ý khi nội dung đã bị xoá. Quy tắc từ playbook của KDIGI CMS:

to luôn là đích cuối, không tạo chuỗi A → B → C.
Trang bị xoá để draft (trả 404) thay vì redirect hàng loạt về trang chủ, vì soft-404 gây hại SEO.
Pipeline không tự sinh redirect cho trang lưu trữ taxonomy (/category/<slug>/, /tag/<slug>/), trang tác giả, phân trang, feed, ?p=123 và đính kèm. Hãy liệt kê các URL có traffic từ Search Console rồi thêm vào staged/redirects/.
Redirect của plugin (Rank Math Redirections, Yoast Premium) không được archive; xuất CSV từ plugin rồi chuyển thành file JSON.

Ví dụ một redirect thủ công:

{ "collection": "redirects", "from": "/old-landing/", "to": "/new-landing", "statusCode": 301, "note": "from RankMath" }

Trong CMS, collection redirects có from (đường dẫn bắt đầu bằng /), to (đường dẫn nội bộ, URL ngoài bị từ chối khi lưu), statusCode (301 hoặc 302) và isEnabled. Frontend của bạn đọc danh sách này qua REST và áp dụng ở middleware; CMS chỉ cảnh báo khi có chuỗi chứ không tự chặn. Sau này đổi slug trong admin, CMS tự tạo redirect 301 từ đường dẫn cũ sang mới. Xem thêm tính năng SEO và JSON-LD.

Frontend: những thứ WordPress từng làm hộ

Khi chuyển sang headless, các việc sau trở thành trách nhiệm của frontend. Theo playbook của KDIGI, sitemap và robots.txt không được chuyển, frontend phải tự sinh.

Việc	Cần làm ở frontend headless
Render HTML	SSR/SSG/ISR; kiểm bằng `curl` thấy đủ nội dung mà không cần JavaScript
Title, description	Đọc `seo.*` và template của site (`Sites.seoTitles`); xem tài liệu SEO
Canonical, robots	Tuyệt đối URL, đúng domain
JSON-LD	CMS lưu sẵn `<script type="application/ld+json">` trong `seo.jsonLd.raw`, frontend chèn nguyên văn
Breadcrumb	Dùng `seo.breadcrumbs` (bỏ qua mục `isHidden: true`)
Sitemap, robots.txt	Tự sinh, nộp trong Search Console
Làm mới cache khi nội dung đổi	Cung cấp webhook revalidate cho CMS gọi

Về tích hợp, đọc Headless API. Với JSON-LD, đọc bài Schema markup và JSON-LD là gì.

Cutover: đổi DNS an toàn

Có ba kịch bản theo playbook:

Đổi domain: WordPress ở old.example.com, KDIGI CMS phục vụ example.com (--wp-url https://old.example.com --domain example.com).
Backend WordPress tách khỏi site công khai (wp.example.com là backend, example.com là site công khai cũ): thêm --public-url https://example.com để link nội bộ chuyển thành đường dẫn tương đối.
Thay thế tại chỗ (cùng host): bắt buộc có redirect cho mọi URL thay đổi và kiểm robots/canonical trên staging trước khi chuyển DNS.

Quy trình khuyến nghị: baseline nguồn → import vào DB local hoặc staging → duyệt checklist nghiệm thu → import production (backup bắt buộc) → so sánh lại toàn bộ URL → chuyển DNS → theo dõi Search Console 2–4 tuần → tắt WordPress. Đóng băng nội dung WordPress từ lúc archive cuối cùng đến cutover để không bỏ sót bài mới.

Checklist nghiệm thu trước khi chuyển DNS

[ ] 10 URL ngẫu nhiên và toàn bộ URL trong sitemap cũ: mở được hoặc 301 đúng đích.
[ ] Canonical, og:url, robots đúng domain mới; không có noindex ngoài ý muốn.
[ ] Ngày xuất bản/sửa đúng nguồn, không phải ngày import.
[ ] Heading, bảng, ảnh hiển thị đủ; không còn [shortcode] hoặc Markdown thô.
[ ] Ảnh load được (HTTP 200), featured image đúng bài.
[ ] Menu header/footer đúng, link nội bộ không 404.
[ ] sitemap.xml, robots.txt hoạt động; JSON-LD hợp lệ trong Rich Results Test.
[ ] Đã lưu file pg_dump và thư mục wp-archive/<site>/.

Sau cutover: theo dõi gì

Trong 2–4 tuần đầu, kiểm tra hằng tuần: báo cáo Pages (trang bị loại, "Crawled – currently not indexed", 404 mới), báo cáo Performance so với baseline, và Crawl stats. Google cũng lưu ý rằng URL cũ vẫn có thể thỉnh thoảng hiện trong kết quả dù URL mới đã được lập chỉ mục, đây là hiện tượng bình thường. Đừng gỡ redirect sớm; hãy giữ chúng càng lâu càng tốt và đối chiếu mốc thời gian trong tài liệu site move của Google.

Dao động thứ hạng ngắn hạn sau khi đổi hạ tầng là bình thường. Nếu sau vài tuần lượng URL được lập chỉ mục tụt rõ rệt, quay lại baseline và đối chiếu từng nhóm URL.

Có nên chuyển không: bảng quyết định nhanh

Tình huống	Gợi ý
Blog hoặc site doanh nghiệp, có developer, muốn frontend tốc độ cao	Phù hợp headless
Nhiều website cần quản trị chung	Phù hợp CMS đa site như KDIGI CMS
Bán hàng WooCommerce có giỏ hàng, biến thể, đơn hàng	Giữ WooCommerce làm backend bán hàng; chỉ chuyển nội dung/SEO
Site dựng hoàn toàn bằng Elementor, nhiều landing phức tạp	Chuẩn bị dựng lại layout; đừng kỳ vọng import giữ nguyên
Không có developer, site nhỏ chạy ổn	Ở lại WordPress

Nếu bạn muốn tự host thay vì dùng dịch vụ, xem hướng dẫn tự host.

Câu hỏi thường gặp

Chuyển WordPress sang headless CMS có làm giảm thứ hạng SEO không?

Không nhất thiết. Thứ hạng chỉ giảm khi URL đổi mà thiếu redirect 301, canonical hoặc robots bị sai, hoặc nội dung chỉ hiện sau JavaScript. Nếu bạn giữ URL, chuyển đủ dữ liệu SEO, render phía server và theo dõi Search Console sau cutover, rủi ro mất thứ hạng rất thấp. Dao động ngắn hạn vẫn có thể xảy ra.

Có cần giữ nguyên URL khi chuyển sang headless không?

Nên giữ nguyên permalink nếu có thể, vì đó là cách giảm rủi ro lớn nhất. Nếu bắt buộc đổi, mọi URL cũ phải 301 đến URL mới tương đương, trỏ thẳng đích cuối. Với KDIGI CMS, redirect từ permalink WordPress được sinh tự động ở phase redirects, còn trang lưu trữ taxonomy, tác giả, feed phải thêm thủ công.

Yoast hoặc Rank Math có chuyển sang headless CMS được không?

Dữ liệu SEO của plugin (title, description, canonical, robots, Open Graph) có thể chuyển được, nhưng bản thân plugin thì không. KDIGI CMS chuẩn hoá cả Yoast lẫn Rank Math về nhóm seo. JSON-LD không import mà được sinh lại từ dữ liệu tài liệu. Redirect lưu trong plugin cần xuất CSV và nhập riêng.

Elementor hoặc Divi có chuyển được không?

Chuyển được phần nội dung văn bản, nhưng không giữ được layout. Importer chỉ đọc HTML của post_content, nên cột, section và animation bị làm phẳng; với trang nội dung nằm trong meta của page builder, kết quả có thể rỗng. Hãy rà lại các trang quan trọng và dựng lại landing đẹp bằng collection landings.

Mất bao lâu để Google ổn định lại sau khi chuyển?

Google không cam kết thời gian cố định. Với site vừa và nhỏ, thường cần vài tuần để Google crawl lại và hợp nhất tín hiệu; site lớn lâu hơn. Playbook của KDIGI khuyến nghị theo dõi Search Console 2–4 tuần trước khi tắt WordPress. Đừng gỡ redirect sớm và đừng đổi thêm cấu trúc URL trong giai đoạn này.

Dùng KDIGI CMS để chuyển site WordPress có tốn phí không?

KDIGI CMS là mã nguồn mở giấy phép MIT và bạn tự host, nên không có phí bản quyền phần mềm; bạn chỉ trả chi phí hạ tầng và công sức triển khai frontend. Xem trang mã nguồn mở và chuyển từ WordPress.

Nguồn

Google Search Central, Redirects and Google Search
Google Search Central, Site move with URL changes
Google Search Central, AI features and your website
KDIGI CMS, Tài liệu di chuyển WordPress (thư mục docs/wordpress-migration: README, runbook, playbook)