Trong dự án DÉCOR & MORE, nhóm tôi đã đăng 76 bài blog và xây dựng 45 backlink. Khối lượng công việc khá lớn, nhưng phần tự đánh giá của báo cáo vẫn thừa nhận hiệu quả SEO chưa cải thiện rõ trong thời gian dự án. Đây là mâu thuẫn quan trọng nhất tôi rút ra: làm nhiều chưa chắc tạo ra kết quả nếu CMS giới hạn quyền xử lý kỹ thuật, trang quản trị thường xuyên gặp lỗi và nội dung chưa có đủ thời gian để được crawl, index rồi tạo traffic.
Website sử dụng CMS Yaviet. Nhóm có thể làm nội dung, hình ảnh, on-page và off-page, nhưng không chủ động sửa sâu sitemap, cache, schema hay một số vấn đề thuộc hệ thống. Vì vậy, bài học của tôi không phải là “CMS riêng không thể làm SEO”. Điều thực tế hơn là SEO trên CMS hạn chế cần một quy trình phân quyền, phối hợp và đo lường khác với checklist thông thường.
1. Làm SEO trên CMS hạn chế khác gì một checklist SEO thông thường
Một checklist cho biết cần kiểm tra gì. Trong khi đó, dự án trên CMS hạn chế còn phải trả lời hai câu hỏi khó hơn: ai có quyền sửa và khi nào bản sửa có thể được triển khai. Nếu bỏ qua hai câu hỏi này, audit dễ trở thành một danh sách lỗi dài nhưng không tạo ra thay đổi.
Ba lớp công việc gồm nội dung cấu hình CMS và hạ tầng kỹ thuật
Lớp nội dung gồm nghiên cứu từ khóa, viết bài, heading, metadata, internal link, ảnh và cập nhật sản phẩm. Đây thường là phần marketer có thể xử lý trong quyền biên tập được cấp.
Lớp cấu hình CMS gồm template, canonical, redirect, sitemap, schema, phân loại nội dung và cách hệ thống sinh URL. Một số CMS có giao diện cho quản trị viên, nhưng CMS riêng có thể khóa các chức năng này hoặc yêu cầu nhà cung cấp can thiệp.
Lớp hạ tầng nằm sâu hơn: mã trạng thái HTTP, hiệu suất máy chủ, cache, JavaScript, log thu thập dữ liệu và cách triển khai bản sửa. Khi vấn đề nằm ở lớp này, marketer có thể phát hiện và mô tả, còn đội phát triển hoặc nhà cung cấp mới có quyền sửa.
Biết lỗi chưa đồng nghĩa với có quyền sửa lỗi
Audit có thể chỉ ra rằng sitemap thiếu URL quan trọng hoặc dữ liệu có cấu trúc bị lỗi. Tuy nhiên, nếu tài khoản quản trị không có quyền thay đổi template hoặc file hệ thống, thao tác tiếp theo không phải là “tối ưu thêm”. Nhóm cần chuyển phát hiện đó thành một yêu cầu kỹ thuật có bằng chứng, người chịu trách nhiệm và cách kiểm tra sau khi sửa.
Đây là khác biệt giữa năng lực chẩn đoán và năng lực triển khai. SEO vẫn chịu trách nhiệm mô tả tác động và xác nhận kết quả, nhưng không nên nhận một cam kết phụ thuộc hoàn toàn vào quyền của IT.
2. Bối cảnh case study DÉCOR & MORE
DÉCOR & MORE là dự án Search Marketing bao gồm nghiên cứu, technical SEO, on-page, off-page và PPC. Trong bảng phân công, tôi tham gia các phần Brief, Technical, On-page, Off-page và PPC; tôi trực tiếp phụ trách nghiên cứu từ khóa, đồng thời rà soát phần việc cùng nhóm.
Mục tiêu và phạm vi gồm technical on-page off-page và PPC
Nhóm bắt đầu từ audit website, nghiên cứu đối thủ và từ khóa, sau đó triển khai nội dung, tối ưu những khu vực được cấp quyền, xây backlink và chạy Google Ads. Phạm vi rộng giúp tôi nhìn thấy sự phụ thuộc giữa các hạng mục: nội dung cần hệ thống hoạt động ổn định; technical cần quyền truy cập; còn PPC có thể tạo traffic sớm nhưng không thay thế tăng trưởng organic.
[INTERNAL LINK CHỜ XUẤT BẢN: Case study DÉCOR & MORE]
Những đầu việc nhóm đã triển khai gồm 76 bài blog và 45 backlink
Phần tổng kết báo cáo ghi nhận 76 bài blog đã đăng và 45 backlink trên hơn 30 nền tảng social, profile và cộng đồng thiết kế. Tôi xem đây là số liệu về sản lượng, không phải kết quả SEO cuối cùng. Chính báo cáo cũng ghi rằng độ phủ từ khóa, impression và traffic organic chưa đạt kỳ vọng trong thời gian dự án.
Một lưu ý dữ liệu là các slide theo dõi nội dung dùng phạm vi đếm khác nhau. Vì vậy, bài viết này giữ con số 76 từ phần tổng kết và không suy ra tỷ lệ index chung nếu chưa có danh sách URL thống nhất.
Giới hạn của CMS Yaviet nằm ở sitemap cache schema và trang quản trị
Nhóm không thể tự can thiệp sâu vào sitemap, cache và schema. Khi trang quản trị gặp lỗi, tiến độ đăng bài chậm lại; nội dung vì thế cũng có ít thời gian hơn để được Google phát hiện và ghi nhận. Nhóm đã làm việc với IT Yaviet qua UltraViewer, đồng thời tiếp tục những phần có thể kiểm soát như nội dung, hình ảnh, on-page và off-page.
Trải nghiệm này dẫn đến năm bài học dưới đây.
3. Bài học 1 Audit phải kết thúc bằng ma trận quyền xử lý
Kết quả quan trọng nhất của audit không phải số lỗi tìm được. Đó là danh sách hành động đã được chia theo quyền xử lý. Tôi dùng ba nhóm để tránh việc marketer chờ IT cho mọi việc hoặc cố sửa những phần mình không được phép chạm tới.
Nhóm A là việc marketer có thể tự làm ngay
Nhóm A gồm các việc nằm trong quyền biên tập: sửa title và meta description, chuẩn hóa heading, bổ sung nội dung hữu ích, nén ảnh, cải thiện alt text, thêm internal link, cập nhật CTA và kiểm tra liên kết hỏng trong phần nội dung. Mỗi việc nên có URL cụ thể và được kiểm tra sau khi xuất bản.
Nhóm B cần IT hỗ trợ hoặc cấp quyền
Nhóm B gồm sitemap, canonical, redirect, schema ở cấp template, cache, lỗi 4xx, cách sinh URL hoặc tài nguyên bị chặn. SEO cần cung cấp hiện tượng, URL mẫu, ảnh hoặc dữ liệu kiểm tra, tác động dự kiến và tiêu chí xác nhận. IT chịu trách nhiệm thay đổi hệ thống; SEO chịu trách nhiệm kiểm thử lại.
Nhóm C chưa thể sửa nên phải theo dõi và quản trị rủi ro
Một số thay đổi có thể bị hoãn vì nền tảng, ngân sách hoặc lộ trình sản phẩm. Với nhóm C, cần ghi rõ rủi ro và phương án tạm thời. Ví dụ, nếu chưa thay được cấu trúc template, nhóm có thể ưu tiên các trang quan trọng, củng cố internal link và tránh mở rộng thêm loại trang gây trùng lặp.
Audit nên kết thúc bằng owner và hành động, không dừng ở danh sách lỗi.
4. Bài học 2 Ưu tiên khả năng crawl và index trước khối lượng nội dung
Nội dung chỉ có cơ hội tạo traffic khi Google có thể tìm thấy, truy cập và lập chỉ mục trang. Theo yêu cầu kỹ thuật tối thiểu của Google Tìm kiếm, Googlebot không được bị chặn, trang phải trả mã HTTP 200 và nội dung phải có thể lập chỉ mục. Đáp ứng ba điều kiện này vẫn không bảo đảm trang sẽ được index.
Ba điều kiện tối thiểu Google cần ở một trang
Trước khi tăng sản lượng, tôi sẽ kiểm tra một mẫu URL theo từng loại trang: bài blog, danh mục và sản phẩm. Với mỗi URL, cần xác nhận Googlebot có thể truy cập, máy chủ trả phản hồi hợp lệ, không có chỉ thị noindex ngoài ý muốn và phần nội dung chính xuất hiện trong phiên bản Google có thể đọc.
Việc này giúp tách hai vấn đề. Nếu URL chưa đủ điều kiện kỹ thuật, cần sửa hệ thống. Nếu URL đủ điều kiện nhưng chưa được index, nhóm tiếp tục kiểm tra chất lượng, trùng lặp, canonical, internal link và thời gian Google xử lý.
Cách dùng URL Inspection Page Indexing và sitemap để kiểm tra
Công cụ kiểm tra URL cho biết trạng thái của một URL, lần crawl gần nhất, khả năng lập chỉ mục và canonical do Google chọn. Sau khi IT sửa, nên chạy kiểm tra phiên bản hoạt động trước, rồi mới yêu cầu index nếu phù hợp.
Báo cáo Lập chỉ mục trang giúp nhìn vấn đề theo nhóm nguyên nhân trên toàn website. Sitemap hỗ trợ Google khám phá URL, nhưng việc gửi sitemap chỉ là một tín hiệu gợi ý, không bảo đảm crawl hoặc index. Vì vậy, nhóm cần theo dõi cả sitemap, Page Indexing và từng URL quan trọng thay vì chỉ bấm “Request indexing”.
Vì sao 76 bài đã đăng không đồng nghĩa 76 bài tạo traffic
“Đã đăng”, “đã index”, “có impression” và “có click” là bốn trạng thái khác nhau. Một URL có thể xuất bản thành công nhưng chưa được Google phát hiện. URL đã index vẫn có thể chưa tạo impression nếu chủ đề, chất lượng hoặc mức cạnh tranh chưa phù hợp. URL có impression cũng chưa chắc nhận click.
Vì các bảng trong báo cáo dùng phạm vi đếm khác nhau, cách an toàn là lập một bảng URL duy nhất với các cột: ngày đăng, canonical, trạng thái index, impression, click, truy vấn và hành động tiếp theo. Bảng này đáng tin hơn một tỷ lệ index tổng hợp thiếu cùng mẫu số.
5. Bài học 3 Mỗi yêu cầu kỹ thuật phải có owner mức ưu tiên và thời hạn
Khi quyền sửa nằm ở IT, chất lượng của yêu cầu quyết định tốc độ xử lý. Một tin nhắn “website bị lỗi SEO” không đủ để người phát triển tái hiện vấn đề, đánh giá mức ảnh hưởng hoặc biết khi nào công việc hoàn tất.
Viết ticket bằng URL lỗi ảnh hưởng cách kiểm tra và mức ưu tiên
Một ticket ngắn có thể dùng cấu trúc sau:
1. URL hoặc mẫu URL: nơi xuất hiện vấn đề.
2. Hiện tượng: mô tả điều đang xảy ra, kèm ảnh hoặc dữ liệu kiểm tra.
3. Ảnh hưởng: trang không crawl được, canonical sai, dữ liệu có cấu trúc lỗi hay chỉ là cải tiến.
4. Cách tái hiện: công cụ, bước kiểm tra và kết quả hiện tại.
5. Mức ưu tiên: chặn index, ảnh hưởng trang quan trọng hoặc cải tiến theo backlog.
6. Tiêu chí nghiệm thu: trạng thái mong đợi sau khi sửa.
Thiết lập SLA tối thiểu giữa SEO và IT
SLA trong ngữ cảnh này là thời gian phản hồi và xử lý đã được thống nhất, không phải lời hứa rằng mọi lỗi sẽ hoàn tất trong cùng một khoảng thời gian. Nhóm có thể chia yêu cầu thành ba mức: lỗi chặn xuất bản hoặc index; lỗi ảnh hưởng nhóm trang quan trọng; và cải tiến không khẩn cấp. Mỗi mức cần owner, ngày phản hồi dự kiến và lịch cập nhật trạng thái.
Thời hạn cụ thể phải do SEO, IT và doanh nghiệp thống nhất theo nguồn lực thật. Không nên tự đặt một con số trong báo cáo rồi xem đó là cam kết của nhà cung cấp.
Kiểm tra lại sau khi IT sửa thay vì mặc định lỗi đã được giải quyết
Một ticket chỉ đóng khi tiêu chí nghiệm thu đã đạt. SEO cần mở lại URL, kiểm tra mã phản hồi, canonical, robots, phần kết xuất và dữ liệu có cấu trúc liên quan. Với lỗi index, nên kiểm tra phiên bản hoạt động trong URL Inspection và theo dõi báo cáo sau khi Google crawl lại.
Ticket chưa hoàn tất cho đến khi bản sửa được kiểm tra lại trên URL thật.
6. Bài học 4 Đo chất lượng đầu ra thay vì chỉ đếm số lượng thực thi
Sản lượng giúp quản lý tiến độ, nhưng không trả lời nội dung có được tìm thấy hoặc mang lại giá trị hay không. Vì vậy, báo cáo SEO nên nối mỗi đầu ra với một chỉ số chất lượng ở bước kế tiếp.
Từ số bài và backlink đến index impression click và truy vấn
Với nội dung, chuỗi đo phù hợp là: bài đã xuất bản → URL đủ điều kiện index → URL đã index → impression → click → hành động trên website. Với backlink, cần kiểm tra trang nguồn có tồn tại và có thể được crawl, liên kết có đúng URL đích, ngữ cảnh có liên quan và liên kết có được công cụ phát hiện hay không.
Bộ nội dung Portfolio tổng hợp Search Console trong bốn tháng với 452 lượt nhấp, 6,89 nghìn lượt hiển thị, CTR 6,6% và vị trí trung bình 7,3. Các số liệu này tạo baseline để tiếp tục theo dõi, nhưng chưa đủ chứng minh tăng trưởng bền vững vì thời gian ngắn và traffic còn phụ thuộc một phần vào truy vấn thương hiệu.
Đọc Search Console theo trang truy vấn và giai đoạn thời gian
Báo cáo Hiệu suất của Search Console cho phép nhóm dữ liệu theo truy vấn, trang, quốc gia, thiết bị và thời gian. Thay vì chỉ nhìn tổng click, tôi sẽ trả lời ba câu hỏi: trang nào bắt đầu có impression; truy vấn nào là thương hiệu hay không thương hiệu; và thay đổi xuất hiện sau khi URL được index bao lâu.
So sánh cần dùng cùng phạm vi và đủ thời gian. Một dự án ngắn nên ưu tiên tín hiệu sớm như số trang quan trọng được index, impression không thương hiệu và truy vấn mới, đồng thời ghi rõ rằng đây là chỉ số trung gian.
Backlink đã tạo khác backlink đã được ghi nhận như thế nào
Một backlink “đã tạo” nghĩa là nhóm đã đặt liên kết trên một trang nguồn. Điều đó không bảo đảm trang nguồn được index, liên kết được Google dùng hay liên kết tạo tác động xếp hạng. Báo cáo Links của Search Console cũng không phải danh sách đầy đủ; Google mô tả đây là một mẫu liên kết nội bộ và bên ngoài.
Vì vậy, báo cáo nên tách số link đã triển khai, số trang nguồn còn hoạt động, số link được phát hiện trong công cụ và chất lượng của domain hoặc ngữ cảnh. Với dự án tiếp theo, tôi sẽ ưu tiên ít nguồn hơn nhưng liên quan và có giá trị tham chiếu rõ hơn.
Baseline GSC cho thấy tín hiệu hiển thị và nhấp chuột, chưa đủ kết luận tăng trưởng SEO bền vững.
7. Bài học 5 KPI phải phản ánh phần đội dự án có thể kiểm soát
KPI hợp lý phải cho thấy cả công việc đã làm và giới hạn quyền kiểm soát. Nếu mọi kết quả organic đều được giao cho nhóm SEO nhưng thời gian sửa CMS phụ thuộc nhà cung cấp, báo cáo sẽ khó phân biệt chất lượng triển khai với độ trễ kỹ thuật.
Tách KPI thực thi KPI SEO trung gian và KPI kinh doanh
Tôi đề xuất ba tầng KPI:
• KPI thực thi: bài được duyệt và đăng đúng chuẩn, ticket kỹ thuật được gửi đủ thông tin, internal link được bổ sung, URL quan trọng được kiểm tra.
• KPI SEO trung gian: trang quan trọng đủ điều kiện index, số URL đã index, impression không thương hiệu, click, CTR và truy vấn liên quan.
• KPI kinh doanh: form, cuộc gọi, yêu cầu báo giá, lead đủ điều kiện hoặc doanh thu có thể gắn nguồn.
Tầng đầu nằm gần quyền kiểm soát của đội dự án. Hai tầng sau chịu tác động của kỹ thuật, thời gian, nhu cầu tìm kiếm, mức cạnh tranh, trải nghiệm trang và năng lực chuyển đổi.
Điều chỉnh kỳ vọng khi dự án ngắn và phụ thuộc kỹ thuật
Trong giai đoạn ngắn, mục tiêu nên tập trung vào nền tảng: sửa các lỗi chặn, index các trang ưu tiên, tạo baseline và chứng minh quy trình phối hợp hoạt động. Mục tiêu traffic hoặc lead vẫn cần theo dõi, nhưng phải ghi rõ thời gian đo và các phụ thuộc chưa được giải quyết.
Điều chỉnh kỳ vọng không có nghĩa hạ tiêu chuẩn. Nó giúp cam kết đúng phần nhóm có thể thực hiện, đồng thời làm rõ điều kiện cần để kết quả xuất hiện ở giai đoạn sau.
Cách báo cáo kết quả mà không che giấu hạn chế
Báo cáo nên đặt kết quả và giới hạn cạnh nhau. Với DÉCOR & MORE, cách diễn đạt phù hợp là: nhóm đã đăng 76 bài và xây 45 backlink; tuy nhiên, hiệu quả organic chưa cải thiện rõ trong thời gian dự án do thời gian quan sát ngắn và các giới hạn kỹ thuật chưa được xử lý hoàn toàn.
Cách viết này không làm dự án yếu đi. Nó chứng minh người làm có thể phân biệt output với outcome, nêu đúng phạm vi bằng chứng và đề xuất bước tiếp theo có căn cứ.
8. Checklist triển khai SEO khi không thể sửa sâu CMS
Trước khi làm cần xác định quyền truy cập điểm nghẽn và baseline
1. Liệt kê tài khoản và quyền thực tế của marketing, IT và nhà cung cấp CMS.
2. Chọn nhóm URL quan trọng để kiểm tra crawl, index, canonical và hiệu suất.
3. Ghi baseline Search Console theo cùng khoảng thời gian, trang và truy vấn.
4. Xác định lỗi nào chặn index, lỗi nào ảnh hưởng trải nghiệm và lỗi nào chỉ là cải tiến.
5. Thống nhất owner, kênh nhận ticket và nguyên tắc ưu tiên.
Trong khi làm cần duy trì backlog ticket IT và kiểm tra index
1. Gắn mọi phát hiện với URL, bằng chứng và tiêu chí nghiệm thu.
2. Tiếp tục tối ưu phần marketer có quyền thay vì chờ toàn bộ technical hoàn tất.
3. Theo dõi trạng thái URL ưu tiên bằng Page Indexing và URL Inspection.
4. Ghi ngày đăng, ngày index và ngày bắt đầu có impression để hiểu độ trễ.
5. Rà soát backlog định kỳ với IT và cập nhật phụ thuộc.
Sau khi làm cần đo tác động ghi giới hạn và đề xuất giai đoạn tiếp theo
1. So sánh cùng phạm vi thời gian, tách branded và non-branded khi dữ liệu cho phép.
2. Đánh giá theo từng trang và truy vấn, không chỉ tổng toàn website.
3. Tách rõ output, KPI trung gian và kết quả kinh doanh.
4. Ghi những lỗi còn mở, rủi ro và dữ liệu chưa thể đối soát.
5. Đề xuất giai đoạn tiếp theo theo thứ tự tác động và khả năng triển khai.
Quy trình giúp nhóm duy trì tiến độ dù một phần technical SEO phụ thuộc IT.
9. Kết luận CMS hạn chế buộc quy trình SEO thực tế hơn
CMS hạn chế không làm SEO bất khả thi. Nó làm lộ rõ một yêu cầu thường bị bỏ qua: chiến lược chỉ có thể triển khai khi audit, quyền xử lý, phối hợp IT và đo lường được nối thành một quy trình.
Bài học lớn nhất của tôi từ DÉCOR & MORE là không dùng khối lượng để thay cho hiệu quả. 76 bài và 45 backlink cho thấy nỗ lực triển khai; giá trị SEO phải tiếp tục được kiểm tra qua trạng thái index, impression, click, truy vấn và hành động kinh doanh trong một khoảng thời gian đủ dài. Khi báo cáo thẳng cả phần làm được lẫn giới hạn, nhóm có cơ sở tốt hơn để chọn việc cần ưu tiên ở giai đoạn tiếp theo.
CTA chính: [INTERNAL LINK CHỜ XUẤT BẢN: Xem case study DÉCOR & MORE và cách tôi phân chia công việc SEO với IT]
