Bàn giao website chuẩn SEO cần kiểm tra những gì trước khi nhận

Trước khi nhận bàn giao website, doanh nghiệp không nên chỉ kiểm tra giao diện đẹp hay website “chạy được”, mà cần nghiệm thu toàn bộ nền tảng SEO, dữ liệu và quyền quản trị như một tài sản số dài hạn. Một website chuẩn SEO cần được rà soát từ crawlability, indexability, cấu trúc URL, redirect, on-page, internal link, tốc độ tải, mobile-first, schema, EEAT, tracking đến bảo mật và tài sản bàn giao. Các hạng mục quan trọng gồm robots.txt không chặn nhầm tài nguyên, sitemap XML chỉ chứa URL canonical có giá trị, trang cần SEO không bị noindex, canonical đúng template, redirect 301 chuẩn cho URL cũ, không có lỗi 404/5xx nghiêm trọng và cấu trúc internal link giúp bot lẫn người dùng tìm thấy trang quan trọng trong ít click. Song song, từng template như trang chủ, danh mục, sản phẩm, dịch vụ, blog và landing page phải có title, meta description, H1, heading, nội dung khác biệt, ảnh tối ưu và schema phù hợp. Website cũng cần đạt hiệu suất ổn định trên mobile, kiểm soát Core Web Vitals, popup, form, CTA và khả năng truy cập cơ bản. Cuối cùng, việc bàn giao phải bao gồm quyền sở hữu domain, hosting, DNS, CMS, GSC, GA4, GTM, database, code repository, backup, tài liệu vận hành và biên bản ghi rõ lỗi còn tồn tại, mức ưu tiên, người phụ trách, deadline, phạm vi bảo hành để tránh rủi ro sau khi nghiệm thu.

Checklist bàn giao website chuẩn SEO cần bao phủ kỹ thuật, nội dung, dữ liệu và quyền truy cập

Checklist bàn giao website chuẩn SEO cần được xây dựng như một tài liệu nghiệm thu kỹ thuật, bao phủ đồng thời kỹ thuật, nội dung, dữ liệu và quyền truy cập. Trọng tâm là đảm bảo bot có thể crawl và index ổn định, website đạt hiệu suất tốt, hệ thống tracking đo lường chính xác và lớp quản trị vận hành an toàn, minh bạch. Mỗi nhóm hạng mục nên có phạm vi, phương pháp, kết quả định lượng và bằng chứng rõ ràng, gắn với công cụ kiểm tra cụ thể để đáp ứng tiêu chí EEAT. Biên bản bàn giao đóng vai trò “hợp đồng kỹ thuật”, ghi rõ trạng thái từng hạng mục, mức ưu tiên, người phụ trách và deadline, đồng thời phân loại lỗi theo mức ảnh hưởng đến crawl, index, traffic và chuyển đổi, tránh nghiệm thu chỉ dựa trên giao diện đẹp. Khi nghiệm thu website chuẩn SEO, doanh nghiệp không nên chỉ kiểm tra giao diện mà cần đánh giá toàn bộ nền tảng vận hành. Thiết kế web phải được bàn giao kèm trạng thái kỹ thuật, cấu trúc nội dung, tracking, quyền quản trị và bằng chứng kiểm tra để tránh phát sinh lỗi sau khi website chính thức hoạt động.

Website cần được nghiệm thu theo crawlability, indexability, performance, tracking và quản trị vận hành

Một checklist bàn giao website chuẩn SEO ở mức chuyên nghiệp cần được xây dựng như một tài liệu nghiệm thu kỹ thuật, không chỉ dừng lại ở việc “nhìn cho đẹp” hay “chạy được”. Checklist phải bao phủ đầy đủ các nhóm hạng mục: crawlability (khả năng bot truy cập và thu thập dữ liệu), indexability (khả năng được lập chỉ mục ổn định, không bị chặn hoặc xung đột tín hiệu), performance (tốc độ, Core Web Vitals và trải nghiệm thực tế của người dùng), tracking (đo lường dữ liệu hành vi, kênh, chuyển đổi) và quản trị vận hành (bảo mật, phân quyền, backup, quy trình vận hành). Cách nghiệm thu theo tài liệu kỹ thuật phù hợp với nguyên tắc quản trị chất lượng hệ thống thông tin. DeLone và McLean (2003) cho rằng thành công của một hệ thống số phụ thuộc vào chất lượng hệ thống, chất lượng thông tin và tác động thực tế đến người dùng. Với website chuẩn SEO, checklist bàn giao phải chứng minh được website không chỉ hiển thị đúng giao diện, mà còn có khả năng crawl, index, tải nhanh, đo lường chuyển đổi và vận hành an toàn. Một website chưa có bằng chứng nghiệm thu kỹ thuật chưa thể xem là tài sản SEO hoàn chỉnh, vì các lỗi ẩn có thể chỉ lộ ra sau khi traffic và chiến dịch marketing bắt đầu chạy.

Mỗi nhóm hạng mục này đều ảnh hưởng trực tiếp đến khả năng website xuất hiện trên Google, chất lượng traffic và tỷ lệ chuyển đổi. Khi nghiệm thu, chủ website cần yêu cầu đơn vị triển khai cung cấp báo cáo chi tiết hoặc biên bản thể hiện rõ từng nhóm đã được kiểm tra, test và tối ưu đến mức nào, kèm theo log hoặc bằng chứng kỹ thuật. Ở mức chuyên sâu, mỗi nhóm nên có:

• Phạm vi kiểm tra: liệt kê rõ các yếu tố đã được test (ví dụ: robots.txt, sitemap, canonical, schema, CWV…)
• Phương pháp kiểm tra: test tự động, test thủ công, test trên staging hay production
• Kết quả định lượng: số lượng URL crawl được, % URL index, điểm PageSpeed, số event tracking hoạt động…
• Bằng chứng: screenshot, file export, log server, report PDF

Việc lưu báo cáo, log và ảnh chụp kiểm tra giúp tăng tính truy xuất trách nhiệm trong quá trình vận hành website. Trong quản trị chất lượng phần mềm, Sommerville (2016) nhấn mạnh rằng kiểm thử và tài liệu hóa kết quả là cơ sở để xác nhận hệ thống đáp ứng yêu cầu đã đặt ra. Với website SEO, bằng chứng nghiệm thu nên bao gồm kết quả crawl, trạng thái index, báo cáo Core Web Vitals, cấu hình tracking, sitemap, robots.txt, canonical và phân quyền tài khoản. Những dữ liệu này giúp chủ website đối chiếu khi có lỗi phát sinh, tránh tình trạng tranh cãi cảm tính giữa đội dev, SEO và đơn vị triển khai.

Để đảm bảo tính minh bạch và chuẩn EEAT, chủ website nên yêu cầu nhà phát triển mô tả rõ công cụ và phương pháp đã dùng để kiểm tra, kèm theo cấu hình cụ thể. Ví dụ:

• Dùng Google Search Console để test index, kiểm tra Coverage, Page indexing, sitemaps, manual actions, và dùng URL Inspection để kiểm tra từng URL quan trọng (trang chủ, category, landing page, money page).
• Dùng PageSpeed Insights và Lighthouse để đo Core Web Vitals trên cả mobile và desktop, phân tích LCP, FID/INP, CLS, TTFB, đồng thời ghi nhận phiên bản report tại thời điểm bàn giao.
• Dùng Screaming Frog hoặc Sitebulb để crawl toàn bộ cấu trúc website, kiểm tra depth, internal linking, status code, canonical, meta robots, hreflang (nếu có), structured data, và xuất báo cáo chi tiết.
• Dùng GA4 và Google Tag Manager để thiết lập tracking, event, conversion, cross-domain tracking (nếu có), đồng thời kiểm tra bằng chế độ preview/debug và so sánh số liệu với server (nếu có backend log).

Mỗi kết quả kiểm tra nên được lưu lại dưới dạng file, ảnh chụp màn hình hoặc báo cáo PDF, gắn timestamp và môi trường (staging/production), tránh tình trạng nghiệm thu “bằng miệng” mà không có tài liệu đối chiếu sau này. Với các dự án lớn, nên có một thư mục chung (Google Drive, Notion, hệ thống quản lý dự án) lưu toàn bộ artifact nghiệm thu để phục vụ audit về sau.

Ở nhóm quản trị vận hành, ngoài việc website chạy ổn định, cần kiểm tra thêm:

• Quyền sở hữu domain, hosting, DNS, tài khoản CDN, email gửi hệ thống (SMTP, transactional email).
• Quyền truy cập Search Console, GA4, Tag Manager, các công cụ SEO bên thứ ba (nếu có) phải thuộc về chủ website, không dùng tài khoản cá nhân của agency.
• Cấu hình backup tự động, tần suất backup, quy trình restore, và test restore ít nhất một lần trên môi trường staging.
• Các lớp bảo mật cơ bản: HTTPS, HSTS (nếu phù hợp), firewall ứng dụng (WAF), giới hạn login, cập nhật CMS/plugin, phân quyền user theo nguyên tắc least privilege.

Biên bản bàn giao nên ghi rõ hạng mục đạt, chưa đạt, lỗi cần sửa và người chịu trách nhiệm

Một website chuẩn SEO cần có biên bản bàn giao chi tiết đóng vai trò như “hợp đồng kỹ thuật” giữa chủ website và đơn vị triển khai. Trong biên bản, mỗi hạng mục phải được đánh dấu rõ ràng: đạt, chưa đạt, cần theo dõi, kèm theo ghi chú kỹ thuật khi cần. Việc này giúp tất cả các bên có cùng nhận thức về trạng thái thực tế của website tại thời điểm bàn giao. Biên bản bàn giao nên vận hành như một bảng kiểm soát rủi ro, không chỉ là danh sách công việc. Boehm (1981) chỉ ra rằng lỗi phần mềm càng được phát hiện muộn thì chi phí sửa càng cao, đặc biệt khi lỗi đã lan vào kiến trúc hệ thống hoặc quy trình vận hành. Với website, lỗi canonical sai, robots.txt chặn nhầm, tracking thiếu sự kiện hoặc redirect hỏng có thể làm mất traffic, sai dữ liệu và tăng chi phí sửa sau bàn giao. Mỗi lỗi cần có owner, deadline và mức độ ảnh hưởng, để đảm bảo vấn đề kỹ thuật được xử lý trước khi website bước vào giai đoạn tăng trưởng traffic.

Biên bản không chỉ liệt kê lỗi, mà còn phải ghi nhận mức độ ưu tiên (priority) và người chịu trách nhiệm xử lý (owner). Ở mức chuyên sâu, nên gắn thêm:

• Impact: lỗi ảnh hưởng đến crawl, index, traffic, conversion hay bảo mật.
• Effort: ước lượng độ khó/khối lượng công việc (low/medium/high) để đội dev và SEO lên kế hoạch.
• Environment: lỗi xảy ra trên staging, production hay cả hai.

Biên bản nên có cấu trúc dạng bảng, phân loại theo nhóm kỹ thuật, nội dung, dữ liệu và quyền truy cập. Mỗi lỗi hoặc hạng mục chưa đạt cần có mô tả ngắn, rõ ràng, có thể kèm ví dụ URL cụ thể, chẳng hạn: “Trang sản phẩm chưa có schema Product cho các thuộc tính price, availability”, “Một số URL filter đang index gây trùng lặp nội dung và lãng phí crawl budget”, “Core Web Vitals trên mobile chưa đạt ngưỡng tốt cho nhóm URL category”.

Bên cạnh đó, cần ghi rõ deadline xử lý và phạm vi bảo hành mà đơn vị triển khai cam kết: lỗi nào nằm trong phạm vi fix miễn phí, lỗi nào phát sinh do thay đổi yêu cầu, thời gian phản hồi (SLA) khi có sự cố SEO nghiêm trọng (ví dụ: traffic rơi đột ngột do lỗi kỹ thuật). Điều này giúp chủ website có cơ sở yêu cầu hỗ trợ khi cần và giảm thiểu tranh cãi về sau.

Để quản lý hiệu quả, biên bản bàn giao nên được đồng bộ vào hệ thống quản lý task (Jira, Trello, Asana…) với cùng cấu trúc: hạng mục, trạng thái, priority, assignee, due date. Mỗi lần fix lỗi, cần cập nhật trạng thái và nếu có thay đổi lớn (ví dụ: đổi cấu trúc URL, đổi logic canonical), nên tạo thêm bản cập nhật tài liệu kỹ thuật để đội SEO nắm được.

Không nên nhận bàn giao chỉ dựa trên giao diện đẹp hoặc website chạy được trên trình duyệt

Nhiều dự án website thất bại về SEO vì chủ doanh nghiệp chỉ nghiệm thu dựa trên giao diện và việc website “chạy được” trên trình duyệt. Một website có thể nhìn rất đẹp, animation mượt, hiệu ứng bắt mắt, nhưng lại:

• Bị chặn index bởi robots.txt hoặc meta robots noindex.
• Có cấu trúc URL lộn xộn, không thân thiện, không phản ánh cấu trúc thông tin.
• Tốc độ chậm, Core Web Vitals kém, đặc biệt trên mobile.
• Không có tracking chuyển đổi, không đo được hiệu quả kênh marketing.

Giao diện đẹp không đảm bảo website có chất lượng sử dụng và chất lượng kỹ thuật tốt. Nielsen (1993) cho rằng tính khả dụng của hệ thống phải được đánh giá dựa trên khả năng người dùng hoàn thành nhiệm vụ hiệu quả, ít lỗi và ít tốn nỗ lực, chứ không chỉ dựa vào cảm nhận thị giác. Với SEO, website còn phải được Googlebot hiểu đúng, tải nhanh, có cấu trúc nội dung rõ và đo được chuyển đổi. Một trang nhìn đẹp nhưng bị noindex, chậm trên mobile hoặc thiếu tracking vẫn là nghiệm thu thất bại, vì nó không phục vụ được mục tiêu kinh doanh sau khi ra mắt.

Khi đó, toàn bộ chi phí marketing sau này sẽ bị đội lên vì phải sửa lỗi nền tảng hoặc phải chạy quảng cáo bù cho phần organic không hiệu quả. Việc “đập đi xây lại” hạ tầng SEO sau khi website đã chạy thường tốn kém hơn rất nhiều so với việc làm đúng ngay từ giai đoạn bàn giao.

Trong quá trình nghiệm thu, cần tách bạch rõ hai lớp: UI/UX (trải nghiệm người dùng) và SEO & kỹ thuật. UI/UX tập trung vào layout, màu sắc, flow thao tác, còn SEO & kỹ thuật tập trung vào cách Google và các công cụ tìm kiếm hiểu, crawl, index và đánh giá website. Giao diện chỉ là phần “bề nổi”, còn SEO là phần “hạ tầng” quyết định website có thể phát triển bền vững hay không.

Chủ website nên yêu cầu một báo cáo SEO kỹ thuật tối thiểu tại thời điểm bàn giao, bao gồm:

• Trạng thái index: số URL hợp lệ, URL bị loại trừ, lỗi server, soft 404, canonical alternative…
• Sitemap: số sitemap, số URL trong sitemap, tình trạng submit và index trong Search Console.
• Robots.txt: rule chặn/cho phép, kiểm tra với các URL quan trọng.
• Canonical: logic canonical cho category, product, filter, pagination.
• Redirect: mapping redirect 301, xử lý HTTP/HTTPS, www/non-www, trailing slash, redirect chain/loop.
• Core Web Vitals: LCP, CLS, INP/FID cho nhóm URL chính, đặc biệt trên mobile.
• Structured data: schema Organization, WebSite, Breadcrumb, Product, Article… tùy loại website.
• Tracking: GA4, event, conversion, cross-domain (nếu có), liên kết với Search Console.
• Bảo mật cơ bản: HTTPS, redirect HTTP → HTTPS, không lộ trang admin, không index môi trường staging.

Nếu bất kỳ hạng mục quan trọng nào trong số này chưa được xử lý hoặc chưa đạt ngưỡng chấp nhận được, không nên ký nghiệm thu hoàn toàn. Có thể nghiệm thu có điều kiện, kèm danh sách việc phải hoàn thành trước khi thanh toán đủ hoặc trước khi chạy chiến dịch marketing lớn.

Mỗi lỗi SEO cần được phân loại theo mức ảnh hưởng đến crawl, index, traffic và chuyển đổi

Khi rà soát website trước bàn giao, số lượng lỗi SEO có thể khá nhiều, đặc biệt với các website lớn hoặc có nhiều template khác nhau. Để tránh rơi vào tình trạng “quá tải” và không biết nên xử lý gì trước, cần phân loại lỗi theo mức ảnh hưởng đến bốn yếu tố: crawl, index, traffic và chuyển đổi. Cách tiếp cận này giúp đội ngũ ưu tiên đúng việc, tránh sa đà vào những lỗi nhỏ nhưng tốn nhiều thời gian. Phân loại lỗi theo tác động giúp đội ngũ ưu tiên xử lý dựa trên rủi ro kinh doanh. Kaplan và Norton (1992) cho rằng hệ thống đo lường hiệu quả cần liên kết nhiều góc nhìn: tài chính, khách hàng, quy trình nội bộ và năng lực vận hành. Áp dụng vào SEO, một lỗi robots.txt chặn thư mục sản phẩm có tác động khác hoàn toàn với lỗi thiếu alt ở vài ảnh phụ. Lỗi ảnh hưởng đến crawl và index có thể làm mất khả năng xuất hiện; lỗi ảnh hưởng đến traffic làm giảm cơ hội tiếp cận; lỗi ảnh hưởng đến chuyển đổi làm thất thoát doanh thu. Không phải mọi lỗi SEO đều có cùng mức ưu tiên.

Những lỗi chặn bot, noindex nhầm, redirect sai hoặc lỗi 5xx thường được xếp vào nhóm ưu tiên cao nhất vì có thể khiến website không xuất hiện trên Google hoặc mất traffic đột ngột. Ở mức chuyên sâu, có thể chia thành:

• Lỗi blocking: robots.txt chặn thư mục quan trọng, meta noindex trên template chính, canonical trỏ sai domain.
• Lỗi phá vỡ cấu trúc: redirect loop, redirect chain dài, thay đổi URL không có redirect, 404 hàng loạt.
• Lỗi làm nhiễu tín hiệu: trùng lặp nội dung lớn, canonical mâu thuẫn, nhiều phiên bản URL cùng nội dung.

Các lỗi liên quan đến tối ưu on-page, structured data hoặc Core Web Vitals có thể được xếp vào nhóm ưu tiên trung bình, nhưng vẫn cần deadline rõ ràng vì chúng ảnh hưởng trực tiếp đến khả năng cạnh tranh trên SERP và trải nghiệm người dùng. Những lỗi nhỏ như thiếu alt ở một số ảnh phụ, thiếu meta description ở vài trang ít quan trọng có thể xử lý sau, miễn là không ảnh hưởng lớn đến trải nghiệm và khả năng index.

Cách phân loại này giúp cả đội dev, SEO và chủ doanh nghiệp có chung ngôn ngữ, tránh tranh luận cảm tính. Khi trao đổi, có thể quy ước:

• Priority Very High: lỗi có thể làm mất index, mất traffic lớn, gây lỗi hiển thị nghiêm trọng.
• Priority High: lỗi ảnh hưởng rõ rệt đến traffic, trải nghiệm hoặc chuyển đổi trên nhóm trang quan trọng.
• Priority Medium: lỗi tối ưu, cải thiện hiệu suất, tăng CTR, tăng khả năng hiểu nội dung.
• Priority Low: lỗi nhỏ, mang tính “nice to have”, xử lý khi có nguồn lực dư.

Khi ghi nhận lỗi trong biên bản bàn giao, nên gắn thẳng từng lỗi với nhóm ảnh hưởng chính (crawl/index/traffic/conversion) để ban lãnh đạo dễ hiểu mức độ rủi ro. Điều này giúp việc ra quyết định ưu tiên và phân bổ ngân sách, nguồn lực trở nên rõ ràng, có cơ sở hơn thay vì dựa trên cảm tính hoặc đánh giá chủ quan.

Kiểm tra crawlability trước khi nhận website

Kiểm tra crawlability trước khi nhận website cần tập trung vào khả năng truy cập và khám phá nội dung của bot tìm kiếm. Trước hết, phải đảm bảo file robots.txt không chặn nhầm trang quan trọng, tài nguyên CSS, JavaScript, font hoặc API phục vụ render, đồng thời dùng công cụ crawl và Google Search Console để phát hiện lỗi chặn, lãng phí crawl budget. Tiếp theo, cấu trúc điều hướng (menu, breadcrumb, footer, internal link) phải dùng thẻ a href chuẩn, không phụ thuộc hoàn toàn vào JS, giúp bot dễ dàng follow link. Các URL quan trọng cần nằm trong phạm vi 2–3 click từ trang chủ hoặc hub page, không bị “mồ côi” ngoài cấu trúc internal link. Cuối cùng, phân trang, danh mục, bài viết và sản phẩm phải có URL tĩnh, pagination rõ ràng, tránh infinite scroll thuần JS gây mất index nội dung.

Robots.txt không chặn nhầm trang quan trọng, CSS, JavaScript hoặc tài nguyên cần render

Tập tin robots.txt là lớp “cổng” đầu tiên quyết định khả năng crawl của toàn bộ website, vì vậy khi nghiệm thu cần kiểm tra ở mức cấu hình chi tiết chứ không chỉ nhìn qua cho có. Một sai sót nhỏ như đặt nhầm Disallow: / cho user-agent chung (ví dụ User-agent: *) có thể khiến toàn bộ site bị chặn khỏi Google chỉ trong một lần deploy. Ngoài ra, việc chặn nhầm thư mục chứa CSS, JavaScript, font, hình ảnh sprite hoặc API endpoint phục vụ render cũng có thể khiến Googlebot không render được DOM cuối cùng, dẫn đến hiểu sai layout, ẩn nội dung chính hoặc đánh giá thấp Core Web Vitals. Robots.txt cần được kiểm tra cùng khả năng render vì Google không chỉ đọc URL mà còn cần hiểu nội dung hiển thị cuối cùng. Berners-Lee, Hendler và Lassila (2001) nhấn mạnh giá trị của web nằm ở việc thông tin và quan hệ giữa các phần tử có thể được máy diễn giải. Nếu CSS, JavaScript hoặc tài nguyên render bị chặn, bot có thể không thấy menu, nội dung chính, sản phẩm, CTA hoặc dữ liệu có cấu trúc. Chặn nhầm tài nguyên render có thể làm Google hiểu sai trang, dù người dùng vẫn thấy giao diện bình thường trên trình duyệt. Vì vậy, nghiệm thu robots.txt phải đi kèm test render bằng công cụ crawl và Google Search Console.

Khi kiểm tra, cần đọc kỹ từng block user-agent trong robots.txt:

• Xác định có block riêng cho Googlebot, Googlebot-Image, Googlebot-Mobile, AdsBot… hay không, và các block này có vô tình chặn thư mục quan trọng không.
• Đảm bảo không có Disallow: / áp dụng cho user-agent chung, trừ khi đó là môi trường staging hoặc pre-production đã được kiểm soát bằng bảo mật khác (basic auth, IP whitelist).
• Không chặn toàn bộ các thư mục như /wp-content/themes/, /wp-content/uploads/, /assets/, /static/, /dist/ nếu trong đó có CSS, JS, hình ảnh, font đang được sử dụng để render nội dung chính.
• Nếu cần chặn, nên chặn có chọn lọc các thư mục thực sự không cần crawl như /tmp/, /cgi-bin/, /private/, hoặc các file test, log, script nội bộ.

Ngoài việc mở file robots.txt trên trình duyệt, nên dùng công cụ crawl chuyên dụng (Screaming Frog, Sitebulb, JetOctopus…) để mô phỏng hành vi bot và kiểm tra:

• Các URL quan trọng (trang chủ, category chính, landing page, sản phẩm top, bài viết pillar) có bị trả về trạng thái Blocked by robots.txt hay không.
• Các file CSS, JS, hình ảnh lớn, font có bị chặn trong quá trình crawl tài nguyên (resource crawl) hay không.

Nếu website đã kết nối Google Search Console, nên vào Settings > Crawl stats để xem:

• Tỷ lệ yêu cầu bị trả về lỗi 403, 404, 5xx hoặc bị chặn bởi robots.txt.
• Danh sách host và path mà Googlebot crawl nhiều nhất, từ đó phát hiện xem có đang lãng phí crawl budget vào các URL không cần thiết (ví dụ URL filter, parameter, session ID).

Với các website SPA, PWA hoặc sử dụng nhiều JavaScript (React, Vue, Angular, Next.js, Nuxt…), việc chặn nhầm file JS hoặc endpoint API có thể khiến Google không thể render nội dung sau khi hydrate. Cần đảm bảo:

• Các bundle JS chính (ví dụ main.js, app.js, vendor.js) không bị chặn.
• Các route quan trọng có thể được render ở mức HTML cơ bản (SSR hoặc pre-render) để giảm phụ thuộc vào JS khi bot crawl.
• Nếu dùng dynamic rendering hoặc giải pháp render riêng cho bot, cần test bằng user-agent Googlebot để chắc chắn không bị robots.txt chặn nhầm.

Menu, breadcrumb, footer và internal link phải crawlable bằng thẻ a href

Cấu trúc điều hướng là “xương sống” của crawlability. Menu chính, breadcrumb, footer và các block internal link trong nội dung phải được xây dựng bằng thẻ a href HTML chuẩn với URL rõ ràng, không phụ thuộc hoàn toàn vào JavaScript onclick, event listener hoặc các component custom mà không sinh ra anchor HTML. Nếu navigation chỉ hoạt động khi JS chạy, nhưng không có fallback HTML, Googlebot có thể không nhìn thấy hoặc không follow được các link quan trọng, đặc biệt trong trường hợp render bị giới hạn tài nguyên. Liên kết nội bộ bằng thẻ HTML chuẩn là nền tảng để bot khám phá và hiểu cấu trúc website. Brin và Page (1998) cho thấy cấu trúc hyperlink là một tín hiệu quan trọng để đánh giá mối quan hệ và mức độ quan trọng của tài liệu trên web. Với website bàn giao, menu, breadcrumb, footer, block bài liên quan và liên kết trong nội dung nên dùng thẻ a href rõ ràng, có anchor text mô tả đúng trang đích. Nếu liên kết chỉ tồn tại qua JavaScript hoặc nút onclick, crawler có thể không phát hiện đầy đủ URL quan trọng. Internal link không chỉ là điều hướng UX, mà còn là đường dẫn phân phối tín hiệu SEO.

Khi nghiệm thu, cần kiểm tra kỹ:

• Menu desktop và mobile có sử dụng <a href="..."> cho từng item, hay chỉ dùng <div onclick="...">, router-link không render thành anchor, hoặc các component SPA không tạo ra URL tĩnh.
• Breadcrumb hiển thị trên từng trang category, bài viết, sản phẩm có đầy đủ anchor cho từng cấp (Home > Category > Subcategory > Page) và không bị render bằng JS thuần mà không có HTML sẵn.
• Footer chứa các link đến trang chính sách, trang giới thiệu, category quan trọng, sitemap HTML… đều là anchor crawlable.
• Các internal link trong nội dung bài viết, mô tả sản phẩm, block “bài viết liên quan”, “sản phẩm liên quan” cũng phải là anchor chuẩn, không bị ẩn trong JS hoặc iframe.

Nên dùng công cụ crawl như Screaming Frog để:

• Chạy crawl toàn site và so sánh số lượng URL được phát hiện qua internal link với số lượng URL thực tế trong sitemap hoặc database.
• Nếu số lượng URL phát hiện được thấp hơn nhiều so với kỳ vọng, có thể navigation đang bị ẩn sau JS, hoặc các link được gắn thuộc tính, event khiến bot không follow được.

Cần kiểm tra thêm:

• Các link trong menu, breadcrumb, footer không bị gắn rel="nofollow" một cách vô lý, vì điều này làm suy yếu luồng internal link và ảnh hưởng đến phân bổ PageRank nội bộ.
• Các link quan trọng không bị chặn bởi thuộc tính data-no-follow hoặc các cơ chế custom khác mà hệ thống crawl không hiểu.
• Không sử dụng quá nhiều link dạng JavaScript pseudo (ví dụ href="javascript:void(0)") cho các mục cần được index.

URL quan trọng cần truy cập được trong ít tầng click từ trang chủ hoặc hub page

Một website chuẩn SEO cần đảm bảo các URL quan trọng (trang dịch vụ chính, category lớn, landing page chiến lược, bài viết pillar, collection quan trọng) có thể được truy cập trong khoảng 2–3 click từ trang chủ hoặc từ các hub page chính. Crawl depth càng thấp, khả năng được bot ghé thăm thường xuyên và nhận internal link càng cao, từ đó tăng cơ hội index nhanh và duy trì thứ hạng ổn định.

Khi audit trước nghiệm thu, nên:

• Sử dụng tính năng Crawl depth trong các công cụ audit để đo số tầng click từ trang chủ đến từng URL.
• Lọc ra các URL quan trọng (theo danh sách từ khóa, landing page SEO, trang mang lại chuyển đổi) và kiểm tra depth thực tế của chúng.
• Nếu phát hiện các trang này có depth > 3 (ví dụ 4–6 click), cần đánh giá lại cấu trúc điều hướng.

Các cách rút ngắn depth cho URL quan trọng:

• Đưa trực tiếp vào menu chính hoặc mega menu nếu phù hợp với trải nghiệm người dùng.
• Thêm vào breadcrumb logic hơn (ví dụ gom vào category/hub phù hợp thay vì để lẻ loi trong một nhánh sâu).
• Tạo hoặc tối ưu hub page (trang tổng hợp chủ đề) và đặt internal link rõ ràng từ hub đến các trang con chiến lược.
• Chèn internal link trong nội dung từ các bài viết có traffic cao, trang top để đẩy sức mạnh đến các URL đang nằm sâu.

Việc tối ưu depth không chỉ giúp bot crawl hiệu quả hơn mà còn cải thiện UX: người dùng có thể tìm thấy nội dung quan trọng nhanh hơn, giảm bounce rate và tăng thời gian onsite, gián tiếp hỗ trợ SEO.

Website không có orphan page quan trọng bị bỏ ngoài cấu trúc điều hướng

Orphan page là những trang không có bất kỳ internal link nào trỏ đến, khiến bot và người dùng gần như không thể tìm thấy nếu không biết URL trực tiếp hoặc không truy cập từ quảng cáo. Trong quá trình thiết kế, chạy chiến dịch hoặc nhập nội dung, rất dễ phát sinh orphan page như landing page quảng cáo, trang khuyến mãi, trang test A/B, trang tạo tạm cho đối tác. Nếu những trang này có giá trị SEO hoặc chuyển đổi, việc để chúng “mồ côi” là một lãng phí lớn về crawl budget và authority nội bộ.

Trước khi nhận bàn giao, nên yêu cầu đơn vị triển khai:

• Chạy một lượt crawl toàn site bằng công cụ chuyên dụng, sau đó xuất danh sách URL mà crawler phát hiện được qua internal link.
• Đối chiếu danh sách này với:
  • Sitemap XML (hoặc nhiều sitemap nếu site lớn).
  • Danh sách URL trong database CMS hoặc hệ thống sản phẩm.
  • Dữ liệu truy cập trong GA4, log server hoặc các công cụ analytics khác.

Các URL xuất hiện trong sitemap, database hoặc GA4 nhưng không xuất hiện trong kết quả crawl nội bộ thường là ứng viên orphan page. Với các trang này, cần phân loại:

• Trang quan trọng cho SEO hoặc chuyển đổi:
  • Gắn vào cấu trúc điều hướng thông qua menu, category, tag, hub page hoặc internal link trong nội dung.
  • Đảm bảo có ít nhất một (tốt hơn là nhiều) internal link từ các trang liên quan về mặt chủ đề.
• Trang chỉ phục vụ chiến dịch ngắn hạn, test, hoặc không còn giá trị:
  • Cân nhắc gắn noindex nếu vẫn cần dùng cho quảng cáo nhưng không muốn index.
  • Hoặc redirect 301 về trang phù hợp (category, landing page mới) nếu nội dung đã được thay thế.

Quản lý orphan page tốt giúp tập trung crawl budget vào các URL có giá trị, tránh tình trạng Googlebot lãng phí tài nguyên vào các trang rời rạc, ít liên quan, đồng thời tối ưu cấu trúc internal link để tăng sức mạnh cho các cụm chủ đề chính.

Phân trang, danh mục, bài viết và sản phẩm cần có đường dẫn crawl rõ ràng

Các khu vực như category, listing sản phẩm, blog thường sử dụng phân trang (pagination) để chia nhỏ danh sách dài. Nếu phân trang được triển khai bằng JS load more hoặc infinite scroll mà không có URL riêng cho từng trang, bot có thể chỉ crawl được phần nội dung hiển thị ban đầu (page 1), bỏ sót hàng loạt sản phẩm hoặc bài viết phía sau. Điều này đặc biệt nguy hiểm với e-commerce hoặc blog lớn, vì phần lớn nội dung có thể không bao giờ được index đầy đủ.

Cần đảm bảo:

• Mỗi trang phân trang có URL tĩnh, ví dụ:
  • /blog/page/2/, /blog/page/3/
  • /category/ao-thun?page=2, /category/ao-thun?page=3
• Các link đến trang phân trang tiếp theo/trước đó được đặt trong HTML (ví dụ block pagination ở cuối listing) với <a href="..."> rõ ràng.
• Nếu sử dụng infinite scroll, cần có cơ chế fallback pagination cho bot (ví dụ hiển thị link “Xem thêm” với URL tĩnh, hoặc cấu hình theo hướng dẫn của Google cho infinite scroll).

Đối với website thương mại điện tử, mỗi sản phẩm và bài viết cần:

• Có URL riêng, tĩnh, không phụ thuộc hoàn toàn vào tham số filter hoặc session.
• Nằm trong cấu trúc thư mục hợp lý (ví dụ /danh-muc/san-pham/ten-san-pham hoặc /blog/chuyen-muc/ten-bai-viet), giúp bot hiểu mối quan hệ chủ đề.
• Không bị trùng lặp nội dung do nhiều URL khác nhau dẫn đến cùng một sản phẩm (ví dụ vừa có URL dạng canonical, vừa có URL kèm filter).

Các filter như màu sắc, kích thước, thương hiệu, sắp xếp, khoảng giá… nếu không kiểm soát tốt sẽ tạo ra vô số URL trùng lặp hoặc gần trùng lặp, gây loãng crawl budget. Khi nghiệm thu, cần:

• Test việc thay đổi filter và quan sát URL trên trình duyệt:
  • Nếu mỗi thao tác filter tạo ra một parameter mới (ví dụ ?color=red&size=m&sort=price_asc), cần có chiến lược kiểm soát index (robots.txt, noindex, canonical).
  • Nếu filter không thay đổi URL (chỉ load bằng JS), cần đảm bảo các URL chính vẫn chứa đầy đủ sản phẩm quan trọng trong vài trang đầu của listing.
• Dùng công cụ crawl để xác nhận bot nhìn thấy cấu trúc phân trang và sản phẩm tương tự như người dùng:
  • Kiểm tra số lượng URL sản phẩm, bài viết được phát hiện.
  • Kiểm tra trạng thái indexability (có bị noindex, canonical sai, blocked by robots.txt hay không).

Khi cấu trúc phân trang và URL sản phẩm/bài viết được thiết kế rõ ràng, bot có thể crawl sâu và rộng hơn mà không lãng phí tài nguyên vào các biến thể URL không cần thiết, đồng thời đảm bảo toàn bộ inventory nội dung và sản phẩm có cơ hội được index và xếp hạng.

Kiểm tra indexability và trạng thái hiển thị trên Google

Kiểm tra indexability và trạng thái hiển thị trên Google là bước nghiệm thu kỹ thuật quan trọng để đảm bảo website có thể được thu thập, hiểu và xếp hạng ổn định. Trọng tâm là xác nhận mọi URL quan trọng đều indexable, không bị chặn bởi meta robots, x-robots-tag hay canonical sai, đồng thời trả về HTTP status 200 nhất quán. Song song, cần chủ động kiểm soát index cho các nhóm URL không mang giá trị SEO như search nội bộ, filter rác, giỏ hàng, tài khoản… nhằm tránh loãng chỉ mục và lãng phí crawl budget. Hệ thống canonical phải được cấu hình chuẩn cho từng template trang, hỗ trợ hợp nhất tín hiệu về đúng URL chuẩn. XML sitemap chỉ nên chứa URL canonical, indexable và có giá trị SEO, được khai báo đầy đủ trong Google Search Console. Cuối cùng, GSC cần được xác minh và dùng URL Inspection để kiểm tra mẫu, đảm bảo Google có thể crawl, render và index website đúng như mong muốn.

Trang cần index phải trả status code 200 và không có meta robots noindex

Indexability không chỉ là điều kiện “có cũng được” mà là tầng kỹ thuật nền tảng để mọi nỗ lực SEO khác phát huy hiệu quả. Một trang chỉ thực sự có khả năng xuất hiện trên Google khi đáp ứng đồng thời các điều kiện:

• Trả về HTTP status 200 ổn định (không chập chờn 5xx, không redirect vòng lặp).
• Không bị chặn bởi meta robots với thuộc tính noindex.
• Không bị chặn bởi x-robots-tag trên HTTP header.
• Không bị canonical trỏ sang một URL khác không phải là phiên bản chuẩn cần xếp hạng.

Indexability là điều kiện nền để nội dung có cơ hội cạnh tranh trên kết quả tìm kiếm. Saracevic (2007) cho rằng tính liên quan trong truy hồi thông tin phụ thuộc vào việc hệ thống có thể nhận diện, lưu trữ và đối chiếu tài liệu với nhu cầu người dùng. Nếu URL quan trọng trả 404, 5xx, bị noindex hoặc canonical sang trang khác, Google không thể xem đó là tài liệu hợp lệ cho truy vấn mục tiêu. Vì vậy, các trang chủ, dịch vụ, sản phẩm, category, bài pillar và landing page chuyển đổi cần được kiểm tra bằng cả mã HTTP, meta robots, x-robots-tag và canonical. Trang không index được thì không có giá trị SEO thực tế.

Trong quá trình nghiệm thu, cần xây dựng một danh sách URL mẫu đại diện cho từng loại trang quan trọng: trang chủ, category, sản phẩm/dịch vụ, blog/bài viết, landing page chiến dịch. Với mỗi URL, nên thực hiện hai lớp kiểm tra:

• Kiểm tra bằng URL Inspection trong Google Search Console: xem Google có thể crawl, render và index hay không, có phát hiện chặn bởi robots hay canonical không.
• Kiểm tra HTTP header và mã nguồn HTML bằng công cụ như curl, DevTools, hoặc crawler chuyên dụng để xác nhận status code, x-robots-tag, meta robots, canonical.

Nếu phát hiện bất kỳ trang quan trọng nào trả về 3xx (đặc biệt là redirect không cần thiết), 4xx (404, 410) hoặc 5xx (lỗi server), cần yêu cầu xử lý ngay vì:

• 3xx không cần thiết làm mất tín hiệu trực tiếp cho URL đích, tăng độ trễ index.
• 4xx khiến Google loại bỏ URL khỏi chỉ mục, mất hoàn toàn khả năng xếp hạng.
• 5xx lặp lại nhiều lần khiến Google giảm crawl rate, ảnh hưởng toàn site.

Với meta robots, cần đặc biệt chú ý các biến thể:

• <meta name="robots" content="noindex, nofollow">
• <meta name="robots" content="noindex, follow">
• x-robots-tag: noindex trên HTTP header (thường cấu hình ở server hoặc CDN).

Một số CMS hoặc plugin SEO có cơ chế tự động gắn noindex cho:

• Môi trường staging, UAT, dev.
• Chế độ “bảo trì”, “coming soon”, “private mode”.
• Site đang đặt password bảo vệ bằng HTTP Auth.

Khi chuyển sang môi trường production, cần có checklist kỹ thuật để đảm bảo:

• Đã tắt toàn bộ cấu hình noindex toàn site.
• Không còn rule x-robots-tag noindex trên server/nginx/apache.
• Không có plugin hoặc module bảo trì đang kích hoạt âm thầm.

Đối với website đa ngôn ngữ hoặc đa phiên bản (www/non-www, http/https), cần xác định rõ phiên bản canonical chính thức và đảm bảo chỉ phiên bản đó mở index, các phiên bản còn lại redirect 301 về bản chuẩn thay vì để Google index song song.

Trang không cần index như search nội bộ, filter rác, giỏ hàng và tài khoản phải được kiểm soát

Bên cạnh việc mở index cho các trang mang giá trị kinh doanh và traffic, cần có chiến lược kiểm soát index cho những loại URL không mang lại giá trị SEO hoặc có thể gây hại:

• Trang search nội bộ (kết quả tìm kiếm trên site).
• URL filter rác, filter kết hợp nhiều tham số không có nhu cầu tìm kiếm thực.
• Giỏ hàng, checkout, tài khoản người dùng, lịch sử đơn hàng.
• Trang cảm ơn chứa thông tin nhạy cảm hoặc chỉ xuất hiện sau chuyển đổi.
• Trang test, sandbox, A/B test tạm thời, trang demo.

Nếu để Google index các trang này, hệ quả thường gặp:

• Loãng chỉ mục: tỷ lệ URL chất lượng trong index giảm, làm suy yếu “sức mạnh” tổng thể của domain.
• Lãng phí crawl budget: Googlebot tốn tài nguyên crawl các URL vô giá trị thay vì tập trung vào trang quan trọng.
• Trùng lặp nội dung: nhiều biến thể URL hiển thị cùng một nội dung, gây khó khăn cho việc đánh giá relevance.

Giải pháp chuẩn là gắn meta robots noindex, follow hoặc sử dụng x-robots-tag cho các loại trang này. Cấu hình “follow” vẫn cho phép Googlebot đi theo link nội bộ để truyền PageRank, trong khi “noindex” ngăn trang xuất hiện trong kết quả tìm kiếm.

Với các hệ thống filter tạo ra hàng nghìn hoặc hàng triệu URL (ví dụ: filter theo màu, size, brand, price, sort, paginate), có thể áp dụng kết hợp:

• noindex cho các tổ hợp filter không có search demand.
• Không đưa các URL này vào sitemap.
• Hạn chế internal link trực tiếp từ menu, footer, hoặc block điều hướng cố định.

Tuy nhiên, không nên chặn hoàn toàn bằng robots.txt nếu vẫn muốn Googlebot crawl để theo dõi link nội bộ và hiểu cấu trúc site. Chặn bằng robots.txt khiến Google không đọc được meta robots và canonical trên trang, dẫn đến khó kiểm soát index chính xác.

Trong bước nghiệm thu, cần yêu cầu đơn vị triển khai:

• Liệt kê rõ các nhóm URL đã được noindex (theo pattern, ví dụ: ?q=, ?sort=, /cart, /account).
• Mô tả cách họ cấu hình: meta robots trong template, x-robots-tag trên server, hay rule trong CMS.
• Chứng minh bằng một số URL mẫu cho từng nhóm để kiểm tra thực tế.

Canonical phải trỏ đúng URL chuẩn của từng template trang

Thẻ rel="canonical" là tín hiệu quan trọng giúp Google hiểu đâu là phiên bản URL chuẩn khi tồn tại nhiều URL tương tự hoặc trùng lặp nội dung. Sai sót trong cấu hình canonical có thể dẫn đến:

• Google bỏ qua hoặc giảm ưu tiên index trang quan trọng.
• Gộp tín hiệu về một URL không mong muốn (ví dụ: URL có tham số, URL cũ đã redirect).
• Phân tán tín hiệu xếp hạng giữa nhiều phiên bản URL.

Canonical giúp hợp nhất tín hiệu khi một nội dung có nhiều biến thể URL, nhưng cấu hình sai có thể làm mất quyền xếp hạng của trang chính. Guha, Brickley và Macbeth (2016) cho thấy dữ liệu có cấu trúc và tín hiệu mô tả thực thể giúp máy tìm kiếm hiểu đúng quan hệ giữa các đối tượng trên web. Với canonical, quan hệ quan trọng nhất là quan hệ giữa URL biến thể và URL chuẩn. Canonical nên trỏ đến trang 200, indexable, cùng intent và cùng nội dung chính, không trỏ sang trang cũ, trang noindex, trang redirect hoặc trang không tương đương. Khi nghiệm thu, cần crawl toàn site để phát hiện canonical chéo, canonical vòng lặp và canonical trỏ sai template.

Mỗi template trang (trang chủ, category, sản phẩm, bài viết, landing page) cần có logic canonical rõ ràng. Thông thường, phiên bản URL chuẩn nên sử dụng self-canonical:

• Trang chủ: canonical trỏ về đúng phiên bản chuẩn (ví dụ: https://www.example.com/).
• Category: canonical trỏ về URL category không tham số, không tracking.
• Sản phẩm: canonical trỏ về URL sản phẩm chính, không chứa UTM, không chứa ID session.
• Bài viết/blog: canonical trỏ về URL bài viết duy nhất, tránh trùng lặp giữa category, tag, archive.

Với các trang có tham số filter, sort, tracking, canonical nên trỏ về phiên bản không tham số, trừ khi có chiến lược SEO riêng cho từng filter (rất hiếm và cần phân tích search intent kỹ). Ví dụ:

• /giay-the-thao?color=red&sort=priceasc canonical về /giay-the-thao.
• /san-pham/abc?utmsource=... canonical về /san-pham/abc.

Trong các dự án redesign hoặc replatform, cần đặc biệt chú ý:

• Không để canonical của URL mới trỏ nhầm về URL cũ đã redirect 301, vì sẽ tạo chuỗi tín hiệu vòng vèo.
• Không canonical chéo giữa hai URL không tương đương nội dung (ví dụ: canonical từ sản phẩm A sang sản phẩm B khác hẳn).
• Không sử dụng một canonical duy nhất cho toàn bộ site (sai lầm thường gặp khi cấu hình template).

Khi nghiệm thu, nên dùng công cụ crawl để xuất danh sách canonical cho toàn site, sau đó kiểm tra mẫu cho từng loại URL:

• Đảm bảo không có canonical trỏ chéo vòng lặp (A canonical sang B, B canonical sang A).
• Không canonical về trang không liên quan hoặc trang đã noindex.
• Canonical luôn trỏ đến URL trả về 200, indexable, và là phiên bản chuẩn mong muốn.

XML sitemap chỉ chứa URL canonical, indexable và có giá trị SEO

XML sitemap đóng vai trò như bản đồ giúp Google phát hiện nhanh các URL quan trọng, đặc biệt hữu ích với website lớn, cấu trúc phức tạp hoặc có nhiều trang mới được tạo thường xuyên. Một sitemap chuẩn SEO cần tuân thủ các nguyên tắc:

• Chỉ chứa URL canonical (trùng với canonical trên trang).
• Mỗi URL trong sitemap phải đang mở index, không có meta robots noindex.
• Tất cả URL phải trả về HTTP status 200, không 3xx, 4xx, 5xx.
• Chỉ đưa vào những URL có nội dung thực sự có giá trị SEO, có khả năng mang lại traffic hoặc chuyển đổi.

Sitemap XML nên được xem là danh sách ưu tiên kỹ thuật gửi cho công cụ tìm kiếm, không phải nơi chứa mọi URL đang tồn tại trong hệ thống. Morville và Rosenfeld (2006) nhấn mạnh rằng kiến trúc thông tin tốt phải giúp người dùng và hệ thống tìm thấy nội dung quan trọng bằng cấu trúc rõ ràng. Với sitemap, nguyên tắc tương tự là chỉ đưa vào các URL có giá trị tìm kiếm, có nội dung đủ khác biệt, trả 200, không noindex và khớp canonical. Sitemap chứa nhiều URL lỗi làm giảm chất lượng tín hiệu, khiến Google Search Console báo cảnh báo và làm việc debug index trở nên khó hơn sau bàn giao.

Nếu sitemap chứa nhiều URL lỗi (404, 301, 5xx, noindex, trùng lặp), Google Search Console sẽ báo lỗi hoặc cảnh báo, đồng thời đánh giá sitemap là nguồn tín hiệu kém chất lượng. Điều này không chỉ làm giảm hiệu quả của sitemap mà còn có thể ảnh hưởng đến cách Google đánh giá toàn bộ site.

Trước khi nhận bàn giao, cần yêu cầu đơn vị triển khai cung cấp đường dẫn sitemap, thường là /sitemap.xml hoặc một sitemap index chứa nhiều file con (sitemap cho sản phẩm, bài viết, trang tĩnh…). Các bước kiểm tra nên bao gồm:

• Dùng công cụ crawl hoặc script để kiểm tra status code của từng URL trong sitemap.
• Đối chiếu với canonical trên từng trang để đảm bảo URL trong sitemap là bản chuẩn.
• Kiểm tra meta robots và x-robots-tag để chắc chắn không có URL noindex trong sitemap.

Với website lớn, nên tách sitemap theo loại nội dung (sản phẩm, bài viết, trang tĩnh, category) để:

• Dễ quản lý và debug khi có lỗi.
• Dễ theo dõi hiệu suất index của từng nhóm nội dung trong Search Console.
• Giảm rủi ro vượt giới hạn số URL trong một file sitemap.

Đồng thời, cần xác nhận rằng sitemap đã được:

• Khai báo trong Google Search Console ở mục Sitemaps.
• Tham chiếu trong file robots.txt bằng dòng Sitemap: https://www.example.com/sitemap.xml.

Google Search Console cần xác minh domain và kiểm tra URL mẫu bằng URL Inspection

Google Search Console (GSC) là công cụ bắt buộc phải có khi bàn giao website chuẩn SEO, vì đây là kênh duy nhất cung cấp dữ liệu chính thức từ Google về crawl, index, lỗi kỹ thuật và hiệu suất tìm kiếm. Chủ website cần được bàn giao quyền sở hữu (Owner) cho property dạng Domain (bao phủ tất cả subdomain, http/https) hoặc ít nhất là property dạng URL prefix đúng phiên bản canonical.

Sau khi xác minh, nên sử dụng tính năng URL Inspection để kiểm tra một số URL mẫu đại diện:

• Trang chủ.
• Một vài category chính.
• Một số sản phẩm/dịch vụ quan trọng.
• Bài viết mới hoặc landing page mới triển khai.

URL Inspection cung cấp thông tin chi tiết:

• Trang đã được index hay chưa, nếu chưa thì lý do là gì.
• Google đang xem canonical nào cho URL đó (có trùng với canonical khai báo không).
• Trang có bị chặn bởi robots.txt, meta robots, x-robots-tag hay không.
• Trạng thái mobile-friendly, khả năng render, và dữ liệu structured data nếu có.

Với website mới, có thể sử dụng chức năng “Request indexing” cho một số trang quan trọng để đẩy nhanh quá trình index ban đầu. Tuy không đảm bảo lập tức, nhưng giúp Google ưu tiên crawl sớm hơn.

Trong phạm vi nghiệm thu, nên yêu cầu:

• Chụp lại màn hình GSC thể hiện rằng Google có thể crawl và index website bình thường.
• Không có lỗi nghiêm trọng ở mức hệ thống (ví dụ: toàn site bị chặn bởi robots, tỷ lệ lỗi server cao).
• Đã cấu hình đúng phiên bản canonical trong property (không nhầm giữa http/https, www/non-www).

Kiểm tra cấu trúc URL, redirect và lỗi HTTP

Cấu trúc URL, hệ thống redirect và mã lỗi HTTP cần được kiểm tra như một khối thống nhất để đảm bảo website vận hành ổn định, dễ crawl và không làm thất thoát tín hiệu SEO. URL phải ngắn, rõ nghĩa, dùng chữ thường, dấu gạch ngang và hạn chế tham số; mọi biến thể www/non-www, HTTP/HTTPS phải được gom về một phiên bản canonical bằng redirect 301, tránh chain và loop. Toàn bộ site cần được crawl để phát hiện và xử lý redirect chain, loop, 404, soft 404 và lỗi 5xx trước khi nghiệm thu. Với dự án redesign, phải lập file mapping chi tiết để redirect URL cũ sang URL mới đúng intent. Trang 404 cần trả đúng mã lỗi và hỗ trợ điều hướng, giúp người dùng tiếp tục khám phá nội dung.

URL cần ngắn, dễ đọc, thống nhất chữ thường, dấu gạch ngang và không có tham số thừa

Cấu trúc URL thân thiện là một trong những tín hiệu kỹ thuật quan trọng nhất của SEO on-site, ảnh hưởng trực tiếp đến khả năng crawl, index, CTR trên SERP và trải nghiệm người dùng. Về nguyên tắc, URL nên phản ánh rõ ràng chủ đề nội dung, tránh mọi yếu tố gây nhiễu hoặc khó hiểu cho cả người dùng lẫn bot. URL rõ ràng giúp người dùng và bot hiểu nhanh chủ đề trang trước cả khi đọc nội dung. Nielsen (1993) cho rằng hệ thống dễ dùng phải giảm gánh nặng nhận thức và giúp người dùng dự đoán được kết quả của hành động. Trong SEO, URL như /dich-vu/thiet-ke-website/ dễ hiểu hơn nhiều so với /page.php?id=123&ref=abc, vì nó thể hiện chủ đề, cấp thư mục và intent rõ hơn. URL ổn định cũng giúp tích lũy tín hiệu lâu dài, tránh phải redirect nhiều lần khi đổi cấu trúc. Khi nghiệm thu, cần thống nhất quy ước chữ thường, dấu gạch ngang, trailing slash và phiên bản canonical.

Một URL tối ưu thường đáp ứng các tiêu chí:

• Ngắn gọn, có cấu trúc: chỉ giữ lại các thư mục (folder) thực sự cần thiết, tránh lồng quá nhiều cấp như /category/subcategory/sub-sub/category/product/. Mỗi cấp thư mục nên thể hiện một tầng phân loại rõ ràng.
• Mô tả nội dung bằng từ khóa tự nhiên: ưu tiên từ khóa chính và biến thể gần nghĩa, nhưng không nhồi nhét. Ví dụ: /may-loc-khong-khi-sharp-kc-f30ev-w/ thay vì /product1234/.
• Dùng dấu gạch ngang (-) để phân tách từ, tuyệt đối tránh dấu gạch dưới (_) hoặc khoảng trắng mã hóa %20. Bot của Google hiểu dấu gạch ngang là khoảng cách giữa các từ, giúp phân tích từ khóa chính xác hơn.
• Thống nhất chữ thường: sử dụng toàn bộ chữ thường để tránh tạo ra các biến thể URL khác nhau về mặt kỹ thuật nhưng trùng nội dung, ví dụ: /San-Pham/ và /san-pham/.
• Hạn chế tham số: chỉ dùng query string khi thực sự cần (lọc, sort, tracking). Các tham số như ?ref=abc, ?sessionid=xyz nên được loại bỏ khỏi URL index chính hoặc xử lý bằng canonical/parameter handling trong Google Search Console.

Khi nghiệm thu, cần kiểm tra theo từng nhóm template URL:

• Trang chủ: chỉ nên có một URL duy nhất, ví dụ https://domain.com/, không để tồn tại thêm /index.php, /home, /default.aspx…
• Category: cấu trúc rõ ràng, không lặp từ, ví dụ /dien-thoai/, tránh /danh-muc/dien-thoai/ nếu “danh-muc” không mang thêm ý nghĩa.
• Subcategory: thể hiện mối quan hệ phân cấp, ví dụ /dien-thoai/android/, không nên dùng ID khó hiểu như /cat.php?id=12.
• Sản phẩm: ưu tiên /dien-thoai/iphone-15-pro-max/ thay vì /p/iphone-15-pro-max-12345/ trừ khi ID là bắt buộc về mặt hệ thống.
• Bài viết/blog: cấu trúc có thể là /blog/tu-van-chon-may-loc-khong-khi/, hạn chế đưa ngày tháng vào URL nếu không cần thiết, vì gây dài và khó chỉnh sửa sau này.
• Landing page: URL nên ngắn, tập trung vào intent chuyển đổi, ví dụ /khuyen-mai/may-loc-khong-khi/.

Nếu phát hiện nhiều URL dạng ?id=123&ref=abc hoặc chứa ký tự mã hóa như %2F, %3F, cần yêu cầu chuẩn hóa lại bằng cách:

• Thiết kế lại routing ở mức CMS/framework để sinh URL tĩnh (pretty URL).
• Dùng rewrite rule (Apache, Nginx, IIS) để chuyển từ URL động sang URL thân thiện.
• Đảm bảo không tồn tại song song hai phiên bản URL chỉ khác nhau ở chữ hoa/chữ thường hoặc có/không có dấu gạch chéo cuối (trailing slash) mà không có redirect thống nhất. Ví dụ, phải chọn một chuẩn: /san-pham/ hoặc /san-pham, sau đó redirect 301 tất cả biến thể về chuẩn này.

Phiên bản www, non-www, HTTP và HTTPS phải quy về một bản canonical bằng 301

Mỗi domain thường có ít nhất bốn biến thể truy cập:

• http://domain.com
• http://www.domain.com
• https://domain.com
• https://www.domain.com

Nếu không cấu hình redirect chuẩn, Google có thể coi đây là các thực thể khác nhau, dẫn đến:

• Phân tán backlink và tín hiệu xếp hạng giữa nhiều phiên bản.
• Trùng lặp nội dung (duplicate content) trên diện rộng.
• Khó kiểm soát dữ liệu trong Google Search Console (mỗi phiên bản là một property riêng).

Trước khi nhận bàn giao, cần xác định rõ phiên bản canonical mà website sẽ sử dụng lâu dài, thường là:

• https://www.domain.com nếu muốn giữ “www” cho mục đích thương hiệu hoặc hạ tầng.
• https://domain.com nếu muốn URL ngắn gọn, hiện đại.

Các bước kiểm tra và yêu cầu kỹ thuật:

• Truy cập trực tiếp từng phiên bản trên trình duyệt, quan sát thanh địa chỉ để xem có được chuyển về phiên bản canonical hay không.
• Dùng công cụ kiểm tra redirect (như các extension HTTP header hoặc công cụ crawl) để xác nhận:
  • Tất cả phiên bản không canonical đều trả 301 Moved Permanently về đúng URL canonical.
  • Không có redirect chain kiểu: http -> https -> https www; thay vào đó nên gom về một bước duy nhất, ví dụ: http://domain.com -> https://domain.com.
  • Không tồn tại redirect loop, ví dụ: https://domain.com -> https://www.domain.com -> https://domain.com.
• Kiểm tra chứng chỉ SSL:
  • Chứng chỉ phải hợp lệ cho phiên bản canonical (SAN hoặc wildcard phù hợp).
  • Không có cảnh báo “Not secure” hoặc lỗi mixed content trên các trang chính.
• Đảm bảo các internal link, canonical tag, hreflang (nếu có) đều trỏ về đúng phiên bản canonical, không trỏ lẫn lộn giữa www và non-www hoặc giữa http và https.

Redirect chain, redirect loop, 404, soft 404 và lỗi 5xx cần được xử lý trước khi nhận

Các lỗi HTTP phản ánh chất lượng kỹ thuật của website và ảnh hưởng trực tiếp đến crawl budget, index coverage và trải nghiệm người dùng. Một website mới hoặc vừa triển khai lại mà còn nhiều lỗi loại này thường sẽ gặp khó khăn trong giai đoạn đầu SEO.

Các nhóm lỗi cần kiểm tra bằng crawl toàn site:

• Redirect chain: chuỗi chuyển hướng nhiều bước, ví dụ:
  • /san-pham-cu/ -> /san-pham-moi/ -> /san-pham-moi-2024/
  Điều này làm chậm tốc độ tải, lãng phí crawl budget và có thể làm suy yếu tín hiệu link. Cần rút gọn thành một bước 301 trực tiếp từ URL gốc sang URL cuối cùng.
• Redirect loop: vòng lặp chuyển hướng, ví dụ:
  • /a -> /b -> /a
  Khi gặp loop, bot sẽ dừng crawl, người dùng không truy cập được trang. Cần rà lại rule redirect, ưu tiên logic đơn giản, tránh điều kiện chồng chéo.
• 404 Not Found: trang không tồn tại. Về mặt SEO, một số 404 là bình thường, nhưng:
  • Không nên để nhiều internal link trỏ đến URL 404, vì làm thất thoát PageRank nội bộ và gây trải nghiệm xấu.
  • Các URL từng có traffic/backlink mà nay trả 404 nên được xem xét redirect 301 sang trang tương đương.
• Soft 404: trang trả mã 200 nhưng nội dung thực tế là “không tìm thấy” hoặc quá mỏng, không có giá trị. Google thường gắn nhãn soft 404 trong Search Console. Nguyên nhân phổ biến:
  • Trang thông báo “Không có sản phẩm nào trong danh mục này” nhưng vẫn trả 200.
  • Trang sản phẩm hết hàng vĩnh viễn nhưng không có nội dung thay thế.
  Giải pháp: hoặc trả đúng 404/410, hoặc bổ sung nội dung hữu ích, gợi ý sản phẩm liên quan để trang đủ giá trị giữ lại.
• Lỗi 5xx (server error): bao gồm 500, 502, 503, 504… Đây là lỗi nghiêm trọng vì:
  • Google có thể giảm crawl rate nếu gặp nhiều 5xx liên tục.
  • Người dùng không truy cập được, ảnh hưởng trực tiếp doanh thu.
  Cần phối hợp với đội server/hosting để:
  • Kiểm tra log server, tìm nguyên nhân (timeout, quá tải, lỗi code, cấu hình reverse proxy…).
  • Thiết lập monitoring và alert để phát hiện sớm.
  • Dùng 503 kèm header Retry-After khi bảo trì có kế hoạch.

Trước khi nghiệm thu, nên chạy crawl toàn bộ site (hoặc ít nhất là tất cả URL quan trọng) và xuất báo cáo lỗi HTTP, sau đó yêu cầu fix đến mức tối thiểu có thể.

Trang cũ trong dự án redesign phải có mapping redirect sang URL mới phù hợp intent

Trong các dự án redesign hoặc chuyển nền tảng, việc mapping redirect là yếu tố quyết định giữ hay mất traffic organic. Khi cấu trúc URL thay đổi, mọi URL cũ đều cần được xử lý có chủ đích, không để Google tự “đoán”.

Quy trình mapping chuyên nghiệp thường gồm các bước:

• Trích xuất danh sách URL cũ từ:
  • Log server, Google Analytics, Google Search Console.
  • Các công cụ crawl phiên bản cũ (nếu còn truy cập được).
  • Danh sách backlink từ các công cụ phân tích liên kết.
• Lập một file mapping (thường là spreadsheet) với các cột:
  • URL cũ.
  • URL mới tương ứng.
  • Loại nội dung/intent (sản phẩm, category, bài viết, landing page…).
  • Ghi chú đặc biệt (URL có nhiều backlink, URL có traffic cao…).
• Nguyên tắc mapping:
  • Ưu tiên redirect 301 sang trang có intent tương đương hoặc gần nhất: sản phẩm sang sản phẩm, category sang category, bài viết sang bài viết cùng chủ đề.
  • Nếu sản phẩm cũ không còn bán nhưng có sản phẩm thay thế, redirect sang sản phẩm thay thế hoặc category phù hợp.
  • Chỉ redirect về trang chủ khi thực sự không có lựa chọn nào tốt hơn; lạm dụng redirect về homepage có thể làm loãng tín hiệu và gây khó hiểu cho người dùng.
• Sau khi triển khai rule redirect:
  • Crawl toàn bộ danh sách URL cũ để xác nhận:
    • Tất cả đều trả 301 (không phải 302, 307) và trỏ đúng URL mới.
    • Không có redirect chain hoặc loop phát sinh từ rule chồng chéo.
    • Không còn URL cũ quan trọng nào trả 404 nếu vẫn có nội dung tương đương.

Khi nghiệm thu, file mapping này cần được bàn giao cho chủ website như một tài liệu kỹ thuật chính thức, để sau này có thể rà soát, cập nhật hoặc debug khi phát sinh vấn đề về traffic và index.

Trang 404 phải trả đúng mã lỗi và có điều hướng phục hồi người dùng

Một trang 404 chuẩn SEO không chỉ là vấn đề thẩm mỹ mà còn là vấn đề kỹ thuật và trải nghiệm. Hai yêu cầu cốt lõi:

• Trả đúng mã HTTP 404 (hoặc 410 nếu muốn báo “đã xóa vĩnh viễn”).
• Giúp người dùng phục hồi hành trình, giảm tỷ lệ thoát và tăng khả năng tiếp tục khám phá site.

Các lỗi thường gặp:

• Trang 404 được thiết kế đẹp nhưng trả mã 200, khiến Google index trang này như một trang hợp lệ, dẫn đến soft 404 hàng loạt.
• Trang 404 chỉ hiển thị một dòng thông báo khô khan, không có bất kỳ link điều hướng hoặc gợi ý nào, làm người dùng buộc phải bấm Back hoặc đóng tab.

Một trang 404 tốt nên có các thành phần:

• Thông báo thân thiện, dễ hiểu, có thể kèm giải thích ngắn gọn lý do trang không tồn tại.
• Link về trang chủ, giúp người dùng quay lại điểm xuất phát.
• Một số link đến category chính hoặc các trang/bài viết phổ biến, giúp gợi ý hướng đi tiếp theo.
• Có thể kèm ô search nội bộ để người dùng tự tìm nội dung họ cần.
• Thiết kế đồng bộ với giao diện chung của website để người dùng không cảm giác bị “ra khỏi site”.

Về mặt kỹ thuật:

• Không cần gắn noindex cho trang 404, vì Google dựa vào mã trạng thái 404 để xử lý; tuy nhiên cần đảm bảo header HTTP thực sự trả 404.
• Khi nghiệm thu, nên:
  • Gõ một URL ngẫu nhiên không tồn tại, ví dụ /abcxyz-khong-ton-tai, để xem trang 404 hiển thị ra sao.
  • Dùng công cụ kiểm tra header (trình duyệt dev tools hoặc công cụ HTTP header) để xác nhận mã trạng thái là 404, không phải 200 hay 302.

Kiểm tra on-page SEO cho từng template trang

Kiểm tra on-page SEO cho từng template trang tập trung vào việc đảm bảo các yếu tố kỹ thuật và nội dung cốt lõi được chuẩn hóa, nhất quán và bám sát search intent. Mỗi loại trang (sản phẩm, dịch vụ, blog, category, landing page…) cần được thiết kế quy tắc rõ ràng cho title, meta description, H1–H3, cấu trúc nội dung, cách hiển thị và render HTML. Nội dung chính phải xuất hiện ổn định trong HTML render ban đầu hoặc được Googlebot truy cập dễ dàng, tránh phụ thuộc hoàn toàn vào JavaScript. Hình ảnh cần tối ưu alt text, tên file và kích thước để vừa hỗ trợ SEO vừa cải thiện tốc độ tải. Cuối cùng, mọi trang quan trọng phải có nội dung đủ sâu, khác biệt, tránh thin content và tăng tín hiệu EEAT.

Mỗi trang quan trọng cần có title, meta description và H1 duy nhất, đúng search intent

On-page SEO ở mức kỹ thuật và chiến lược bắt đầu từ việc kiểm soát chặt chẽ các thẻ cơ bản: title, meta description và H1. Mỗi template trang (trang chủ, category, sản phẩm, blog, landing page…) cần được định nghĩa rõ quy tắc sinh title và H1, sau đó áp dụng nhất quán cho toàn bộ website.

Với các trang quan trọng, title phải:

• Độc nhất trên toàn site, tránh trùng lặp giữa các URL khác nhau.
• Chứa từ khóa chính một cách tự nhiên, ưu tiên xuất hiện ở nửa đầu title.
• Phản ánh đúng search intent: thông tin, giao dịch, so sánh, điều hướng…
• Đủ ngắn để hạn chế bị cắt trên SERP (thường khoảng 50–60 ký tự, nhưng nên test thực tế).
• Tránh lặp thương hiệu quá dài dòng; có thể đặt brand ở cuối, ngăn cách bằng “|” hoặc “–”.

Meta description nên được xem như một đoạn copy quảng cáo ngắn:

• Tóm tắt rõ ràng lợi ích chính và điểm khác biệt của trang.
• Chèn từ khóa liên quan một cách tự nhiên để tăng mức độ liên quan, không nhồi nhét.
• Có lời kêu gọi hành động (CTA) rõ ràng: “Tìm hiểu thêm”, “Xem bảng giá”, “Đặt lịch tư vấn”…
• Độ dài khoảng 120–160 ký tự, tránh quá dài khiến bị cắt cụt.

Thẻ H1 trên trang nên:

• Trùng hoặc gần với title, nhưng có thể linh hoạt hơn về mặt ngôn ngữ.
• Chỉ xuất hiện một lần trên mỗi trang trong hầu hết các trường hợp.
• Chứa từ khóa chính hoặc biến thể gần nghĩa, thể hiện rõ chủ đề nội dung.

Khi nghiệm thu, nên yêu cầu đội dev hoặc SEO xuất danh sách title, meta description, H1 cho toàn bộ trang hoặc tối thiểu cho các template chính. Có thể dùng:

• Các crawler như Screaming Frog, Sitebulb để export dữ liệu hàng loạt.
• Các script nhỏ sử dụng headless browser để quét nếu site phức tạp.

Nếu phát hiện:

• Nhiều trang trùng title hoặc description.
• Thiếu H1, hoặc H1 bị dùng cho logo, slogan không liên quan.
• Meta description bị cắt cụt, chứa ký tự đặc biệt lỗi font.

cần yêu cầu tối ưu lại ngay ở mức template. Với website lớn, nên xây dựng quy ước đặt title và H1 cho từng loại trang, ví dụ:

• Trang sản phẩm: [Tên sản phẩm] – [Thuộc tính chính] | [Brand]
• Trang category: [Danh mục] [Khu vực/Đối tượng] – [Lợi ích chính]
• Blog: [Tiêu đề bài viết giải quyết vấn đề cụ thể]

Cách làm này giúp đảm bảo tính nhất quán, dễ mở rộng và giảm rủi ro lỗi khi thêm hàng nghìn URL mới.

Heading H2, H3 phải phản ánh nội dung thật, không nhồi từ khóa hoặc trùng lặp máy móc

Các thẻ H2, H3 là xương sống của cấu trúc nội dung, giúp công cụ tìm kiếm hiểu rõ chủ đề chính – phụ, đồng thời cải thiện khả năng đọc cho người dùng. Về mặt kỹ thuật, heading nên được dùng như một outline logic, không phải công cụ để “phóng to chữ”.

Một số nguyên tắc chuyên sâu khi thiết kế heading cho template:

• Mỗi H2 đại diện cho một phần nội dung chính; H3 nằm dưới H2 tương ứng, không nhảy cấp lung tung.
• Không lặp lại cùng một cụm từ khóa chính trong nhiều H2 trên cùng một trang nếu không có lý do rõ ràng.
• Heading phải mô tả chính xác nội dung bên dưới, tránh kiểu “từ khóa + từ khóa + từ khóa”.
• Không dùng heading cho các đoạn text nhỏ như label, caption, slogan chỉ để tăng kích thước font.

Trong quá trình nghiệm thu, nên kiểm tra kỹ:

• Một số bài viết dài (pillar content, hướng dẫn chuyên sâu).
• Trang dịch vụ, landing page chạy quảng cáo.
• Trang category có filter phức tạp.

Kiểm tra xem:

• Có nhiều hơn một H1 không cần thiết hay không.
• H2, H3 có bị dùng cho các block không quan trọng như “Sản phẩm liên quan”, “Tin mới” nếu không cần SEO cho phần đó.
• Các heading có bị lặp lại y hệt giữa nhiều trang (do copy template) dẫn đến nội dung trông giống nhau.

Với các website lớn, có thể thiết lập guideline:

• Trang sản phẩm: H2 cho “Mô tả chi tiết”, “Thông số kỹ thuật”, “Hướng dẫn sử dụng”, “FAQ”…
• Trang dịch vụ: H2 cho “Dịch vụ là gì”, “Quy trình thực hiện”, “Lợi ích”, “Bảng giá”, “Câu hỏi thường gặp”.
• Blog: H2 cho các ý chính, H3 cho các bước, ví dụ, case study.

Cách này giúp nội dung rõ ràng, tăng khả năng xuất hiện rich snippet, featured snippet cho các đoạn H2/H3 được tối ưu tốt.

Nội dung chính phải xuất hiện trong HTML render ban đầu hoặc được Googlebot truy cập ổn định

Với các website SPA hoặc dùng nhiều JavaScript, rủi ro lớn là nội dung chính chỉ xuất hiện sau khi JS chạy, trong khi HTML ban đầu gần như trống hoặc chỉ chứa skeleton. Về mặt crawl budget và khả năng index, điều này có thể khiến Google bỏ sót hoặc chậm index các trang quan trọng.

Về mặt kỹ thuật, nên ưu tiên:

• Server-side rendering (SSR) cho các trang cần SEO mạnh (category, sản phẩm, bài viết).
• Static rendering / pre-rendering cho nội dung ít thay đổi.
• Hybrid rendering: phần khung và nội dung chính SSR, phần tương tác nâng cao dùng JS.

Khi nghiệm thu, có thể kiểm tra theo các bước:

• Dùng “View Source” để xem HTML ban đầu: nội dung chính (H1, đoạn text, danh sách sản phẩm) có xuất hiện hay không.
• Dùng “Inspect” và tab Elements để xem DOM sau khi render; so sánh với HTML gốc.
• Sử dụng các crawler có tính năng “View rendered HTML” để mô phỏng cách Googlebot thấy trang.

Nếu phát hiện:

• Nội dung chỉ được load qua API sau khi scroll, click hoặc tương tác phức tạp.
• Các block quan trọng (mô tả sản phẩm, review, giá) không có trong HTML render ban đầu.

cần làm việc với team dev để cân nhắc:

• Đưa phần nội dung quan trọng vào SSR hoặc static HTML.
• Đảm bảo file JS, CSS, API endpoint không bị chặn bởi robots.txt hoặc cấu hình server.
• Test bằng công cụ “URL Inspection” trong Google Search Console để xem Google có render đầy đủ hay không.

Mục tiêu là đảm bảo indexability và rendering stability: Googlebot luôn có thể truy cập và hiểu nội dung chính mà không phụ thuộc quá nhiều vào điều kiện môi trường hoặc tài nguyên render.

Ảnh cần có alt text phù hợp ngữ cảnh, tên file rõ và kích thước tối ưu

Ảnh trên website vừa phục vụ trải nghiệm người dùng, vừa là tín hiệu cho SEO và accessibility. Về mặt kỹ thuật, mỗi ảnh quan trọng nên có alt text mô tả ngắn gọn nội dung hoặc chức năng, đặc biệt với:

• Ảnh sản phẩm chính.
• Ảnh minh họa trong bài blog, hướng dẫn.
• Ảnh trong banner có thông điệp quan trọng.

Nguyên tắc viết alt text:

• Mô tả đúng nội dung ảnh trong ngữ cảnh của trang.
• Chèn từ khóa liên quan nếu phù hợp, nhưng không lặp lại vô nghĩa.
• Không dùng các chuỗi như “image1”, “banner-home”, “anh1-anh2”.

Tên file ảnh cũng nên được tối ưu:

• Dùng từ khóa hoặc mô tả ngắn, phân tách bằng dấu gạch ngang: may-loc-khong-khi-xyz.jpg.
• Tránh ký tự đặc biệt, dấu tiếng Việt, khoảng trắng.
• Không dùng chuỗi ký tự tự động như IMG_1234.JPG cho ảnh quan trọng.

Về kích thước và dung lượng:

• Resize ảnh đúng kích thước hiển thị, tránh load ảnh 3000px cho khung 600px.
• Dùng định dạng hiện đại (WebP, AVIF) nếu hạ tầng cho phép.
• Nén ảnh bằng công cụ hoặc pipeline build để giảm dung lượng mà vẫn giữ chất lượng chấp nhận được.

Trong giai đoạn nghiệm thu, nên:

• Kiểm tra ngẫu nhiên một số trang sản phẩm, bài blog để xem alt text có được điền đầy đủ, đúng ngữ cảnh hay không.
• Dùng PageSpeed Insights hoặc Lighthouse để xem ảnh có bị đánh giá là quá lớn, chưa nén, hoặc không dùng định dạng tối ưu.

Tối ưu ảnh tốt giúp cải thiện chỉ số LCP (Largest Contentful Paint), giảm băng thông và tăng khả năng xuất hiện trong Google Images cho các truy vấn liên quan.

Trang sản phẩm, dịch vụ, blog và category cần có nội dung đủ khác biệt để tránh thin content

Thin content – nội dung mỏng, trùng lặp, ít giá trị – là một trong những nguyên nhân khiến website khó cạnh tranh trên SERP, đặc biệt trong các ngành có nhiều đối thủ mạnh. Về mặt chiến lược, mỗi trang sản phẩm, dịch vụ, bài viết và category cần được thiết kế để mang lại giá trị riêng, không chỉ “thay tên đổi mã”. Nội dung khác biệt là cơ sở để chứng minh chuyên môn và tránh việc nhiều URL cạnh tranh cùng một intent. Fogg và cộng sự (2003) cho thấy người dùng đánh giá độ tin cậy của website dựa trên các dấu hiệu như thông tin cụ thể, khả năng kiểm chứng, tính chuyên nghiệp và sự minh bạch. Với trang sản phẩm, dịch vụ, blog hoặc category, nội dung không nên chỉ thay tên hoặc copy mô tả nhà cung cấp; cần có lợi ích, thông số, quy trình, FAQ, hình ảnh thực tế, case study hoặc hướng dẫn sử dụng riêng. Nội dung mỏng làm yếu E-E-A-T, giảm khả năng xếp hạng và làm người dùng khó tin vào năng lực thật của website.

Với trang sản phẩm, nên có:

• Mô tả chi tiết về tính năng, thông số, chất liệu, kích thước, cách sử dụng.
• Lợi ích cụ thể cho từng nhóm khách hàng, tình huống sử dụng.
• So sánh với các model khác trong cùng dòng (nếu phù hợp).
• FAQ, hướng dẫn bảo quản, lưu ý khi sử dụng.

Với trang dịch vụ:

• Giải thích rõ dịch vụ là gì, phù hợp với ai.
• Mô tả quy trình thực hiện từng bước.
• Case study, testimonial, kết quả thực tế.
• Bảng giá hoặc cách tính giá, điều kiện, cam kết.

Với blog và category:

• Bài viết cần giải quyết vấn đề cụ thể, có chiều sâu, không chỉ lặp lại thông tin chung chung.
• Category nên có phần mô tả giới thiệu, giải thích phạm vi sản phẩm/dịch vụ trong danh mục.
• Tránh việc nhiều bài viết khác nhau nhưng nội dung gần như giống hệt, chỉ thay đổi vài câu.

Trước khi nhận bàn giao, nên chọn ngẫu nhiên một số trang trong mỗi nhóm (sản phẩm, dịch vụ, blog, category) và đọc kỹ để đánh giá:

• Nội dung có thực sự giải thích rõ lợi ích, tính năng, cách sử dụng hay không.
• Có case study, ví dụ thực tế, số liệu minh chứng hay chỉ là lời quảng cáo chung chung.
• Mức độ trùng lặp giữa các sản phẩm tương tự: mô tả có được viết riêng hay copy từ catalog nhà cung cấp.

Với website thương mại điện tử, nên yêu cầu:

• Mỗi nhóm sản phẩm chính có guideline nội dung riêng.
• Các sản phẩm bán chạy, sản phẩm chiến lược phải có mô tả độc đáo, chi tiết hơn mức tối thiểu.

Cách làm này không chỉ giúp tránh thin content mà còn tăng tín hiệu EEAT (Experience, Expertise, Authoritativeness, Trustworthiness) trong mắt người dùng lẫn công cụ tìm kiếm, thể hiện rằng doanh nghiệp có hiểu biết thực sự về sản phẩm/dịch vụ mình cung cấp.

Kiểm tra kiến trúc thông tin và internal link

Phần này tập trung vào việc đảm bảo website được đo lường và quản trị dữ liệu SEO một cách bài bản, gắn chặt với mục tiêu kinh doanh. Trước hết, các tài khoản cốt lõi như Google Search Console, GA4, Google Tag Manager và công cụ analytics khác phải được thiết lập đúng, chủ doanh nghiệp giữ quyền sở hữu cao nhất để tránh phụ thuộc đơn vị triển khai. Tiếp theo, hệ thống tracking cần bao phủ đầy đủ các sự kiện quan trọng: gửi form, click gọi, chat, add to cart, purchase, booking… và được kiểm thử trên nhiều thiết bị, trình duyệt để đảm bảo conversion không bị lỗi và dữ liệu không sai lệch.

Bên cạnh đó, UTM, pixel, cookie consent và ecommerce tracking phải được cấu hình chuẩn, tránh trùng lặp, đảm bảo tuân thủ bảo mật dữ liệu. Cuối cùng, cần xây dựng dashboard báo cáo phân tách rõ traffic organic, paid, referral, direct và conversion từ SEO, giúp đội ngũ ra quyết định dựa trên số liệu thay vì cảm tính.

Danh mục, dịch vụ, sản phẩm và bài viết cần được nhóm theo entity và intent rõ ràng

Một kiến trúc thông tin chuẩn SEO trong giai đoạn nghiệm thu không chỉ dừng ở việc “nhóm cho hợp lý”, mà cần dựa trên tư duy entity-based SEO và phân tích search intent chi tiết. Mỗi nhóm nội dung (category, dịch vụ, sản phẩm, bài viết) nên được gắn với một hoặc một cụm entity cốt lõi, đồng thời map rõ với các loại intent: informational, commercial, transactional, navigational.

Cách tiếp cận chuyên sâu thường gồm các bước:

• Thu thập danh sách từ khóa và chủ đề, sau đó gom theo entity (thực thể: bệnh, sản phẩm, thương hiệu, quy trình, đối tượng…)
• Phân loại intent cho từng cụm từ khóa: người dùng đang tìm thông tin, so sánh, hay chuẩn bị mua/đăng ký dịch vụ
• Xây dựng “cây nội dung” trong đó:
  • Trang category/dịch vụ chính đóng vai trò hub cho một entity
  • Các bài viết chuyên sâu, FAQ, case study là các cluster xoay quanh hub
  • Trang sản phẩm/landing page chuyển đổi phục vụ intent transactional/commercial

Ví dụ chuyên sâu cho website y tế:

• Nhóm theo bệnh lý (entity: “thoát vị đĩa đệm”, “viêm loét dạ dày”, “tiểu đường”)
• Trong mỗi bệnh lý, tách theo intent:
  • Informational: nguyên nhân, triệu chứng, chẩn đoán, biến chứng
  • Commercial/Transactional: gói khám, phác đồ điều trị, chi phí, đặt lịch
  • Navigational: thông tin bác sĩ, cơ sở khám, quy trình tiếp nhận

Với website thương mại điện tử, có thể thiết kế:

• Level 1: loại sản phẩm (entity: “Laptop”, “Điện thoại”, “Máy giặt”)
• Level 2: thương hiệu (entity: “Apple”, “Samsung”, “Dell”)
• Level 3: nhu cầu sử dụng (học tập, gaming, văn phòng, doanh nghiệp…)
• Các bài viết hỗ trợ: hướng dẫn chọn mua, so sánh model, review chi tiết, FAQ bảo hành

Khi nghiệm thu, cần yêu cầu đơn vị triển khai cung cấp:

• Sơ đồ site map logic hoặc mindmap thể hiện rõ:
  • Trang nào là “pillar/hub”, trang nào là “cluster/supporting”
  • Mối quan hệ giữa category – subcategory – bài viết – sản phẩm
  • Các tuyến nội dung phục vụ từng intent chính
• Giải thích lý do phân nhóm:
  • Dựa trên entity nào, insight người dùng nào, dữ liệu từ khóa nào
  • Cách kiến trúc này hỗ trợ xây dựng topical authority cho từng chủ đề

Một kiến trúc tốt sẽ:

• Giúp Google dễ nhận diện chủ đề trọng tâm, hiểu website như một “chuyên gia” trong từng cụm entity
• Giảm cannibalization (nhiều trang tranh nhau cùng một từ khóa/intent)
• Giúp người dùng di chuyển tự nhiên từ nội dung tổng quan đến nội dung chuyên sâu và trang chuyển đổi

Breadcrumb phải phản ánh đúng quan hệ phân cấp giữa trang con và trang cha

Breadcrumb là lớp điều hướng thể hiện cấu trúc phân cấp thực tế của website. Về mặt kỹ thuật SEO, breadcrumb cung cấp tín hiệu rõ ràng cho Google về:

• Trang nào là cấp cao hơn (parent), trang nào là cấp thấp hơn (child)
• Vị trí tương đối của một URL trong toàn bộ kiến trúc
• Đường đi logic mà người dùng có thể quay lại các cấp trên

Yêu cầu quan trọng khi nghiệm thu:

• Breadcrumb phải khớp với cấu trúc URL và cấu trúc category:
  • Nếu URL: /dien-thoai/iphone/iphone-15/, breadcrumb nên là: Trang chủ > Điện thoại > iPhone > iPhone 15
  • Không nên hiển thị một cấp breadcrumb không tồn tại trong cấu trúc thật
• Kiểm tra trên các loại trang:
  • Category: phải hiển thị ít nhất “Trang chủ > Danh mục”
  • Sản phẩm: hiển thị đầy đủ tuyến category dẫn đến sản phẩm
  • Bài viết: hiển thị category bài viết hoặc chuyên mục kiến thức tương ứng
• Mỗi cấp breadcrumb phải là link HTML chuẩn:
  • Dùng thẻ <a> với href rõ ràng, không bị chặn bởi robots.txt hoặc nofollow nội bộ
  • Không render breadcrumb hoàn toàn bằng JS khó crawl nếu không có fallback HTML

Về mặt dữ liệu có cấu trúc, nên triển khai schema BreadcrumbList tương ứng với breadcrumb hiển thị. Khi nghiệm thu, cần:

• Dùng công cụ kiểm tra dữ liệu có cấu trúc (Rich Results Test, Schema validator) để:
  • Xác nhận Google đọc được BreadcrumbList
  • Đảm bảo mỗi item có position, name, item (URL) chính xác
• Đối chiếu giữa breadcrumb hiển thị và breadcrumb trong schema:
  • Không để tình trạng schema một kiểu, giao diện hiển thị một kiểu
  • Không dùng breadcrumb schema cho những cấp không tồn tại trong UI

Internal link từ trang chủ, menu, footer và nội dung phải ưu tiên URL có giá trị SEO

Internal link là công cụ điều phối PageRank nội bộ và định hướng crawl. Trong nghiệm thu, cần đánh giá mức độ “tập trung sức mạnh” vào các URL chiến lược, thay vì dàn trải vào những trang ít giá trị SEO.




Các nhóm vị trí internal link quan trọng:

• Trang chủ:
  • Phải trỏ đến các category/dịch vụ trụ cột, không chỉ tập trung vào tin tức mới nhất
  • Các block nổi bật (banner, section dịch vụ, sản phẩm hot) nên link đến landing page chiến lược
• Menu chính (header):
  • Ưu tiên các danh mục mang lại traffic/lead/doanh thu cao
  • Hạn chế nhét quá nhiều item khiến mỗi link bị “loãng” giá trị
  • Các mục con (mega menu) nên phản ánh cấu trúc entity đã thiết kế
• Footer:
  • Không chỉ chứa link pháp lý (Điều khoản, Chính sách…) mà nên có:
    • Link đến các category/dịch vụ chính
    • Link đến các hub nội dung quan trọng (blog chính, thư viện tài liệu, FAQ tổng)
  • Tránh nhồi quá nhiều link không cần thiết gây nhiễu
• Nội dung bài viết/trang dịch vụ:
  • Chèn internal link theo ngữ cảnh đến:
    • Bài viết chuyên sâu hơn (đi xuống)
    • Trang tổng quan/pillar (đi lên)
    • Trang chuyển đổi (đi sang intent transactional)
  • Ưu tiên link đến các URL đang cần đẩy thứ hạng hoặc có giá trị kinh doanh cao

Khi nghiệm thu, nên:

• Dùng công cụ crawl (Screaming Frog, Sitebulb,…) để:
  • Liệt kê các URL nhận nhiều internal link nhất
  • So sánh với danh sách URL ưu tiên do đội SEO đề xuất
  • Phát hiện các trang quan trọng nhưng lại nhận ít link (orphan/near-orphan)
• Kiểm tra thủ công một số tuyến:
  • Từ trang chủ đến từng dịch vụ chính có tối đa bao nhiêu click
  • Từ bài viết kiến thức đến trang dịch vụ liên quan có link rõ ràng hay không

Anchor text cần mô tả điểm đến, không dùng quá nhiều cụm chung chung hoặc nhồi từ khóa

Anchor text là tín hiệu ngữ nghĩa quan trọng giúp bot hiểu nội dung trang đích và mối liên hệ giữa các trang. Về mặt chuyên môn, anchor text nên:

• Mô tả chính xác hoặc gần chính xác chủ đề trang đích
• Phù hợp với ngữ cảnh câu, đoạn văn xung quanh
• Đa dạng về cách diễn đạt, tránh lặp 100% exact match quá nhiều




Các lỗi thường gặp khi nghiệm thu:

• Dùng anchor chung chung:
  • “xem thêm”, “tại đây”, “click vào đây” cho hầu hết internal link
  • Làm giảm khả năng hiểu ngữ cảnh của bot, giảm giá trị SEO của link
• Nhồi từ khóa:
  • Mọi link trỏ về một trang đều dùng cùng một anchor exact match từ khóa chính
  • Dễ tạo tín hiệu tối ưu quá đà, thiếu tự nhiên
• Anchor quá dài hoặc lẫn nhiều từ không liên quan:
  • Toàn bộ một câu hoặc một đoạn được gắn link
  • Khó xác định phần nào là trọng tâm ngữ nghĩa

Trong giai đoạn nghiệm thu, có thể:

• Chọn một số trang dịch vụ và bài viết quan trọng để:
  • Đếm số lượng anchor trỏ về cùng một URL
  • Ghi nhận các biến thể anchor đang được sử dụng
• Đánh giá:
  • Tỷ lệ anchor mô tả rõ ràng (ví dụ: “dịch vụ khám thoát vị đĩa đệm”, “bảng giá điều trị tiểu đường”)
  • Tỷ lệ anchor chung chung (“xem thêm”, “tại đây”)
  • Mức độ đa dạng: có nhiều biến thể tự nhiên hay chỉ 1–2 cụm lặp lại

Điều chỉnh đề xuất:

• Giữ một tỷ lệ nhỏ anchor chung chung để tự nhiên, nhưng phần lớn anchor nên mô tả nội dung trang đích
• Tránh dùng cùng một anchor exact match cho tất cả link trỏ về một URL; thay bằng các biến thể gần nghĩa
• Giới hạn độ dài anchor ở mức vừa phải, tập trung vào cụm từ khóa chính và từ liên quan trực tiếp

HTML sitemap nên có nếu website lớn, nhiều danh mục hoặc nhiều URL sâu

Với website có cấu trúc phức tạp, nhiều tầng danh mục hoặc hàng trăm, hàng nghìn URL, một HTML sitemap đóng vai trò như một “bản đồ điều hướng” cho cả bot và người dùng. Khác với XML sitemap (chủ yếu cho bot), HTML sitemap là một trang hiển thị link nội bộ ở dạng có thể click trực tiếp.




Đặc điểm của một HTML sitemap hiệu quả:

• Được tổ chức theo cấu trúc danh mục:
  • Nhóm theo loại nội dung: dịch vụ, sản phẩm, bài viết, tài liệu, FAQ…
  • Trong mỗi nhóm, có thể chia tiếp theo entity hoặc chủ đề lớn
• Được link từ footer hoặc một vị trí dễ truy cập:
  • Giúp bot có thêm một điểm xuất phát để crawl
  • Giúp người dùng tìm nhanh khu vực họ quan tâm nếu menu chính quá phức tạp
• Không chứa:
  • Trang test, staging, trang demo
  • Trang noindex, trang lỗi 4xx/5xx
  • URL trùng lặp, tham số không cần thiết

Khi nghiệm thu website lớn, cần:

• Kiểm tra sự tồn tại của HTML sitemap hoặc ít nhất một trang hub tổng hợp link đến các danh mục chính
• Đối chiếu với XML sitemap và dữ liệu crawl:
  • Các khu vực quan trọng có được đại diện trong HTML sitemap hay không
  • Có URL nào trong HTML sitemap trả về lỗi hoặc redirect vòng lặp không
• Đảm bảo:
  • HTML sitemap được crawl bình thường (không bị noindex, nofollow, chặn robots)
  • Cấu trúc hiển thị rõ ràng, dễ scan, không nhồi quá nhiều link trong một khối khó đọc

Kiểm tra tốc độ tải trang và Core Web Vitals




Các template chính cần đạt tốc độ ổn định trên mobile và desktop

Tốc độ tải trang và Core Web Vitals không chỉ là “chỉ số đẹp” trong báo cáo mà là tập hợp các tín hiệu xếp hạng và trải nghiệm người dùng cốt lõi. Khi nghiệm thu một website, đặc biệt là website thương mại điện tử hoặc site nội dung lớn, cần xem tốc độ như một hạng mục kỹ thuật bắt buộc, tương đương với bảo mật hay tính ổn định hệ thống.




Các template quan trọng cần được kiểm tra riêng biệt trên cả mobile và desktop gồm:

• Trang chủ (home)
• Trang category / listing sản phẩm / danh mục bài viết
• Trang chi tiết sản phẩm
• Trang chi tiết bài viết / blog / tin tức
• Landing page (đặc biệt là landing chạy quảng cáo)

Mỗi template nên được test bằng PageSpeed Insights và/hoặc Lighthouse ở chế độ mô phỏng mobile và desktop. Không chỉ nhìn điểm tổng (Performance score) mà cần soi kỹ:

• Các chỉ số Core Web Vitals: LCP, INP, CLS (và FID nếu còn xuất hiện trong báo cáo cũ)
• Thời gian tải nội dung hiển thị đầu tiên (FCP), Time to First Byte (TTFB)
• Số lượng request, dung lượng tổng tài nguyên tải về, số lượng JS/CSS

Mục tiêu là đạt ngưỡng “Good” cho Core Web Vitals, nhưng quan trọng hơn là trải nghiệm thực tế: nội dung chính phải hiển thị nhanh, thao tác cuộn và click mượt, không giật lag. Nên test thêm bằng cách:

• Dùng thiết bị thật (điện thoại tầm trung, mạng 4G) để cảm nhận tốc độ
• Thử truy cập lần đầu (chưa cache) và lần sau (đã cache) để so sánh
• Thử truy cập từ nhiều khu vực địa lý khác nhau nếu có người dùng phân tán

Trong biên bản nghiệm thu, nên có mục riêng ghi nhận kết quả đo tốc độ cho từng template, bao gồm:

• Ảnh chụp màn hình báo cáo PageSpeed Insights / Lighthouse
• Link trực tiếp tới báo cáo (nếu có thể lưu lại URL)
• Ghi chú ngắn về các cảnh báo quan trọng (ví dụ: LCP cao, INP kém, TTFB chậm)

Nếu có template nào quá chậm, cần phân tích nguyên nhân ở mức kỹ thuật chi tiết hơn:

• Ảnh quá nặng, chưa tối ưu định dạng, chưa resize đúng kích thước hiển thị
• JS/CSS chưa nén, chưa gộp file, tải đồng bộ (blocking) thay vì defer/async
• Server phản hồi chậm do cấu hình hosting yếu, database query nặng, không có cache
• Không dùng CDN cho tài nguyên tĩnh, dẫn đến độ trễ cao với người dùng ở xa máy chủ
• Quá nhiều script bên thứ ba (tracking, chat, heatmap, A/B testing) chạy ngay từ đầu

Tối ưu tốc độ ngay từ giai đoạn nghiệm thu giúp tránh việc phải “đập đi xây lại” sau khi site đã vận hành, tiết kiệm chi phí refactor code, nâng cấp hạ tầng và hạn chế rủi ro tụt thứ hạng SEO khi website đã có lưu lượng lớn.

LCP cần được tối ưu bằng ảnh hero nhẹ, preload hợp lý và server response nhanh

Largest Contentful Paint (LCP) đo thời gian để phần tử nội dung lớn nhất trong vùng nhìn thấy đầu tiên (viewport) được render hoàn chỉnh. Thực tế, phần tử này thường là:

• Ảnh hero hoặc banner lớn ở đầu trang
• Background image của section đầu tiên (nếu được tính là phần tử hiển thị)
• Block text lớn (heading + đoạn mô tả) hoặc card nội dung nổi bật




Để tối ưu LCP, cần tiếp cận theo nhiều lớp:

• Tối ưu ảnh hero
  • Nén ảnh với chất lượng hợp lý, ưu tiên định dạng hiện đại như WebP, AVIF (nếu hệ thống và trình duyệt mục tiêu hỗ trợ)
  • Đảm bảo kích thước ảnh đúng với kích thước hiển thị thực tế, tránh dùng ảnh 4000px cho vùng hiển thị 1200px
  • Sử dụng srcset và sizes để trình duyệt chọn phiên bản ảnh phù hợp với độ phân giải màn hình
  • Tránh lazy load cho ảnh LCP trong viewport đầu tiên, vì sẽ làm chậm LCP
• Preload tài nguyên quan trọng
  • Preload CSS chính (critical CSS) để giảm thời gian chặn render
  • Preload font web quan trọng, đặc biệt là font dùng cho heading/hero text
  • Preload ảnh hero nếu chắc chắn đó là phần tử LCP và không gây lãng phí băng thông
• Tối ưu server và TTFB
  • Cải thiện thời gian phản hồi server (TTFB) bằng cách tối ưu code backend, query database, cấu hình cache phía server
  • Sử dụng reverse proxy (như Nginx) và cache toàn trang (full-page cache) cho các trang ít thay đổi
  • Đảm bảo hạ tầng hosting đủ tài nguyên CPU/RAM, không quá tải khi có nhiều truy cập đồng thời

Khi nghiệm thu, cần kiểm tra báo cáo LCP trong PageSpeed Insights cho từng template, đặc biệt là:

• Trang chủ và landing page bán hàng (thường có hero lớn, nhiều banner)
• Trang sản phẩm có ảnh lớn ở trên cùng

Nếu LCP trên mobile vượt ngưỡng khuyến nghị (thường < 2.5s cho mức “Good”), cần yêu cầu đơn vị triển khai điều chỉnh cụ thể:

• Giảm kích thước và dung lượng ảnh hero, tách ảnh desktop/mobile nếu cần
• Tối ưu hosting, bật cache phía server, sử dụng CDN cho ảnh và static assets
• Giảm số lượng request ban đầu bằng cách gộp CSS/JS quan trọng, loại bỏ tài nguyên không dùng
• Đảm bảo không có script nặng chặn render ở phần trên màn hình (above the fold)

LCP tốt không chỉ giúp cải thiện SEO mà còn tác động trực tiếp đến tỷ lệ thoát (bounce rate) và tỷ lệ chuyển đổi, vì người dùng có xu hướng rời đi nếu nội dung chính không xuất hiện đủ nhanh.

INP cần kiểm soát JavaScript, third-party script và tương tác nặng

Interaction to Next Paint (INP) đo độ trễ tổng thể khi người dùng tương tác với trang (click, tap, nhập liệu) cho đến khi trình duyệt render khung hình tiếp theo phản hồi lại hành động đó. INP kém thường xuất phát từ:

• Bundle JavaScript quá lớn, nhiều logic chạy trên main thread
• Quá nhiều script bên thứ ba: chat, tracking, tag manager, widget nhúng
• DOM phức tạp, nhiều node, thao tác DOM nặng trong event handler
• Re-render lớn trong các framework SPA (React, Vue, Angular) khi có tương tác




Để tối ưu INP, cần tập trung vào việc giảm tải cho main thread và tối ưu cách xử lý tương tác:

• Giảm kích thước và độ phức tạp của JavaScript
  • Code splitting, chỉ load JS cần thiết cho từng trang hoặc từng phần chức năng
  • Tree-shaking để loại bỏ code không dùng trong bundle
  • Minify và nén JS, loại bỏ polyfill không cần thiết cho tập trình duyệt mục tiêu
• Quản lý script bên thứ ba
  • Đánh giá lại sự cần thiết của từng script: tracking, chat, popup, heatmap,…
  • Trì hoãn (defer) hoặc tải sau khi tương tác (on user interaction) với các script không quan trọng cho lần tải đầu
  • Hạn chế chạy nhiều công cụ phân tích cùng lúc (ví dụ nhiều nền tảng analytics trùng chức năng)
• Tối ưu xử lý sự kiện
  • Tránh thực hiện các tác vụ nặng (tính toán phức tạp, thao tác DOM lớn) trực tiếp trong event handler
  • Sử dụng Web Worker cho các tác vụ tính toán nặng nếu phù hợp
  • Batch các cập nhật DOM, tránh cập nhật từng phần nhỏ liên tục

Trong giai đoạn nghiệm thu, cần kiểm tra INP trên các trang có nhiều tương tác quan trọng:

• Form đăng ký, form lead, form liên hệ
• Giỏ hàng, trang thanh toán, bước nhập thông tin khách hàng
• Trang có chat widget, popup, hoặc nhiều nút call-to-action

Cần test bằng cả công cụ (PageSpeed Insights, Lighthouse) và trải nghiệm thực tế: nếu sau khi click nút “Thêm vào giỏ” hoặc “Thanh toán” mà người dùng phải chờ lâu mới thấy phản hồi (loading, thay đổi trạng thái nút, chuyển trang), đó là dấu hiệu INP kém. Khi đó, cần yêu cầu tối ưu lại luồng xử lý, giảm JS không cần thiết và đảm bảo phản hồi giao diện xảy ra càng sớm càng tốt, ngay cả khi xử lý backend vẫn đang diễn ra.

CLS cần tránh layout shift từ ảnh, font, banner, popup và iframe

Cumulative Layout Shift (CLS) đo tổng mức độ thay đổi bố cục bất ngờ trong quá trình tải trang. CLS cao gây khó chịu cho người dùng vì nội dung “nhảy” liên tục, dễ dẫn đến click nhầm, đặc biệt trên mobile. Các nguyên nhân phổ biến:

• Ảnh không khai báo kích thước (width/height) hoặc không có container cố định
• Font web load chậm, gây hiện tượng “nhảy chữ” khi font thay đổi (FOIT/FOUT)
• Banner, quảng cáo, popup xuất hiện muộn, đẩy nội dung xuống
• Iframe nhúng (video, map, widget) không có khung kích thước cố định




Để kiểm soát CLS, cần áp dụng các nguyên tắc bố cục ổn định:

• Khai báo width/height cho ảnh, hoặc dùng CSS đặt tỉ lệ khung (aspect-ratio) để trình duyệt dành sẵn không gian
• Đặt container cố định cho banner, quảng cáo, popup; nếu nội dung chưa load thì vẫn giữ chỗ bằng skeleton hoặc placeholder
• Tối ưu font web bằng preload, font-display phù hợp, và font fallback có kích thước gần giống
• Đặt kích thước cố định cho iframe (ví dụ video YouTube, bản đồ) bằng CSS, tránh để auto height gây nhảy layout khi nội dung load

Khi nghiệm thu, cần test trang trên cả mobile và desktop, chú ý:

• Cuộn chậm từ trên xuống dưới để quan sát xem có phần tử nào xuất hiện muộn làm dịch chuyển nội dung
• Kiểm tra các trang có nhiều banner, popup, quảng cáo, hoặc nội dung nhúng
• Test với mạng chậm để dễ thấy các layout shift xảy ra khi tài nguyên load từ từ

CLS tốt giúp website trông chuyên nghiệp, ổn định, tăng độ tin cậy và giảm tỷ lệ người dùng bỏ trang vì khó thao tác.

Cache, CDN, nén tài nguyên và lazy loading cần được cấu hình đúng

Các kỹ thuật như cache, CDN, nén tài nguyên (Gzip, Brotli) và lazy loading là nền tảng cho hiệu năng web hiện đại. Khi nghiệm thu, không chỉ cần “có bật” mà còn phải cấu hình đúng và kiểm tra hiệu quả thực tế.




Các điểm cần kiểm tra:

• Cache
  • Cache phía server (full-page cache, object cache) đã được bật và hoạt động ổn định
  • Header cache-control cho tài nguyên tĩnh (CSS, JS, ảnh) có thời gian sống (TTL) đủ dài
  • Cơ chế purge/invalidate cache khi cập nhật nội dung hoặc deploy phiên bản mới
• CDN
  • CDN đã được cấu hình cho domain chính hoặc ít nhất cho static assets
  • Kiểm tra request thực tế để đảm bảo tài nguyên được phân phối từ edge server gần người dùng
  • Đảm bảo không có lỗi mixed content hoặc cấu hình sai origin gây chậm hoặc lỗi tải
• Nén tài nguyên
  • Gzip hoặc Brotli đã bật cho HTML, CSS, JS
  • Kiểm tra header phản hồi để xác nhận content-encoding đúng
  • Đảm bảo nén không gây lỗi cho một số loại file đặc biệt (ví dụ file đã nén sẵn)
• Lazy loading
  • Áp dụng lazy load cho ảnh và video nằm dưới màn hình đầu tiên (below the fold)
  • Không lazy load ảnh LCP hoặc các phần tử quan trọng trong viewport đầu tiên
  • Kiểm tra tương thích với SEO (ví dụ dùng loading="lazy" chuẩn HTML và đảm bảo bot vẫn truy cập được nội dung quan trọng)

Trong biên bản nghiệm thu, nên có mục xác nhận kỹ thuật:

• Website đã bật cache ở mức server hoặc thông qua plugin/hệ thống cache chuyên dụng
• CDN đã được cấu hình (nếu có trong phạm vi hợp đồng) và hoạt động đúng
• Nén Gzip/Brotli đã bật cho các loại tài nguyên cần thiết
• Lazy loading đã được áp dụng cho ảnh/video ngoài màn hình đầu tiên mà không ảnh hưởng đến LCP và SEO

Có thể sử dụng các công cụ kiểm tra header HTTP, DevTools của trình duyệt và PageSpeed Insights để xác nhận các cấu hình này. Việc thiết lập đúng ngay từ đầu thể hiện năng lực kỹ thuật của đơn vị triển khai và giúp website sẵn sàng cho lưu lượng truy cập lớn, giảm chi phí hạ tầng trong dài hạn.

Kiểm tra responsive, mobile-first và khả năng truy cập




Giao diện mobile phải hiển thị đầy đủ nội dung, CTA, menu và form quan trọng

Trong bối cảnh mobile-first indexing, Google chủ yếu thu thập và đánh giá nội dung dựa trên phiên bản mobile. Điều này có nghĩa: nếu nội dung, CTA hoặc menu chỉ xuất hiện trên desktop mà bị ẩn hoặc rút gọn quá mức trên mobile, Google có thể coi như nội dung đó không tồn tại hoặc ít quan trọng hơn. Vì vậy, mọi nội dung cốt lõi phục vụ SEO và chuyển đổi (content chính, internal link, CTA, form, menu điều hướng) cần xuất hiện đầy đủ và có thể tương tác tốt trên mobile.




Không nên dùng kỹ thuật ẩn nội dung (display:none, visibility:hidden, accordion đóng kín toàn bộ, tab ẩn) cho các đoạn nội dung quan trọng chỉ vì muốn giao diện “gọn” hơn. Có thể rút gọn bằng cách chia khối, dùng heading rõ ràng, accordion có trạng thái mở mặc định cho phần quan trọng, hoặc ưu tiên thứ tự hiển thị, nhưng không được loại bỏ nội dung chính khỏi DOM trên mobile.

Khi nghiệm thu, cần lập danh sách các template quan trọng và test lần lượt trên nhiều kích thước màn hình:

• Trang chủ: hero banner, USP, danh mục chính, sản phẩm nổi bật, CTA chính (đăng ký, mua hàng, liên hệ).
• Trang category / danh sách: bộ lọc (filter), sắp xếp (sort), breadcrumb, phân trang, CTA xem chi tiết / thêm giỏ.
• Trang sản phẩm: hình ảnh, gallery, giá, khuyến mãi, thông số, mô tả chi tiết, đánh giá, CTA “Mua ngay”, “Thêm vào giỏ”.
• Trang bài viết: tiêu đề, ngày, tác giả (nếu cần cho EEAT), mục lục (TOC), nội dung, box liên quan, CTA đăng ký / tải tài liệu.
• Landing page: section lợi ích, bằng chứng xã hội (social proof), bảng giá, FAQ, form đăng ký, CTA chính/phụ.

Cần kiểm tra trên các breakpoint phổ biến (ví dụ: 320px, 375px, 414px, 768px) để đảm bảo:

• Không có phần nội dung bị cắt, tràn ngang (horizontal scroll) hoặc bị che bởi khung cố định.
• Không phải zoom mới đọc được text hoặc bấm được nút.
• CTA luôn hiển thị rõ ràng, không bị dồn xuống quá sâu hoặc bị che bởi sticky bar, chat widget.
• Form hiển thị đủ trường, label rõ ràng, không bị vỡ layout khi xoay ngang màn hình.

Form nên được tối ưu cho mobile-first: giảm tối đa trường không cần thiết, dùng đúng loại input (email, tel, number) để kích hoạt bàn phím phù hợp, bật/tắt auto-capitalize, auto-correct hợp lý. Với các form quan trọng (đăng ký, thanh toán), nên test toàn bộ luồng: nhập liệu, báo lỗi, thông báo thành công, chuyển trang cảm ơn.

Font, khoảng cách, nút bấm và trường nhập liệu cần dễ thao tác trên màn hình nhỏ

Trải nghiệm người dùng trên mobile phụ thuộc nhiều vào typography và kích thước vùng tương tác. Font chữ quá nhỏ hoặc line-height quá thấp sẽ khiến người dùng phải zoom, tăng tỷ lệ thoát và giảm thời gian on-site. Về mặt kỹ thuật, nên ưu tiên:

• Kích thước font thân bài tối thiểu khoảng 14–16px trên mobile, heading lớn hơn tương ứng để tạo phân cấp thị giác.
• Line-height khoảng 1.4–1.6 cho đoạn văn để dễ đọc, tránh cảm giác “dính chữ”.
• Khoảng cách giữa các đoạn, giữa các block nội dung đủ rộng để người dùng không bị “ngợp” khi cuộn.

Đối với nút bấm và trường nhập liệu, cần đảm bảo kích thước vùng chạm (hit area) tối thiểu khoảng 44x44px theo khuyến nghị của nhiều guideline UX. Không chỉ kích thước nút, mà khoảng cách giữa các nút cũng quan trọng để tránh bấm nhầm, đặc biệt với các hành động quan trọng như “Xóa”, “Thanh toán”, “Hủy”.

Trong quá trình nghiệm thu, nên thao tác thực tế trên thiết bị thật thay vì chỉ xem trên trình giả lập:

• Cuộn nhanh và chậm để xem nội dung có bị giật, lag, hay layout nhảy bất thường không.
• Click vào các link text nhỏ để kiểm tra có dễ bấm nhầm sang phần tử khác không.
• Nhập liệu vào form dài (địa chỉ, ghi chú) để xem keyboard có che mất trường nhập, nút gửi có luôn hiển thị không.

Nếu phải zoom để đọc hoặc dễ bấm nhầm, cần yêu cầu điều chỉnh CSS: tăng font-size, line-height, padding của nút, margin giữa các phần tử. Các nút quan trọng như “Mua ngay”, “Đăng ký”, “Liên hệ” nên được đặt ở vị trí dễ chạm bằng ngón tay cái (thường là nửa dưới màn hình), tránh đặt quá sát mép trên hoặc sát cạnh màn hình. Có thể cân nhắc sticky CTA ở cuối màn hình, nhưng phải đảm bảo không che nội dung quan trọng hoặc gây khó chịu.

Nội dung không bị che bởi popup, sticky bar hoặc banner cookie

Các thành phần như popup, sticky bar, banner cookie, chat widget, notification bar nếu thiết kế không khéo sẽ che mất nội dung chính, đặc biệt trên mobile nơi diện tích hiển thị rất hạn chế. Google có hướng dẫn rõ về việc hạn chế interstitial gây khó chịu, đặc biệt là các popup toàn màn hình xuất hiện ngay khi người dùng vừa vào trang từ kết quả tìm kiếm.




Một số lỗi thường gặp:

• Popup xuất hiện ngay lập tức, che toàn bộ nội dung, nút đóng nhỏ hoặc khó thấy.
• Sticky bar ở trên cùng + chat widget ở góc + banner cookie ở dưới cùng khiến vùng nội dung bị kẹp lại rất hẹp.
• Popup không responsive, vượt khỏi màn hình, người dùng không thể cuộn để tìm nút đóng.
• Banner cookie chiếm 1/3 màn hình trên mobile, che mất CTA hoặc phần nội dung đầu trang.

Khi nghiệm thu, cần test các kịch bản hành vi người dùng:

• Người dùng mới vào trang lần đầu: popup/email capture có xuất hiện không, có che toàn bộ nội dung không, nút đóng có rõ ràng và đủ lớn không.
• Người dùng cuộn xuống khoảng 30–50% trang: có xuất hiện thêm popup/slide-in nào nữa không, có gây chồng chéo với sticky bar không.
• Người dùng chuẩn bị thoát (exit-intent trên desktop, back button trên mobile): có hiển thị popup thoát không, có gây khó khăn khi quay lại SERP không.

Nếu website cần hiển thị thông báo cookie để tuân thủ pháp lý, nên dùng banner gọn, chiếm ít chiều cao, có nút chấp nhận rõ ràng và không chặn thao tác cuộn. Có thể đặt banner dạng thanh mỏng ở trên hoặc dưới, tránh dạng overlay toàn màn hình trên mobile. Với sticky bar (ví dụ: thanh “Gọi ngay”, “Chat ngay”), nên giới hạn số lượng, ưu tiên 1–2 hành động quan trọng, tránh xếp chồng nhiều icon gây rối mắt.

Màu sắc, nhãn form, alt text và điều hướng bàn phím cần hỗ trợ accessibility cơ bản

Accessibility (khả năng truy cập) là một phần quan trọng của trải nghiệm người dùng và cũng là tín hiệu gián tiếp cho EEAT, vì nó thể hiện mức độ chuyên nghiệp và sự quan tâm đến đa dạng người dùng. Một số nguyên tắc cơ bản cần đảm bảo:

• Màu sắc và độ tương phản: Văn bản cần có độ tương phản đủ cao so với nền (theo chuẩn WCAG, tỷ lệ tối thiểu 4.5:1 cho text thông thường). Tránh dùng màu chữ xám nhạt trên nền trắng, hoặc chữ màu trên nền ảnh mà không có lớp phủ (overlay).
• Nhãn form (label): Không chỉ dựa vào placeholder, vì placeholder biến mất khi người dùng bắt đầu nhập, gây khó nhớ. Mỗi trường nên có label rõ ràng, gắn đúng với input để screen reader đọc được.
• Alt text cho ảnh: Ảnh mang thông tin (infographic, ảnh sản phẩm, icon có ý nghĩa) cần có alt text mô tả ngắn gọn, giúp người dùng dùng screen reader hiểu nội dung. Ảnh chỉ mang tính trang trí có thể để alt rỗng.
• Điều hướng bằng bàn phím: Các thành phần chính (menu, link, nút, form) phải có thể focus bằng phím Tab, thứ tự focus logic, và trạng thái focus được hiển thị rõ (outline, đổi màu).




Trong giai đoạn nghiệm thu, có thể dùng một số công cụ kiểm tra contrast và accessibility cơ bản để phát hiện nhanh lỗi màu sắc, thiếu label, thiếu alt. Đồng thời, nên test form và menu bằng cách dùng phím Tab để di chuyển giữa các trường và link, kiểm tra xem có phần tử nào không thể focus, hoặc bị “mắc kẹt” khi điều hướng.

Nếu website hướng đến đối tượng người dùng rộng, bao gồm người lớn tuổi hoặc người có hạn chế thị lực, việc chú ý đến accessibility sẽ giúp:

• Tăng khả năng đọc hiểu nội dung trên mobile, đặc biệt trong điều kiện ánh sáng ngoài trời.
• Giảm lỗi nhập liệu do label không rõ hoặc placeholder gây nhầm lẫn.
• Cải thiện cảm nhận về sự tin cậy, chuyên nghiệp, từ đó hỗ trợ EEAT một cách gián tiếp.

Website cần hiển thị ổn định trên các trình duyệt và thiết bị phổ biến

Một website chuẩn SEO không chỉ chạy tốt trên một trình duyệt duy nhất hoặc một loại thiết bị. Người dùng có thể truy cập từ Chrome trên Android, Safari trên iOS, Firefox trên desktop, hoặc Edge trên Windows. Một số lỗi CSS (flex, grid, prefix), JS (API không được hỗ trợ), hoặc font (format, CORS) có thể chỉ xuất hiện trên một trình duyệt nhất định, gây trải nghiệm không đồng nhất và làm giảm hiệu quả SEO do tăng tỷ lệ thoát ở một nhóm người dùng.




Khi nghiệm thu, nên yêu cầu đơn vị triển khai:

• Cung cấp danh sách trình duyệt đã test (Chrome, Safari, Firefox, Edge, các phiên bản chính gần đây) và hệ điều hành (Windows, macOS, iOS, Android).
• Nêu rõ giới hạn hỗ trợ (ví dụ: không hỗ trợ IE, chỉ tối ưu cho 2 phiên bản mới nhất của mỗi trình duyệt).
• Ghi nhận các known issue nhỏ (nếu có) không ảnh hưởng nghiêm trọng đến trải nghiệm hoặc SEO.

Chủ website cũng nên tự kiểm tra trên các thiết bị mình thường dùng: desktop/laptop, tablet, smartphone, cả ở chế độ dọc và ngang. Cần chú ý:

• Layout có bị vỡ, lệch, hoặc font bị thay thế bất thường trên một trình duyệt cụ thể không.
• Các hiệu ứng JS (slider, accordion, menu dropdown, filter) có hoạt động ổn định, không gây treo trang hoặc lỗi console nghiêm trọng.
• Tốc độ tải trang trên mobile có bị chậm bất thường do script không tương thích hoặc polyfill thiếu.

Sự ổn định đa nền tảng là yếu tố quan trọng để giữ chân người dùng, giảm tỷ lệ thoát và đảm bảo dữ liệu hành vi (dwell time, pages/session) không bị méo do lỗi kỹ thuật trên một nhóm thiết bị nhất định. Điều này gián tiếp hỗ trợ hiệu quả SEO và chuyển đổi, đặc biệt trong môi trường mobile-first nơi phần lớn traffic đến từ thiết bị di động.

Kiểm tra structured data và tín hiệu EEAT




Schema Organization, Breadcrumb, Article, Product, FAQ hoặc LocalBusiness cần đúng loại trang

Structured data (schema) là lớp dữ liệu có cấu trúc giúp công cụ tìm kiếm “gắn nhãn” chính xác cho từng thành phần trên trang: loại trang, thực thể, thuộc tính, mối quan hệ. Việc gắn đúng loại schema không chỉ để lấy rich result mà còn để Google xây dựng mô hình tri thức (Knowledge Graph) về doanh nghiệp và nội dung của bạn.




Mỗi nhóm trang nên được thiết kế và triển khai schema theo một “mẫu chuẩn” (template) rõ ràng:

• Organization: dùng cho trang giới thiệu doanh nghiệp, trang chủ hoặc trang thể hiện thông tin tổng quan về tổ chức (tên pháp lý, logo, số điện thoại, email, địa chỉ, social profile). Không nên gắn Organization cho mọi trang con nếu không cần thiết; thay vào đó, có thể khai báo trong JSON-LD toàn site hoặc ở các trang trụ cột.
• LocalBusiness: dùng cho doanh nghiệp có địa điểm cụ thể (cửa hàng, chi nhánh, phòng khám, văn phòng luật, spa…). Cần khai báo rõ địa chỉ, geo, giờ mở cửa, số điện thoại. Tránh gắn LocalBusiness cho các trang không mang tính “địa điểm”, ví dụ trang blog chi tiết.
• BreadcrumbList: gắn cho breadcrumb điều hướng. Mỗi item phải có vị trí (position), tên (name) và URL (item). Cần đảm bảo breadcrumb hiển thị trên giao diện trùng khớp với thứ tự và đường dẫn trong schema.
• Article hoặc BlogPosting: dùng cho bài viết tin tức, blog, hướng dẫn. Cần khai báo headline, description, author, datePublished, dateModified, image, mainEntityOfPage. Với nội dung mang tính tin tức, có thể ưu tiên Article; với nội dung blog, hướng dẫn, có thể dùng BlogPosting.
• Product: dùng cho trang sản phẩm độc lập, có thông tin giá, tình trạng, mô tả, SKU, brand. Không nên gắn Product cho trang danh mục, trang blog review tổng hợp hoặc landing page không bán trực tiếp.
• FAQPage: chỉ dùng cho trang có cấu trúc Hỏi – Đáp rõ ràng, với danh sách câu hỏi và câu trả lời đầy đủ. Không nên gắn FAQPage cho mọi trang chỉ vì có 1–2 câu hỏi rải rác trong nội dung.

Trong quá trình nghiệm thu, cần:

• Sử dụng công cụ kiểm tra structured data (Rich Results Test, Schema Markup Validator) để xác nhận:
  • Schema đúng loại trang, không gắn tràn lan.
  • Không lỗi cú pháp, không thiếu các thuộc tính bắt buộc (required) hoặc khuyến nghị (recommended) quan trọng.
• Đối chiếu loại template trang với loại schema:
  • Template “Giới thiệu doanh nghiệp” → Organization/LocalBusiness.
  • Template “Bài viết blog/tin tức” → Article/BlogPosting + BreadcrumbList.
  • Template “Trang sản phẩm” → Product + Offer + BreadcrumbList.
  • Template “FAQ độc lập” → FAQPage.

Việc gắn đúng loại schema giúp:

• Tăng khả năng hiển thị rich snippet (FAQ, rating, price, breadcrumb, logo…).
• Cải thiện CTR nhờ kết quả tìm kiếm nổi bật, giàu thông tin.
• Thể hiện sự chuyên nghiệp, tuân thủ guideline, giảm rủi ro bị mất rich result trong các đợt cập nhật thuật toán.

Structured data không được khai báo thông tin sai, ẩn hoặc không xuất hiện trên trang

Nguyên tắc cốt lõi của structured data là tính trung thực và tương ứng với nội dung hiển thị. Schema chỉ nên “đánh dấu” lại những gì đã có trên trang, không được dùng để “bịa thêm” thông tin nhằm thao túng kết quả tìm kiếm.




Các hành vi cần tránh tuyệt đối:

• Khai báo giá khuyến mãi trong schema nhưng trên giao diện không hiển thị giá đó, hoặc chỉ hiển thị giá gốc.
• Khai báo rating 5 sao, số lượng review lớn trong schema Product/AggregateRating nhưng trên trang không có bất kỳ review nào, hoặc chỉ có 1–2 review không đủ dữ liệu.
• Khai báo author, reviewer là chuyên gia, bác sĩ, luật sư… trong schema nhưng trên trang không thể hiện thông tin này, không có tiểu sử hoặc bằng chứng chuyên môn.
• Khai báo FAQPage với danh sách câu hỏi – trả lời trong schema nhưng nội dung đó không xuất hiện trên trang, hoặc chỉ xuất hiện một phần.

Khi nghiệm thu, cần thực hiện quy trình kiểm tra chéo:

• Trích xuất schema (dùng Rich Results Test hoặc view-source) và so sánh từng trường quan trọng với nội dung hiển thị:
  • Giá, loại tiền tệ, tình trạng còn hàng.
  • Số lượng review, điểm rating trung bình, tên người review.
  • Tên tác giả, ngày xuất bản, ngày cập nhật.
  • Câu hỏi và câu trả lời trong FAQ.
• Nếu phát hiện:
  • Thông tin ẩn (chỉ có trong schema, không có trên giao diện).
  • Thông tin sai lệch (giá, rating, ngày tháng không trùng).
  • Thông tin “thổi phồng” (tự tạo review, rating không có thật).
  phải yêu cầu chỉnh sửa ngay, ưu tiên đồng bộ nội dung hiển thị với schema hoặc loại bỏ trường sai.

Tuân thủ nguyên tắc này không chỉ để tránh cảnh báo, manual action từ Google mà còn là nền tảng của Trustworthiness trong EEAT: minh bạch, không lừa dối người dùng và công cụ tìm kiếm.

Trang tác giả, giới thiệu, liên hệ, chính sách và điều khoản cần dễ tìm

Tín hiệu EEAT (Experience, Expertise, Authoritativeness, Trustworthiness) được đánh giá không chỉ qua nội dung bài viết mà còn qua cấu trúc thông tin về tổ chức và cá nhân đứng sau website. Các trang “niềm tin” (trust pages) cần được xây dựng đầy đủ và đặt ở vị trí dễ truy cập (menu chính, menu phụ, footer).




Các trang quan trọng cần có:

• Trang Giới thiệu (About):
  • Mô tả rõ doanh nghiệp/tổ chức: tên pháp lý, lịch sử hình thành, sứ mệnh, giá trị cốt lõi.
  • Thông tin về đội ngũ chủ chốt: người sáng lập, ban lãnh đạo, chuyên gia phụ trách nội dung.
  • Nếu có, thể hiện chứng nhận, giải thưởng, đối tác, thành viên hiệp hội chuyên ngành.
• Trang Tác giả (Author):
  • Tiểu sử ngắn gọn nhưng cụ thể: học vấn, chứng chỉ, kinh nghiệm thực tế, lĩnh vực chuyên môn.
  • Liên kết đến các tổ chức, hiệp hội, nơi làm việc hiện tại (nếu phù hợp).
  • Có thể kèm liên kết đến mạng xã hội chuyên nghiệp (LinkedIn, ResearchGate…) để tăng độ tin cậy.
• Trang Liên hệ (Contact):
  • Nhiều kênh liên lạc: form, email, số điện thoại, địa chỉ văn phòng/cửa hàng.
  • Bản đồ (nếu là LocalBusiness), giờ làm việc, hướng dẫn liên hệ cho từng mục đích (hỗ trợ, hợp tác, báo lỗi nội dung…).
• Chính sách bảo mật (Privacy Policy):
  • Giải thích cách thu thập, sử dụng, lưu trữ dữ liệu người dùng.
  • Thông tin về cookie, công cụ đo lường (Analytics, Ads), quyền của người dùng.
• Điều khoản sử dụng (Terms of Use):
  • Quy định về việc sử dụng nội dung, bản quyền, giới hạn trách nhiệm.
  • Điều kiện khi sử dụng dịch vụ, mua hàng, gửi thông tin.

Trong giai đoạn nghiệm thu, cần kiểm tra:

• Các trang trên đã tồn tại chưa, có thể truy cập từ menu hoặc footer trong tối đa 1–2 lần click.
• Nội dung có cập nhật, rõ ràng, không để placeholder hoặc nội dung mẫu chung chung.
• Liên kết nội bộ từ bài viết đến trang tác giả (author page) và từ author page quay lại danh sách bài viết của tác giả.

Việc tổ chức tốt các trang này giúp người dùng và Google hiểu rõ “ai chịu trách nhiệm” cho nội dung, từ đó củng cố Authoritativeness và Trustworthiness của website.

Nội dung chuyên môn cần có nguồn tham khảo, ngày cập nhật, người chịu trách nhiệm hoặc bằng chứng thực tế

Với nội dung mang tính chuyên môn cao hoặc thuộc nhóm YMYL (Your Money Your Life) như tài chính, y tế, pháp lý, giáo dục, tiêu chuẩn EEAT được áp dụng nghiêm ngặt hơn. Mỗi bài viết không chỉ cần “đúng” mà còn phải thể hiện rõ ai chịu trách nhiệm, dựa trên cơ sở nào, và cập nhật đến thời điểm nào.




Các yếu tố nên có trong mỗi bài viết chuyên sâu:

• Tên tác giả và chức danh:
  • Hiển thị rõ ràng ở đầu hoặc cuối bài: tên, chức danh, chuyên môn.
  • Có liên kết đến trang tác giả để người đọc kiểm tra thêm thông tin.
• Ngày xuất bản và ngày cập nhật:
  • Ghi rõ datePublished và dateModified, đồng bộ với schema Article/BlogPosting.
  • Với lĩnh vực thay đổi nhanh (luật, thuế, y khoa, lãi suất…), cần cập nhật định kỳ và ghi rõ “Cập nhật lần cuối”.
• Nguồn tham khảo đáng tin cậy:
  • Liệt kê nguồn ở cuối bài: nghiên cứu khoa học, văn bản pháp luật, tài liệu chính thống, báo cáo từ tổ chức uy tín.
  • Tránh dẫn nguồn mơ hồ, blog cá nhân không có chuyên môn, hoặc nguồn không thể kiểm chứng.
• Bằng chứng thực tế:
  • Case study, số liệu thực tế, ví dụ triển khai, trích dẫn nghiên cứu.
  • Nếu có, thể hiện rõ phạm vi áp dụng, bối cảnh, giới hạn của ví dụ để tránh hiểu sai.

Trong quá trình nghiệm thu, nên chọn một số bài viết chuyên sâu để kiểm tra chi tiết:

• Có hiển thị tên tác giả, chức danh, liên kết đến trang tác giả không.
• Có ngày xuất bản và ngày cập nhật, và hai mốc này có được phản ánh đúng trong schema không.
• Có phần “Nguồn tham khảo” hoặc “Tài liệu tham khảo” ở cuối bài, với nguồn rõ ràng.
• Nếu website thuộc lĩnh vực nhạy cảm, có mô tả quy trình biên tập: ai viết, ai kiểm duyệt, ai chịu trách nhiệm cuối cùng cho nội dung.

Cách trình bày này giúp Google đánh giá cao Expertise và Experience, đồng thời bảo vệ uy tín thương hiệu khi nội dung được trích dẫn hoặc kiểm tra chéo.

Review, rating, giá và tồn kho phải khớp nội dung hiển thị nếu dùng schema sản phẩm

Với website thương mại điện tử, schema Product và Offer là nền tảng để hiển thị rich result về giá, tình trạng còn hàng, đánh giá, xếp hạng. Tuy nhiên, mọi thông tin trong schema phải khớp tuyệt đối với nội dung hiển thị trên trang sản phẩm.




Các trường quan trọng cần đồng bộ:

• Giá (price) và loại tiền tệ (priceCurrency):
  • Giá trong schema phải trùng với giá hiển thị (giá bán hiện tại, không phải giá cũ nếu đã hết khuyến mãi).
  • Nếu có giá khuyến mãi, cần hiển thị rõ trên giao diện và phản ánh đúng trong schema (price, priceValidUntil nếu có).
• Tình trạng còn hàng (availability):
  • Schema dùng các giá trị như InStock, OutOfStock, PreOrder… phải khớp với trạng thái hiển thị (Còn hàng, Hết hàng, Đặt trước…).
  • Nếu hệ thống tồn kho cập nhật tự động, cần đảm bảo schema cũng được cập nhật tương ứng.
• Review và rating (Review, AggregateRating):
  • Số lượng review, điểm trung bình, tên người review trong schema phải trùng với phần đánh giá hiển thị.
  • Nếu chưa có review thực tế, không nên khai báo rating giả hoặc tạo review ảo trong schema.

Trong quá trình nghiệm thu, cần:

• Chọn ngẫu nhiên một số trang sản phẩm ở các nhóm khác nhau (bán chạy, mới, hết hàng) để kiểm tra:
  • Giá trong schema so với giá hiển thị.
  • Trạng thái InStock/OutOfStock/PreOrder so với giao diện.
  • Số lượng review và rating trong schema so với phần đánh giá trên trang.
• Kiểm tra logic cập nhật:
  • Khi giá thay đổi, hệ thống có tự cập nhật schema không hay phải chỉnh tay.
  • Khi sản phẩm hết hàng, availability trong schema có đổi sang OutOfStock không.

Sự nhất quán giữa schema và nội dung hiển thị là điều kiện để duy trì rich snippet ổn định, tránh bị Google loại bỏ dữ liệu có cấu trúc hoặc đánh giá website là thiếu minh bạch trong hoạt động thương mại.

Kiểm tra tracking, analytics và dữ liệu đo lường SEO




Google Search Console, GA4, Google Tag Manager hoặc công cụ analytics cần được bàn giao quyền sở hữu

Một website chuẩn SEO không thể thiếu hệ thống đo lường dữ liệu được thiết lập bài bản, có cấu trúc và có người sở hữu rõ ràng. Về mặt quản trị, chủ website cần nắm quyền Owner/Admin tối cao đối với các tài khoản: Google Search Console (GSC), Google Analytics 4 (GA4), Google Tag Manager (GTM) hoặc các công cụ analytics khác (Matomo, Plausible, Adobe Analytics, v.v.) đang sử dụng. Điều này không chỉ để “có quyền truy cập”, mà còn để:

• Kiểm soát toàn bộ dữ liệu tìm kiếm, hành vi người dùng và chuyển đổi.
• Chủ động thay đổi nhà cung cấp dịch vụ mà không bị “giữ dữ liệu làm con tin”.
• Quản lý phân quyền, bảo mật, tuân thủ chính sách dữ liệu nội bộ.

Không nên để tài khoản nằm hoàn toàn trong tay đơn vị triển khai mà không có quyền truy cập của chủ doanh nghiệp, vì:

• Rủi ro mất dữ liệu lịch sử nếu bị xóa property hoặc thay đổi quyền.
• Khó kiểm tra độc lập các chỉ số SEO, traffic, conversion.
• Không thể tích hợp với các hệ thống nội bộ (CRM, BI, Data Warehouse).

Trong biên bản bàn giao, cần liệt kê chi tiết và có tính pháp lý hơn:

• Email đang giữ quyền Owner của GSC, GA4, GTM và các công cụ analytics khác.
• Danh sách user được cấp quyền, kèm loại quyền: Viewer, Analyst, Editor, Admin, Owner.
• Quyền của đơn vị triển khai: chỉ nên ở mức Editor hoặc tối đa Admin nếu thật sự cần, tránh để họ là Owner duy nhất.
• Quy ước: mọi property mới (website mới, subdomain mới, app mới) phải được tạo dưới tài khoản email thuộc doanh nghiệp.

Nên yêu cầu đơn vị triển khai:

• Chụp screenshot màn hình phần phân quyền (Access Management) của GSC, GA4, GTM đính kèm biên bản.
• Ghi rõ cấu trúc tài khoản GA4: Account > Property > Data Stream; cấu trúc GTM: Account > Container > Workspace.
• Ghi chú các tích hợp quan trọng: GA4 liên kết với Google Ads, Search Console, BigQuery; GTM liên kết với các template tag quan trọng.

Việc này đảm bảo tính minh bạch, giúp chủ website chủ động nếu sau này thay đổi nhà cung cấp dịch vụ, đồng thời giảm rủi ro mất mát dữ liệu hoặc gián đoạn tracking khi chuyển giao.

Sự kiện quan trọng như form submit, call click, chat, add to cart, purchase hoặc demo booking cần được tracking

Để đánh giá hiệu quả SEO và marketing ở mức chuyên sâu, cần tracking các sự kiện chuyển đổi và các micro-conversion quan trọng, không chỉ dừng ở pageview. Các nhóm sự kiện nên được phân loại rõ:

• Lead generation: gửi form, đăng ký tư vấn, đăng ký nhận báo giá, đăng ký newsletter.
• Contact intent: click gọi điện (tel:), click gửi email (mailto:), click mở ứng dụng chat (Zalo, Messenger, WhatsApp, live chat).
• Ecommerce: view product, add to cart, begin checkout, add payment info, purchase, refund.
• Product engagement: xem video sản phẩm, tải tài liệu, xem pricing, đăng ký demo, booking lịch hẹn.




Những sự kiện này nên được thiết lập trong GTM và gửi về GA4 theo chuẩn:

• Sử dụng event name rõ ràng, có quy ước thống nhất (ví dụ: generatelead, submitform, callclick, addtocart, purchase, bookdemo).
• Gửi kèm event parameters quan trọng: formid, formname, pagelocation, productid, productname, value, currency, leadtype, v.v.
• Đối với ecommerce, nên tuân theo chuẩn GA4 recommended events để tận dụng đầy đủ báo cáo.

Khi nghiệm thu, cần test từng sự kiện theo quy trình có kiểm soát:

• Điền form và gửi, kiểm tra:
  • Form gửi thành công, có thông báo/thank-you page.
  • Sự kiện submitform hoặc generatelead xuất hiện trong DebugView GA4.
  • Thông tin quan trọng (loại form, trang gửi form) được ghi nhận đúng parameter.
• Click vào số điện thoại, icon gọi, nút “Gọi ngay”:
  • Trình quay số mở đúng số.
  • Sự kiện callclick hoặc tương đương được ghi nhận.
• Thêm sản phẩm vào giỏ, bắt đầu thanh toán, hoàn tất đơn hàng:
  • Giỏ hàng cập nhật đúng số lượng, giá trị.
  • Các sự kiện addtocart, begincheckout, purchase được gửi với đầy đủ thông tin sản phẩm và giá trị đơn hàng.
• Đặt lịch demo/booking:
  • Hệ thống booking ghi nhận lịch hẹn.
  • Sự kiện bookdemo hoặc generatelead được tracking, gắn với trang và nguồn traffic.

Sau khi test, cần kiểm tra trong DebugView của GA4 hoặc chế độ preview của GTM để xác nhận:

• Sự kiện được bắn đúng lúc, không trùng lặp, không bắn khi form lỗi.
• Không có sự kiện “ảo” do auto-event trigger sai (ví dụ: click bất kỳ cũng tính là conversion).
• Các sự kiện quan trọng đã được đánh dấu là conversion trong GA4.

Nếu không có tracking chuyển đổi hoặc tracking sai, mọi nỗ lực SEO sẽ khó đo lường giá trị thực tế, dễ dẫn đến quyết định sai về ngân sách, nội dung và chiến lược kênh.

Conversion phải được test trên mobile, desktop và các trình duyệt chính

Chuyển đổi (conversion) có thể hoạt động tốt trên desktop nhưng lỗi trên mobile hoặc ngược lại, đặc biệt với các website dùng nhiều script, popup, iframe hoặc các form nhúng từ bên thứ ba. Vì vậy, kiểm thử đa nền tảng là bắt buộc, không chỉ là “khuyến nghị”.




Cần test toàn bộ luồng chuyển đổi trên nhiều thiết bị và trình duyệt:

• Thiết bị: mobile (iOS, Android), tablet (nếu có lượng traffic đáng kể), desktop/laptop.
• Trình duyệt chính: Chrome, Safari, Firefox, Edge; với mobile nên chú ý Safari (iOS) và Chrome (Android).
• Luồng hành vi: điền form, đăng ký, tải tài liệu, thêm vào giỏ, thanh toán, đăng ký demo.

Mỗi bước cần được kiểm tra cả về:

• Chức năng: form có validate đúng, nút có bấm được, không bị che bởi sticky header/footer, không bị lỗi layout trên màn hình nhỏ.
• Tracking: sự kiện có bắn đúng, không bị chặn bởi lỗi script, không bị ảnh hưởng bởi ad-block phổ biến.

Trong biên bản nghiệm thu, nên có mục xác nhận chi tiết:

• Các luồng chuyển đổi chính đã được test trên:
  • Chrome, Safari, Firefox, Edge (phiên bản mới nhất hoặc phiên bản chiếm đa số traffic).
  • Mobile (iOS, Android) và desktop.
• Không có lỗi chặn người dùng hoàn tất hành động (form không gửi được, nút không hoạt động, trang thanh toán lỗi, v.v.).
• Tracking conversion hoạt động đồng nhất giữa các thiết bị, không bị thiếu dữ liệu trên một nền tảng cụ thể.

Nếu phát hiện lỗi, cần ưu tiên sửa ngay vì đây là phần trực tiếp ảnh hưởng đến doanh thu và lead. Với các website có traffic lớn, nên lập checklist test định kỳ sau mỗi lần cập nhật code, theme, plugin hoặc thay đổi script tracking.

UTM, pixel, cookie consent và ecommerce tracking cần hoạt động đúng mục tiêu kinh doanh

Các chiến dịch marketing thường sử dụng UTM để phân biệt nguồn traffic, pixel (Facebook, TikTok, v.v.) để remarketing, cookie consent để tuân thủ quy định bảo mật dữ liệu, và ecommerce tracking để đo doanh thu và hành vi mua hàng. Những thành phần này cần được cấu hình đúng, đồng bộ với mục tiêu kinh doanh và chiến lược dữ liệu.




Khi nghiệm thu, cần kiểm tra kỹ:

• UTM:
  • Link từ các chiến dịch có gắn UTM đúng chuẩn (utmsource, utmmedium, utmcampaign, utmcontent, utm_term).
  • Quy ước đặt tên UTM thống nhất để dễ phân tích (ví dụ: medium = cpc, email, social, không dùng quá nhiều biến thể khó lọc).
  • GA4 ghi nhận đúng nguồn/medium, không bị “vỡ” thành direct do lỗi redirect hoặc mất UTM.
• Pixel:
  • Pixel Facebook, TikTok, LinkedIn, v.v. được gắn qua GTM hoặc trực tiếp, nhưng nên ưu tiên GTM để dễ quản lý.
  • Các sự kiện quan trọng (Lead, Purchase, CompleteRegistration, AddToCart, ViewContent, v.v.) được gửi đúng lúc, đúng giá trị.
  • Không trùng lặp event (double fire) gây sai lệch dữ liệu và tối ưu chiến dịch.
• Cookie consent:
  • Banner hoặc popup cookie consent hoạt động, hiển thị đúng khu vực cần tuân thủ (EU, UK, v.v. nếu áp dụng).
  • Người dùng có thể lựa chọn chấp nhận hoặc từ chối các nhóm cookie (analytics, marketing, functional).
  • Script analytics/pixel chỉ chạy sau khi người dùng đồng ý, nếu chính sách yêu cầu như vậy.
• Ecommerce tracking:
  • Ghi nhận giá trị đơn hàng, sản phẩm, số lượng, thuế, phí ship (nếu cần) một cách chính xác.
  • Mapping đúng giữa ID sản phẩm trên website và ID trong hệ thống quảng cáo (Facebook Catalog, Google Merchant Center).
  • Đối chiếu định kỳ giữa doanh thu trong GA4 và doanh thu trong hệ thống bán hàng để phát hiện sai lệch.

Các thành phần này cần được tối ưu để không gây lỗi, không làm chậm website quá mức. Nên:

• Kiểm tra kích thước và số lượng script được load.
• Sử dụng GTM để quản lý tập trung, bật/tắt tag theo điều kiện (trang, loại người dùng, consent).
• Đảm bảo không có script trùng lặp (gắn pixel trực tiếp và trong GTM cùng lúc).

Việc cấu hình đúng giúp dữ liệu marketing chính xác, hỗ trợ ra quyết định kinh doanh dựa trên số liệu thực, đồng thời giảm rủi ro vi phạm quy định về bảo mật dữ liệu.

Dashboard báo cáo cần phân biệt traffic organic, referral, paid, direct và conversion SEO

Để đánh giá hiệu quả SEO sau bàn giao ở mức chiến lược, cần có dashboard báo cáo phân biệt rõ các nguồn traffic: organic, referral, paid, direct, social, email, v.v. Đồng thời, cần tách riêng conversion đến từ organic để biết SEO đang đóng góp bao nhiêu vào doanh thu hoặc lead, thay vì chỉ nhìn vào lượng traffic.




Dashboard có thể được xây dựng trong GA4, Looker Studio hoặc công cụ BI khác, nhưng tối thiểu nên thể hiện:

• Số phiên (sessions) và người dùng (users) từ organic theo thời gian.
• Các trang đích organic chính (landing pages) và hiệu suất của từng trang:
  • Sessions, users, bounce rate/engagement rate, average engagement time.
  • Conversion rate và số conversion từ organic cho từng trang.
• Các nguồn traffic khác (paid, referral, direct, social) để so sánh tương quan.
• Danh sách từ khóa hoặc truy vấn chính trong Search Console, gắn với trang đích tương ứng.

Trong biên bản bàn giao, nên yêu cầu đơn vị triển khai cung cấp ít nhất một dashboard cơ bản, có cấu trúc rõ:

• Phần tổng quan:
  • Tổng sessions organic, tổng conversion từ organic, tổng doanh thu/lead từ organic trong một khoảng thời gian.
  • Tỷ trọng organic so với các kênh khác.
• Phần chi tiết theo trang:
  • Top landing pages organic, kèm chỉ số engagement và conversion.
  • Nhận diện các trang có traffic cao nhưng conversion thấp để tối ưu.
• Phần truy vấn tìm kiếm:
  • Top truy vấn trong Search Console, impression, click, CTR, vị trí trung bình.
  • Mapping truy vấn với nhóm nội dung hoặc nhóm sản phẩm/dịch vụ.

Nên cấu hình sẵn các filter hoặc segment trong dashboard để:

• Lọc theo thiết bị (mobile/desktop), khu vực địa lý, loại trang (blog, category, product, landing page).
• Lọc theo nhóm từ khóa hoặc nhóm chủ đề nội dung.
• So sánh theo giai đoạn (tháng này so với tháng trước, cùng kỳ năm trước).

Việc có dashboard rõ ràng ngay từ giai đoạn bàn giao giúp chủ website theo dõi hiệu quả SEO ngay từ những tháng đầu, phát hiện sớm vấn đề (sụt traffic, giảm conversion, lỗi tracking) và điều chỉnh chiến lược nội dung, kỹ thuật, link building dựa trên dữ liệu thay vì cảm tính.

Kiểm tra bảo mật, quyền quản trị và tài sản bàn giao




SSL, HTTPS, backup, firewall, chống spam form và cập nhật CMS/plugin cần được cấu hình

Bảo mật không chỉ là cài SSL cho có, mà là một tập hợp các lớp bảo vệ kỹ thuật cần được kiểm tra, cấu hình và ghi nhận rõ trong biên bản nghiệm thu. Trước hết, chứng chỉ SSL phải là loại hợp lệ (Let’s Encrypt, Sectigo, DigiCert…), còn hạn, cài đúng cho toàn bộ tên miền và subdomain cần dùng (www, non-www, staging nếu có). Cần kiểm tra:

• Tất cả URL đều tự động chuyển hướng 301 từ HTTP sang HTTPS.
• Không còn mixed content (ảnh, CSS, JS tải qua HTTP) bằng cách rà soát trong DevTools > Console và dùng các công cụ quét bảo mật.
• Cấu hình giao thức và cipher an toàn (tắt SSLv3, TLS 1.0/1.1 nếu có thể, ưu tiên TLS 1.2+), hạn chế lỗ hổng như BEAST, POODLE.




Hệ thống backup cần được thiết kế theo nguyên tắc 3-2-1 (3 bản sao, 2 loại lưu trữ, 1 bản offsite). Không chỉ “có backup” mà phải mô tả rõ:

• Tần suất backup: hàng ngày, hàng tuần, backup full hay incremental.
• Phạm vi: backup mã nguồn, database, file upload, cấu hình server hay chỉ một phần.
• Vị trí lưu trữ: cùng server, server khác, dịch vụ cloud (S3, Google Cloud Storage…).
• Quy trình restore đã được test thực tế (khôi phục thành công trên môi trường staging).

Về firewall, nên cấu hình kết hợp giữa firewall ở tầng server (iptables, UFW, security group của cloud) và Web Application Firewall (WAF) như Cloudflare, Sucuri, ModSecurity. Cần cấu hình các rule tối thiểu:

• Giới hạn truy cập vào trang quản trị (chỉ IP whitelist, hoặc bắt buộc 2FA/VPN).
• Chặn các pattern tấn công phổ biến: SQL injection, XSS, brute force login.
• Giới hạn rate limit cho các endpoint nhạy cảm (login, form gửi dữ liệu).

Form liên hệ, đăng ký, bình luận phải có cơ chế chống spam đa lớp:

• reCAPTCHA v2/v3 hoặc các giải pháp tương đương.
• Honeypot field ẩn để bẫy bot tự động.
• Giới hạn số lần gửi theo IP, theo session, theo thời gian.
• Validation phía server, lọc từ khóa spam, chặn domain/email khả nghi.

CMS và plugin cần được cập nhật lên phiên bản ổn định, nhưng phải có quy trình:

• Test update trên môi trường staging trước khi áp dụng lên production.
• Loại bỏ plugin không dùng, plugin không rõ nguồn gốc hoặc không còn được nhà phát triển duy trì.
• Ghi lại lịch sử cập nhật (changelog nội bộ) để truy vết khi có lỗi.

Trong biên bản nghiệm thu nên mô tả chi tiết:

• Giải pháp backup đang dùng, lịch backup, thời gian lưu trữ (retention), vị trí lưu.
• Giải pháp firewall/WAF, các rule chính, cách truy cập dashboard quản lý.
• Cơ chế chống spam đang áp dụng cho từng loại form.
• Chính sách cập nhật CMS/plugin: tần suất, quy trình test, người chịu trách nhiệm.

Tài khoản hosting, domain, DNS, CDN, CMS, email, database và repository code cần bàn giao rõ quyền

Một website hoàn chỉnh là tập hợp nhiều tài sản kỹ thuật liên kết với nhau. Nếu không bàn giao đầy đủ, doanh nghiệp rất dễ bị “khóa” bởi nhà cung cấp hoặc gặp rủi ro khi cần chuyển đổi. Cần đảm bảo:

• Tài khoản hosting (cPanel, Plesk, panel riêng, tài khoản cloud như AWS, GCP, Azure) được đăng ký bằng email chính thức của doanh nghiệp.
• Tài khoản quản lý domain tại nhà đăng ký (registrar) cũng thuộc quyền kiểm soát của doanh nghiệp, có khả năng chuyển registrar khi cần.
• Hệ thống DNS (Cloudflare, Route 53, DNS của nhà đăng ký…) được bàn giao tài khoản quản trị, kèm danh sách bản ghi hiện tại.
• Tài khoản CDN (Cloudflare, Akamai, Fastly…) có quyền cấu hình cache, SSL, rule bảo mật.
• Tài khoản admin CMS (WordPress, Drupal, Magento, custom CMS…) với quyền cao nhất, kèm hướng dẫn tạo user mới và phân quyền.
• Thông tin kết nối database (host, port, tên DB, user, quyền) và cách thay đổi mật khẩu an toàn.
• Repository code trên GitHub, GitLab, Bitbucket hoặc nền tảng khác, với quyền owner thuộc về doanh nghiệp.

Trong biên bản bàn giao cần liệt kê chi tiết, có cấu trúc:

• Nhà cung cấp hosting, loại gói, thông tin đăng nhập panel, SSH/SFTP, quyền truy cập.
• Nhà đăng ký domain, tài khoản quản lý, ngày hết hạn domain, trạng thái khóa chuyển (transfer lock).
• Hệ thống DNS đang dùng, tài khoản quản trị, bản export cấu hình DNS hiện tại.
• Tài khoản CDN, các zone đang cấu hình, rule cache/bảo mật quan trọng.
• Tài khoản admin CMS, số lượng admin, phân quyền theo vai trò.
• Thông tin database: user, quyền (read/write), cơ chế backup riêng cho DB nếu có.
• Repository code: URL repo, nhánh chính (main/master), quy ước đặt tên branch, quy trình deploy (CI/CD nếu có).

Mỗi tài khoản quan trọng nên được gắn với email dạng kỹ thuật của doanh nghiệp (ví dụ: it@tencongty.com, devops@tencongty.com), tránh dùng email cá nhân của nhân viên hoặc agency để giảm rủi ro khi nhân sự thay đổi.

Mật khẩu mặc định, tài khoản nhà phát triển và quyền admin dư thừa cần được loại bỏ

Sau triển khai, nhiều hệ thống vẫn giữ mật khẩu mặc định (admin/admin, root/123456…) hoặc tài khoản nhà phát triển với quyền admin, đây là lỗ hổng cực kỳ nguy hiểm. Trước khi nghiệm thu cần thực hiện kiểm tra bảo mật tài khoản:

• Rà soát toàn bộ tài khoản admin trên CMS, hosting, database, repository, panel DNS/CDN.
• Đổi toàn bộ mật khẩu mặc định sang mật khẩu mạnh (độ dài lớn, ký tự đặc biệt, không trùng lặp).
• Xóa hoặc hạ quyền các tài khoản nhà phát triển, tài khoản test, tài khoản tạm thời.
• Đảm bảo chỉ giữ lại số lượng tài khoản admin tối thiểu cần thiết cho vận hành.




Chủ website nên yêu cầu một báo cáo liệt kê:

• Danh sách tài khoản admin hiện có trên từng hệ thống (CMS, hosting, DB, Git, DNS, CDN).
• Vai trò, quyền hạn của từng tài khoản.
• Tài khoản nào thuộc về doanh nghiệp, tài khoản nào thuộc về agency (để cân nhắc hạ quyền hoặc xóa).

Sau đó, thiết lập quy trình quản lý mật khẩu an toàn:

• Sử dụng trình quản lý mật khẩu (password manager) để lưu trữ và chia sẻ an toàn.
• Bật xác thực hai yếu tố (2FA) cho các tài khoản quan trọng: email, hosting, domain, Git, CMS.
• Áp dụng phân quyền theo vai trò (role-based access control): editor, author, admin, developer.
• Định kỳ (ví dụ 3–6 tháng) rà soát lại danh sách tài khoản, thu hồi quyền của nhân sự đã nghỉ.

Việc giảm tối đa quyền admin dư thừa không chỉ giúp hạn chế tấn công từ bên ngoài mà còn giảm rủi ro rò rỉ dữ liệu hoặc thao tác nhầm từ bên trong.

Tài liệu hướng dẫn quản trị nội dung, backup, restore và cập nhật website cần được cung cấp

Một phần quan trọng của bàn giao là tài liệu hướng dẫn vận hành, giúp đội ngũ nội bộ chủ động quản trị mà không phải phụ thuộc hoàn toàn vào đơn vị triển khai. Tài liệu nên bao gồm tối thiểu các nội dung:

• Cách đăng bài, chỉnh sửa nội dung, upload ảnh, tối ưu ảnh cho SEO (kích thước, dung lượng, alt text).
• Cách tạo category, tag, quản lý menu, chỉnh sửa widget/block.
• Quy trình backup thủ công và tự động, cách kiểm tra backup có hoạt động hay không.
• Quy trình restore trên môi trường staging và trên production (ai được phép thực hiện, bước rollback nếu lỗi).
• Cách cập nhật CMS/plugin an toàn: chuẩn bị backup, test trên staging, kiểm tra lại chức năng sau update.
• Hướng dẫn xử lý một số lỗi cơ bản: lỗi hiển thị, lỗi cache, lỗi plugin xung đột, lỗi quyền file.




Trong biên bản bàn giao nên yêu cầu:

• File hướng dẫn dạng PDF, video hoặc wiki nội bộ, có cấu trúc rõ ràng, dễ tra cứu.
• Ảnh minh họa từng bước thao tác quan trọng, đánh dấu những thao tác “nguy hiểm” cần thận trọng.
• Ít nhất một buổi training (online hoặc offline) cho đội ngũ liên quan: marketing, content, IT nội bộ.

Tài liệu càng chi tiết, doanh nghiệp càng chủ động trong việc phát triển nội dung SEO, triển khai chiến dịch marketing và xử lý các sự cố nhỏ mà không phải chờ đợi đơn vị triển khai.

Hợp đồng cần ghi rõ bảo hành lỗi kỹ thuật, phạm vi hỗ trợ và thời gian phản hồi sau bàn giao

Khía cạnh pháp lý và cam kết dịch vụ là lớp bảo vệ cuối cùng cho website sau khi bàn giao. Trong hợp đồng cần quy định rõ thời gian bảo hành lỗi kỹ thuật (3–6–12 tháng hoặc theo thỏa thuận), kèm theo:

• Phạm vi lỗi được bảo hành: lỗi code, lỗi hiển thị trên trình duyệt phổ biến, lỗi bảo mật cơ bản, lỗi cấu hình server liên quan trực tiếp đến website.
• Những hạng mục không thuộc phạm vi bảo hành: thay đổi tính năng lớn, yêu cầu phát triển mới, lỗi do bên thứ ba (plugin, dịch vụ ngoài) sau khi cập nhật ngoài thỏa thuận.
• Thời gian phản hồi (SLA): ví dụ trong vòng 4 giờ làm việc đối với lỗi nghiêm trọng, 24 giờ đối với lỗi thường.
• Thời gian xử lý dự kiến cho từng mức độ lỗi (critical, high, medium, low).




Đồng thời, cần làm rõ phạm vi hỗ trợ liên quan đến SEO:

• Sửa lỗi kỹ thuật phát sinh ảnh hưởng đến index, crawl, tốc độ tải trang.
• Hỗ trợ cấu hình lại tracking (Google Analytics, Google Tag Manager, pixel quảng cáo) khi có thay đổi nhỏ.
• Hỗ trợ tối ưu nhỏ: chỉnh lại thẻ meta, sitemap, robots.txt, canonical, schema markup cơ bản.

Chủ website cần lưu trữ:

• Hợp đồng, phụ lục kỹ thuật, biên bản nghiệm thu.
• Tài liệu kỹ thuật, tài liệu hướng dẫn vận hành, thông tin liên hệ hỗ trợ (email, hotline, kênh ticket).
• Lịch sử thay đổi lớn (major changes) trên website để đối chiếu khi có sự cố SEO.

Khi có lỗi SEO hoặc lỗi kỹ thuật phát sinh sau bàn giao, việc có đầy đủ tài liệu và điều khoản rõ ràng giúp xác định nhanh trách nhiệm, rút ngắn thời gian xử lý và hạn chế tối đa gián đoạn hoạt động kinh doanh.

FAQ về checklist bàn giao website chuẩn SEO




Có nên nhận bàn giao khi website chưa index được trên Google không?

Quyết định có nghiệm thu website khi chưa index được trên Google hay không cần dựa trên phân tích nguyên nhân cụ thể, không chỉ nhìn vào trạng thái “chưa có traffic” hay “chưa thấy trên Google”. Về mặt kỹ thuật, có thể chia thành hai nhóm nguyên nhân chính:

• Nguyên nhân tự nhiên:
  • Website mới hoàn toàn, domain chưa có lịch sử, Google chưa crawl tới.
  • Số lượng backlink gần như bằng 0, không có tín hiệu để bot ưu tiên.
  • Sitemap mới gửi, cần thời gian để Google xử lý và lập chỉ mục.
• Nguyên nhân do lỗi kỹ thuật / cấu hình sai:
  • File robots.txt chặn toàn bộ hoặc chặn nhầm thư mục quan trọng (ví dụ: Disallow: /).
  • Thẻ <meta name="robots" content="noindex, nofollow"> hoặc header X-Robots-Tag: noindex được áp dụng cho toàn site.
  • Lỗi HTTP (5xx, 4xx) lặp lại, khiến Google không thể crawl ổn định.
  • Canonical trỏ sai, khiến Google coi các URL quan trọng là bản trùng lặp và không index.

Trước khi nghiệm thu, cần thao tác chi tiết trong Google Search Console:

• Kiểm tra phần Ownership: domain đã được xác minh bằng phương thức domain (DNS) hay chỉ ở mức URL prefix. Nên ưu tiên xác minh dạng domain để bao phủ toàn bộ subdomain và giao thức.
• Kiểm tra mục Sitemaps: sitemap đã được gửi, trạng thái “Success”, số URL đã phát hiện (Discovered URLs) có tương quan với số trang thực tế.
• Dùng URL Inspection cho:
  • Trang chủ.
  • 1–2 trang danh mục chính.
  • 1–2 trang bài viết / sản phẩm tiêu biểu.

Nếu URL Inspection trả về các trạng thái như “URL is on Google”, “URL is indexed” hoặc “URL is on Google, but has issues” với một số trang mẫu, đồng thời không có lỗi hệ thống nghiêm trọng (robots, noindex toàn site, lỗi 5xx), có thể chấp nhận nghiệm thu với điều kiện:

• Ghi rõ trong biên bản nghiệm thu mốc thời gian kiểm tra lại (ví dụ 2–4 tuần).
• Đơn vị triển khai cam kết hỗ trợ xử lý nếu phát sinh lỗi index do cấu hình hệ thống, không phải do nội dung hoặc chiến lược SEO về sau.

Nếu phát hiện các lỗi như chặn toàn bộ bằng robots, noindex nhầm toàn site, canonical sai hệ thống, hoặc server trả về lỗi 5xx thường xuyên, không nên nghiệm thu cho đến khi các lỗi này được khắc phục và xác nhận lại bằng crawl nội bộ + Search Console.

Cần kiểm tra những công cụ SEO nào trước khi nghiệm thu website?

Trước khi nghiệm thu, cần đảm bảo các công cụ SEO cốt lõi đã được thiết lập đúng, dữ liệu bắt đầu ghi nhận và quyền truy cập thuộc về chủ website. Các công cụ quan trọng gồm:

• Google Search Console:
  • Đã thêm property dạng domain và xác minh thành công.
  • Đã gửi sitemap XML chính, không gửi các sitemap test hoặc chứa URL staging.
  • Kiểm tra mục Pages (hoặc tương đương): số trang “Indexed”, “Not indexed”, các lý do không index (Crawled – currently not indexed, Discovered – currently not indexed, Duplicate without user-selected canonical, v.v.).
  • Kiểm tra mục Page indexing và Experience để phát hiện sớm lỗi kỹ thuật.
• Google Analytics 4 (GA4):
  • Đã tạo property GA4 riêng cho website, không dùng chung với dự án khác.
  • Đã gắn Measurement ID đúng trên toàn bộ template (header hoặc qua GTM).
  • Kiểm tra trong Realtime: có session khi truy cập test, đảm bảo tracking hoạt động.
  • Các sự kiện cơ bản (pageview, scroll, clickoutbound, formsubmit hoặc conversion chính) đã được cấu hình và ghi nhận.
• Google Tag Manager (GTM):
  • Đã tạo container riêng cho website, chủ website có quyền Admin.
  • Đoạn code GTM được gắn đúng vị trí (thẻ <head> và <body> nếu cần).
  • Các tag quan trọng (GA4, pixel quảng cáo, event tracking) đã được publish, không để ở trạng thái draft.
  • Sử dụng chế độ Preview để kiểm tra tag bắn đúng điều kiện trigger.
• Công cụ crawl (Screaming Frog, Sitebulb hoặc tương đương):
  • Chạy crawl toàn bộ website để kiểm tra status code, depth, internal link, canonical, meta robots.
  • Xuất báo cáo lỗi 4xx, 5xx, redirect chain, orphan pages (nếu công cụ hỗ trợ).
  • Đối chiếu số URL indexable với sitemap XML để phát hiện chênh lệch.
• PageSpeed Insights / Lighthouse:
  • Đo Core Web Vitals cho các template chính: trang chủ, danh mục, chi tiết bài viết/sản phẩm, landing page.
  • Ghi nhận điểm hiệu năng, các cảnh báo về LCP, INP, CLS, kích thước ảnh, JS/CSS không cần thiết.

Tất cả các công cụ trên cần được bàn giao quyền truy cập với vai trò quản trị đầy đủ cho chủ website, ưu tiên sử dụng email thuộc tên miền doanh nghiệp để đảm bảo tính sở hữu lâu dài.

Website mới có cần sitemap XML và robots.txt ngay khi bàn giao không?

Ngay cả với website mới, số lượng trang chưa nhiều, sitemap XML và robots.txt vẫn là hai thành phần bắt buộc trong bàn giao chuẩn SEO, vì chúng ảnh hưởng trực tiếp đến tốc độ và chất lượng index.

Yêu cầu chi tiết với sitemap XML:

• Chỉ chứa các URL:
  • Trả về mã 200.
  • Có thể index (không noindex, không canonical sang URL khác).
  • Đúng phiên bản canonical (https, không có tham số thừa, không trùng lặp trailing slash).
• Nếu website lớn, có thể chia sitemap theo nhóm (ví dụ: sitemap-posts.xml, sitemap-products.xml, sitemap-pages.xml), nhưng vẫn cần một sitemapindex.xml tổng.
• Sitemap được cập nhật tự động khi có trang mới, không phải chỉnh tay mỗi lần.

Yêu cầu chi tiết với robots.txt:

• Không chặn nhầm thư mục chứa nội dung chính (ví dụ: /blog/, /product/).
• Có thể chặn:
  • Trang admin, trang hệ thống, trang tìm kiếm nội bộ.
  • Các tham số filter, sort nếu đã xử lý bằng canonical hoặc noindex.
• Nên khai báo đường dẫn sitemap, ví dụ:
  • Sitemap: https://www.example.com/sitemap_index.xml

Trong biên bản nghiệm thu, cần ghi rõ:

• Đường dẫn sitemap chính và các sitemap con (nếu có).
• Đường dẫn file robots.txt và các rule quan trọng đã được kiểm tra.
• Trạng thái gửi sitemap trong Search Console (đã gửi, không lỗi parsing).

Làm sao biết canonical, redirect và noindex đã cấu hình đúng?

Canonical, redirect và noindex là ba cơ chế cốt lõi để kiểm soát index và xử lý trùng lặp nội dung. Sai sót ở đây có thể khiến website mất index hàng loạt hoặc phân tán tín hiệu SEO. Quy trình kiểm tra nên gồm các bước:

• Dùng công cụ crawl:
  • Xuất danh sách toàn bộ URL với các cột:
    • Status code (200, 301, 302, 404, 5xx).
    • Canonical URL (từ thẻ <link rel="canonical">).
    • Meta robots (index/noindex, follow/nofollow).
    • X-Robots-Tag (nếu có).
  • Lọc các trường hợp:
    • URL 200 nhưng canonical trỏ sang URL khác không cùng intent.
    • URL 200 nhưng meta robots = noindex trong khi đó là trang quan trọng.
    • Redirect chain (301 → 301 → 200) hoặc redirect loop.
• Kiểm tra thủ công một số URL mẫu:
  • Trang chủ, trang danh mục, trang chi tiết, trang có tham số.
  • Xem source để xác nhận:
    • Thẻ canonical tồn tại duy nhất, không bị trùng hoặc mâu thuẫn.
    • Meta robots được set đúng (index cho trang cần SEO, noindex cho trang hệ thống).
  • Dùng công cụ kiểm tra header để xem:
    • Status code thực tế (tránh bị 302 tạm thời không cần thiết).
    • Header X-Robots-Tag có chặn index không.
• Dùng URL Inspection trong Search Console:
  • Kiểm tra mục “User-declared canonical” và “Google-selected canonical”:
    • Nếu Google chọn canonical khác với canonical khai báo, cần xem lại cấu trúc internal link, sitemap, nội dung trùng lặp.
  • Kiểm tra lý do không index nếu URL chưa được lập chỉ mục.

Cấu hình được coi là hợp lý khi:

• Các trang chuẩn (version chính) dùng self-canonical, không trỏ chéo không cần thiết.
• Các URL phụ, URL có tham số, URL trùng lặp được:
  • Redirect 301 về URL chuẩn, hoặc
  • Giữ lại nhưng canonical về URL chuẩn và/hoặc noindex nếu không cần xuất hiện trong kết quả tìm kiếm.
• Không có redirect loop, không có chuỗi redirect dài (nên tối đa 1 bước 301).
• Không có trang quan trọng bị noindex hoặc canonical nhầm sang trang khác.

Có cần audit Core Web Vitals trước khi nhận website không?

Audit Core Web Vitals trước nghiệm thu là bước quan trọng để đảm bảo website không chỉ “đúng SEO” về mặt cấu trúc mà còn đáp ứng tiêu chuẩn trải nghiệm người dùng. Các chỉ số chính cần xem:

• LCP (Largest Contentful Paint): thời gian tải phần nội dung lớn nhất trong viewport.
• INP (Interaction to Next Paint): đo độ phản hồi khi người dùng tương tác.
• CLS (Cumulative Layout Shift): mức độ dịch chuyển layout ngoài ý muốn.

Quy trình audit nên bao gồm:

• Dùng PageSpeed Insights:
  • Kiểm tra cho mobile và desktop riêng biệt.
  • Nếu có dữ liệu thực (field data) từ Chrome UX Report, ưu tiên đánh giá theo đó.
  • Ghi nhận các đề xuất tối ưu: nén ảnh, lazy-load, giảm JS không dùng, tối ưu CSS, preload font, v.v.
• Dùng Lighthouse (trong Chrome DevTools hoặc CLI):
  • Chạy audit cho từng template chính.
  • Kiểm tra thêm các mục Accessibility, Best Practices, SEO để phát hiện lỗi liên quan đến UX và kỹ thuật.

Trong biên bản nghiệm thu, nên ghi nhận:

• Giá trị LCP, INP, CLS hiện tại cho mobile và desktop (nếu có field data thì ghi rõ nguồn).
• Các vấn đề lớn ảnh hưởng đến Core Web Vitals (ví dụ: ảnh hero quá nặng, script bên thứ ba chặn render, layout nhảy do thiếu kích thước ảnh).
• Danh sách hạng mục tối ưu tiếp theo, phân loại:
  • Bắt buộc xử lý trước nghiệm thu (ví dụ: LCP > 6s, CLS rất cao).
  • Có thể lên kế hoạch tối ưu sau (fine-tuning hiệu năng).

Bàn giao website có cần quyền Google Search Console và GA4 không?

Trong bàn giao website chuẩn SEO, việc chuyển giao quyền sở hữu và quản trị Google Search Console và GA4 là bắt buộc, vì đây là tài sản dữ liệu cốt lõi của doanh nghiệp. Nếu chủ website không có quyền Owner/Admin:

• Không thể thêm hoặc xóa người dùng khi thay đổi nhà cung cấp dịch vụ.
• Không thể cấu hình thêm property, view, event, conversion mới.
• Có nguy cơ mất quyền truy cập dữ liệu nếu email cá nhân của đơn vị triển khai bị khóa hoặc rời dự án.

Yêu cầu cụ thể khi bàn giao:

• Google Search Console:
  • Chủ website (email doanh nghiệp) phải là Owner (tốt nhất là Verified owner).
  • Đơn vị triển khai có thể giữ quyền Full user hoặc Restricted user nếu còn tiếp tục hỗ trợ.
  • Ghi rõ trong biên bản: email, vai trò, loại property (domain hoặc URL prefix).
• GA4:
  • Chủ website phải có quyền Admin ở cấp property.
  • Các tài khoản agency nên được phân quyền theo nhu cầu (Editor, Analyst, v.v.).
  • Đảm bảo tài khoản GA4 được liên kết đúng với các nền tảng khác nếu cần (Google Ads, BigQuery, v.v.).

Khuyến nghị sử dụng email dạng analytics@tencongty.com hoặc marketing@tencongty.com làm tài khoản quản trị chính, tránh phụ thuộc vào email cá nhân của bất kỳ cá nhân hoặc agency nào.

Website redesign cần kiểm tra redirect từ URL cũ sang URL mới thế nào?

Với dự án redesign hoặc thay đổi cấu trúc URL, kiểm tra redirect là bước then chốt để bảo toàn thứ hạng và traffic organic. Quy trình chi tiết:

• Lập danh sách URL cũ:
  • Xuất từ sitemap cũ (nếu còn truy cập được).
  • Lấy từ log server (các URL có truy cập trong 3–6 tháng gần nhất).
  • Lấy từ Search Console (Coverage, Top pages trong Search results).
  • Lấy từ công cụ analytics (GA4 hoặc Universal Analytics cũ nếu còn dữ liệu).
• Tạo bảng mapping URL cũ – URL mới:
  • Mỗi URL cũ phải có:
    • URL mới tương ứng với intent gần nhất (nội dung, chủ đề, mục đích tìm kiếm).
    • Trường hợp không còn nội dung tương đương, có thể redirect về danh mục cấp trên hợp lý.
  • Tránh redirect tất cả về trang chủ, vì dễ gây mất tín hiệu và trải nghiệm kém.
• Kiểm tra triển khai redirect:
  • Dùng công cụ crawl để crawl toàn bộ danh sách URL cũ.
  • Kiểm tra:
    • Tất cả URL cũ trả về 301 (không phải 302) đến đúng URL mới.
    • Không có 404 không mong muốn.
    • Không có redirect loop hoặc redirect chain dài (nhiều hơn 1 bước).

Sau khi go-live, cần:

• Theo dõi Search Console để phát hiện lỗi 404 mới, URL không index, hoặc giảm mạnh impression/click ở các trang quan trọng.
• Theo dõi traffic organic theo landing page trong GA4 để đánh giá mức độ giữ được hiệu suất SEO.

Các bước này nên hoàn thành và được xác nhận bằng báo cáo crawl + dữ liệu Search Console trước khi nghiệm thu, vì sửa redirect muộn có thể làm mất thêm tín hiệu SEO đã tích lũy.

Ai chịu trách nhiệm sửa lỗi SEO phát hiện sau khi bàn giao?

Trách nhiệm sửa lỗi SEO sau bàn giao phụ thuộc vào hợp đồng và biên bản nghiệm thu, nhưng có thể phân loại theo nguyên tắc:

• Lỗi kỹ thuật thuộc phạm vi triển khai ban đầu:
  • Lỗi code, cấu hình server, CMS, template, tracking.
  • Lỗi canonical, redirect, robots, sitemap do thiết kế hệ thống sai.
  • Thường thuộc phạm vi bảo hành, đơn vị triển khai phải sửa trong thời gian cam kết.
• Lỗi phát sinh do thay đổi sau bàn giao:
  • Chủ website hoặc bên thứ ba chỉnh sửa nội dung, cấu trúc URL, thêm plugin, thay đổi theme.
  • Thêm script bên thứ ba gây chậm site, chèn noindex, thay đổi robots.txt.
  • Thường được coi là yêu cầu mới, không nằm trong bảo hành.
• Hạng mục tối ưu SEO nâng cao:
  • Tối ưu nội dung chuyên sâu, xây dựng cấu trúc topic cluster, schema nâng cao.
  • Chiến lược internal link, A/B testing UX, tối ưu Core Web Vitals ở mức cao.
  • Thường thuộc phạm vi dịch vụ SEO riêng, không phải lỗi cần bảo hành.

Trong biên bản nghiệm thu, nên:

• Liệt kê các lỗi SEO đã phát hiện tại thời điểm nghiệm thu:
  • Lỗi nào được yêu cầu sửa trước khi nghiệm thu.
  • Lỗi nào chấp nhận nghiệm thu nhưng kèm cam kết sửa trong thời gian bảo hành.
• Ghi rõ phạm vi bảo hành: loại lỗi, thời gian, quy trình tiếp nhận và xử lý.
• Khuyến nghị chủ website duy trì checklist SEO định kỳ (crawl, kiểm tra Search Console, kiểm tra tốc độ) để phát hiện sớm vấn đề trong thời gian bảo hành.