Khi một SEOer đặt thẻ canonical, thêm thuộc tính rel="nofollow", hay khai báo hreflang cho trang đa ngôn ngữ, họ đang sử dụng một hệ thống ngữ nghĩa có nền tảng chuẩn hóa rất cụ thể. Chuẩn đó có tên là RFC 8288, được phát hành bởi IETF (Internet Engineering Task Force) vào tháng 10 năm 2017, thay thế cho RFC 5988 trước đó.
RFC 8288 không phải là tài liệu dành cho người làm content. Nó là đặc tả kỹ thuật định nghĩa cách các tài nguyên trên web liên kết với nhau theo nghĩa máy hiểu được, không chỉ theo nghĩa “người dùng bấm vào”. Và đây chính là chỗ mà phần lớn khóa học SEO ở Việt Nam không chạm tới.
RFC 8288 Định Nghĩa Gì? Đọc Thẳng Từ Spec #
RFC 8288 định nghĩa một Web Link là một quan hệ có kiểu giữa hai tài nguyên, được gọi là “link context” (tài nguyên nguồn) và “link target” (tài nguyên đích), trong đó quan hệ đó được mô tả bởi link relation type (kiểu quan hệ liên kết).
Cú pháp đơn giản nhất:
Link: <https://example.com/page>; rel="canonical"
Trong đó:
<https://example.com/page>là link target (tài nguyên đích)rel="canonical"là link relation type (kiểu quan hệ)- Tài nguyên hiện tại đang phục vụ header này là link context (tài nguyên nguồn)
Có ba thành phần cốt lõi RFC 8288 quy định rõ:
1. Link Context: tài nguyên đang khai báo liên kết. Có thể là một trang web, một endpoint API, hay bất kỳ tài nguyên nào có URI. Mặc định là URI của tài nguyên đang gửi tín hiệu.
2. Link Target: tài nguyên mà liên kết trỏ tới. Phải là một URI hợp lệ.
3. Link Relation Type: đây là phần quan trọng nhất. Nó không phải là nhãn tùy tiện, mà phải là một trong hai loại: (a) một registered relation type đã được IANA đăng ký (ví dụ: canonical, alternate, next, prev, stylesheet, author), hoặc (b) một extension relation type dạng URI tuyệt đối để tránh xung đột namespace.
Ngoài ba thành phần chính, RFC 8288 còn quy định một tập link attributes có thể đính kèm vào một Web Link:
hreflang: ngôn ngữ của tài nguyên đíchmedia: loại media mà tài nguyên đích phục vụtitlevàtitle*: tên gợi ý cho tài nguyên đíchtype: MIME type của tài nguyên đích
Hai Tầng Khai Báo Link: HTTP Header và HTML #
Đây là điểm mà hầu hết SEOer không được học trong bất kỳ khóa học nào ở Việt Nam.
RFC 8288 quy định rằng một Web Link có thể được khai báo theo hai cách hoàn toàn tương đương về mặt ngữ nghĩa:
Tầng HTTP Header #
HTTP/1.1 200 OK
Link: </alternate-version>; rel="alternate"; hreflang="en"
Link: </canonical-url>; rel="canonical"
Link: </style.css>; rel="stylesheet"; type="text/css"
Header Link được xử lý bởi máy chủ trước khi HTML được đọc. Crawler của Google và Bing đều hỗ trợ đọc tín hiệu canonical từ HTTP header. Điều này có nghĩa là bạn có thể khai báo rel="canonical" hay hreflang mà hoàn toàn không cần chạm vào HTML của trang.
Tầng HTML #
<link rel="canonical" href="https://example.com/canonical-url">
<link rel="alternate" hreflang="en" href="/alternate-version">
Cả hai tầng đều là cú pháp hợp lệ theo RFC 8288 và HTML Living Standard. Sự khác biệt là ở tốc độ xử lý và độ ưu tiên: HTTP header được đọc trước, không phụ thuộc vào việc trình phân tích cú pháp HTML có hoàn thành hay không.
Tại sao điều này quan trọng với SEO? Vì một số CMS và theme can thiệp vào phần <head> của HTML theo cách không thể kiểm soát hoàn toàn. Trong trường hợp đó, khai báo canonical qua HTTP header là lựa chọn sạch hơn, đáng tin cậy hơn, và xử lý được hàng loạt URL mà không cần sửa từng template.
Nếu bạn muốn hiểu sâu hơn relation canonical được dùng thế nào trong SEO thực chiến, hãy đọc thêm RFC 6596 về canonical. Bài này giúp bạn phân biệt phạm vi dùng đúng của canonical, các lỗi triển khai dễ làm Google chọn sai URL chuẩn, và khi nào nên chuyển sang redirect thay vì tiếp tục giữ nhiều URL gần trùng.
Danh Sách Relation Types Đã Đăng Ký Với IANA và Ứng Dụng SEO #
RFC 8288 yêu cầu rằng mọi rel value dạng chuỗi đơn (không phải URI tuyệt đối) phải được đăng ký với IANA tại registry Link Relations. Dưới đây là các relation type trực tiếp ảnh hưởng đến quyết định của công cụ tìm kiếm:
canonical — Khai báo rằng tài nguyên đích là phiên bản “ưa thích” của một tập nội dung. Google đọc tín hiệu này như một “gợi ý mạnh” (strong hint), không phải là lệnh tuyệt đối. Trong Google Search Central, Google xác nhận họ có thể bỏ qua canonical nếu có tín hiệu mâu thuẫn (ví dụ: trang được canonical trỏ đến nhưng không được link nội bộ hay bị chặn bởi robots.txt).
alternate — Khai báo một phiên bản thay thế của tài nguyên hiện tại. Kết hợp với attribute hreflang để tín hiệu hóa phiên bản ngôn ngữ/quốc gia trong hệ thống đa ngôn ngữ. Kết hợp với attribute media để tín hiệu hóa phiên bản dành cho thiết bị khác nhau (tuy nhiên cách tiếp cận này đã lỗi thời so với responsive design).
nofollow — Theo RFC 8288, đây không phải là một registered relation type. nofollow thực ra là một HTML microformat extension, được Google giới thiệu năm 2005. Không có trong IANA registry. Điều này có nghĩa là nofollow không phải là một tín hiệu ngữ nghĩa theo chuẩn RFC 8288, mà là một convention được Google tự định nghĩa và xử lý theo cách riêng.
next và prev — Dùng để khai báo quan hệ phân trang. Google đã chính thức ngừng sử dụng rel="prev/next" từ năm 2019 cho mục đích tổng hợp nội dung phân trang, tuy nhiên các relation type này vẫn hợp lệ theo RFC 8288 và hữu ích cho browser prefetch.
author — Khai báo tác giả của tài nguyên. Có liên quan trực tiếp đến tín hiệu E-E-A-T khi Google cố gắng xác minh danh tính người tạo nội dung.
stylesheet — Không liên quan đến SEO ranking trực tiếp, nhưng là ví dụ quan trọng để hiểu rằng RFC 8288 không chỉ phục vụ SEO, mà phục vụ toàn bộ kiến trúc web.
rel Không Phải Lệnh Tuyệt Đối: Hiểu Đúng Để Làm Đúng #
Đây là hiểu lầm phổ biến nhất trong cộng đồng SEO Việt Nam.
RFC 8288 trong phần 2.1 ghi rõ: “The meaning of a link is established by its link relation type.” Nói cách khác, rel chỉ khai báo một ngữ nghĩa được đề xuất. Máy đọc link (bất kể là browser, crawler, hay AI agent) không bị bắt buộc tuân theo.
Trong bối cảnh SEO, Google Search Central đã nhiều lần khẳng định:
rel="canonical"là “gợi ý” (hint), không phải “chỉ thị” (directive). Google có thể chọn URL khác làm canonical nếu thấy tín hiệu tổng thể mạnh hơn từ internal link, sitemap, hay hành vi traffic.rel="nofollow"từ năm 2019 đã được Google nâng lên thành “gợi ý” thay vì “lệnh cứng”, cho phép Google tùy ngữ cảnh quyết định có crawl/index URL đích hay không.hreflangđược xem là tín hiệu để xác định phục vụ đúng phiên bản cho đúng người dùng, nhưng Google vẫn có thể hiển thị phiên bản khác nếu hệ thống hreflang có lỗi mâu thuẫn.
Hệ quả thực tiễn: một SEOer hiểu RFC 8288 sẽ không còn tin rằng “gắn canonical là xong” hay “nofollow là máy không đọc”. Họ hiểu rằng tín hiệu kỹ thuật là một phần của hệ thống tín hiệu tổng thể, và độ tin cậy của tín hiệu phụ thuộc vào sự nhất quán giữa các tầng: HTTP header, HTML, sitemap, internal link, và hành vi thực tế.
RFC 8288 và Kiến Trúc Internal Link: Từ Cú Pháp Đến Tư Duy #
Phần này là nơi RFC 8288 trở nên thực sự hữu ích nếu bạn không chỉ học nó như một spec kỹ thuật, mà hiểu tư duy đằng sau nó.
RFC 8288 không nói rằng một link chỉ là “một URL để đi từ A đến B”. Nó nói rằng một link là sự diễn đạt của một quan hệ có kiểu giữa hai tài nguyên. Quan hệ đó có hướng (có nguồn và đích), có kiểu (rel), và có thể có các thuộc tính bổ sung (hreflang, type, media).
Khi bạn thiết kế hệ thống internal link theo tư duy này, câu hỏi không còn là “trang này nên link đến bao nhiêu trang?” mà là:
Trang này đang có quan hệ gì với trang kia?
Một trang dịch vụ ở tầng cân nhắc (Consideration) không nên link bừa đến một trang blog Awareness bằng anchor text chung chung. Quan hệ giữa hai trang đó phải được phản ánh đúng trong anchor text, đúng trong vị trí link trên trang, và đúng trong logic dẫn dắt người dùng tiếp theo.
Đây cũng chính là nền tảng kỹ thuật cho cách VLINK ASIA xây dựng hệ thống internal link trong Website Growth System™: mỗi link là một tín hiệu quan hệ, không phải một hành động kỹ thuật đơn thuần.
Ứng Dụng RFC 8288 Qua HTTP Header Trong Thực Chiến SEO #
Dưới đây là các trường hợp thực tế mà khai báo link qua HTTP header hiệu quả hơn tầng HTML:
1. Canonical cho nội dung không phải HTML #
PDF, tài liệu Word, CSV, hay các endpoint JSON API không có <head> để đặt thẻ <link>. Nhưng chúng vẫn có thể khai báo canonical qua HTTP header:
HTTP/1.1 200 OK
Content-Type: application/pdf
Link: <https://example.com/document>; rel="canonical"
Điều này quan trọng với các trang có hệ thống tài liệu lớn (pháp lý, tài chính, y tế) muốn kiểm soát trang nào được index.
2. Hreflang cho hệ thống đa ngôn ngữ quy mô lớn #
Với website có hàng ngàn URL đa ngôn ngữ, việc render hreflang trong HTML của từng trang tạo ra tải trọng lớn cho server-side rendering. Một số hệ thống giải quyết bằng cách inject hreflang header tại edge layer (Cloudflare Workers, Nginx) dựa trên URL pattern, thay vì xử lý trong CMS.
Ví dụ cấu hình Nginx:
location ~* ^/vi/ {
add_header Link '</en/>; rel="alternate"; hreflang="en"';
add_header Link '</vi/>; rel="alternate"; hreflang="vi"';
}
3. Pagefind và JavaScript-heavy sites #
Với các trang Single Page Application (SPA) nơi HTML ban đầu không chứa nội dung đầy đủ, việc đặt canonical và hreflang trong HTTP header đảm bảo Googlebot đọc được tín hiệu này ngay từ lần fetch đầu tiên, trước khi JavaScript được thực thi.
4. Kiểm tra nhanh bằng curl #
Để xem HTTP Link header của bất kỳ URL nào:
curl -I https://example.com/page
Tìm dòng bắt đầu bằng Link: trong response. Đây là cách nhanh nhất để audit xem một trang có khai báo canonical qua HTTP header hay không, đặc biệt hữu ích khi debug hệ thống CDN hay reverse proxy.
RFC 8288 Trong Hệ Sinh Thái Tiêu Chuẩn Web Rộng Hơn #
RFC 8288 không đứng một mình. Nó là một mắt xích trong hệ thống tiêu chuẩn liên quan:
HTML Living Standard (WHATWG) — Định nghĩa <link> element và rel attribute trong HTML, tham chiếu đến RFC 8288 cho phần semantics của link relation types.
HTTP/1.1 và HTTP/2 (RFC 7230 series, RFC 9110) — Quy định cú pháp của HTTP header, trong đó Link header là một HTTP extension header hợp lệ.
Schema.org và JSON-LD — Không trực tiếp dùng RFC 8288, nhưng chia sẻ cùng tư duy: khai báo quan hệ ngữ nghĩa giữa các thực thể để máy hiểu được. JSON-LD khai báo quan hệ trong tầng dữ liệu có cấu trúc, trong khi RFC 8288 khai báo trong tầng liên kết (linking layer).
Microformats và RDFa — Các hệ thống embedding semantics vào HTML, cùng triết lý với RFC 8288 nhưng ở tầng markup thay vì header.
Khi bạn hiểu rằng RFC 8288, Schema.org, và các chuẩn liên quan đều phục vụ cùng một mục tiêu (giúp máy hiểu ngữ nghĩa của tài nguyên và quan hệ giữa chúng), bạn sẽ thấy rằng SEO theo hướng entity và semantic không phải là xu hướng mới, mà là hướng dẫn kỹ thuật đã được chuẩn hóa từ rất lâu.
Từ RFC 8288 Đến DLN: Tư Duy Quan Hệ Trong Hệ Thống Internal Link #
Framework DLN (Decision Ladder Navigation) của VLINK ASIA không xem internal link là thứ để rải cho đủ số lượng. DLN xem mỗi link là một khai báo quan hệ có hướng, phản ánh bước tiếp theo trong hành trình ra quyết định của người dùng.
Mô hình O → C → P → R → A (Orient → Choose → Prove → Rate → Act) định nghĩa năm loại quan hệ giữa các trang:
- O → C: Trang nhận biết (awareness) khai báo quan hệ dẫn dắt sang trang giúp người dùng lọc và chọn lựa. Anchor text cần phản ánh đúng bước “chọn” này, không phải lặp lại từ khóa của trang nguồn.
- C → P: Trang so sánh/lựa chọn dẫn đến trang chứng minh (proof): case study, testimonial, dữ liệu kết quả. Quan hệ này là “tôi cần bằng chứng trước khi tiếp tục”.
- P → R: Từ bằng chứng sang đánh giá. Người dùng đã thấy bằng chứng, cần xác nhận thêm từ đánh giá độc lập.
- R → A: Từ đánh giá sang hành động. Đây là nơi CTA phải xuất hiện, không phải trước đó.
Mỗi quan hệ này, nếu được khai báo đúng trong internal link, tạo ra một hệ thống tín hiệu mà Googlebot đọc được như một đồ thị có hướng, không phải một mạng lưới link hỗn độn.
Đây là phần mà hầu hết khóa học SEO ở Việt Nam không đề cập, vì họ dạy internal link theo kiểu “bao nhiêu link là đủ” thay vì “link này có ngữ nghĩa quan hệ gì”.
Checklist Audit RFC 8288 Cho Website Thực Chiến #
Dưới đây là danh sách kiểm tra thực tế bạn có thể áp dụng ngay:
Tầng HTTP Header:
- [ ] Kiểm tra các trang quan trọng nhất có khai báo
Link: ...; rel="canonical"trong HTTP header không (dùngcurl -I) - [ ] Nếu site đa ngôn ngữ: hreflang có được inject đúng theo URL pattern không?
- [ ] Canonical trong HTTP header có mâu thuẫn với canonical trong HTML không? (mâu thuẫn = Google có thể bỏ qua cả hai)
Tầng HTML:
- [ ] Mỗi trang có duy nhất một thẻ canonical không? (hai canonical trong HTML = tín hiệu bị vô hiệu hóa)
- [ ] Các trang phân trang (
?page=2) có self-canonical hay canonical về trang gốc không? - [ ]
rel="alternate"trong hreflang có khai báo đầy đủ x-default không?
Tầng Internal Link:
- [ ] Anchor text có phản ánh đúng kiểu quan hệ giữa trang nguồn và trang đích không?
- [ ] Các trang orphan (không có internal link trỏ vào) có nằm trong nhóm trang quan trọng không?
- [ ] Link flow từ tầng nhận biết có dẫn đúng hướng xuống tầng quyết định không?
Vì Sao Không Hiểu RFC 8288 Là Làm SEO Trong Bóng Tối #
Khi một SEOer không hiểu RFC 8288, họ rơi vào một trong các pattern sau:
Pattern 1: Tin tưởng tuyệt đối vào rel. Họ đặt canonical xong coi như “an toàn”. Khi canonical bị Google override, họ không hiểu vì sao và không có cách debug.
Pattern 2: Chỉ làm ở tầng HTML. Họ không biết rằng HTTP header là một tầng triển khai hoàn toàn hợp lệ và trong nhiều trường hợp ưu việt hơn. Với CMS phức tạp, đây là điểm mù nghiêm trọng.
Pattern 3: Hiểu link theo nghĩa vật lý, không theo nghĩa ngữ nghĩa. Họ đếm số lượng link, không thiết kế quan hệ. Kết quả là hệ thống internal link không tạo ra tín hiệu có giá trị cho crawler, và không dẫn dắt người dùng hiệu quả.
Hiểu RFC 8288 không có nghĩa là bạn sẽ viết HTTP header bằng tay mỗi ngày. Hiểu RFC 8288 có nghĩa là bạn biết hệ thống đang vận hành theo nguyên lý gì, và khi có sự cố, bạn biết debug từ tầng nào.
Đây là cách đào tạo SEO tại VLINK ASIA tiếp cận: dạy từ bản chất, không dạy từ checklist. Vì checklist thay đổi theo thuật toán, còn bản chất thì không.
RFC 8288 và AI Search: Tín Hiệu Liên Kết Trong Kỷ Nguyên LLM #
Một điểm ít được thảo luận nhưng ngày càng quan trọng: các hệ thống AI như Googlebot khi render trang để chuẩn bị cho AI Overviews, hay các crawler của Bing dùng để train Copilot, đều parse HTTP headers và HTML để xây đồ thị quan hệ tài nguyên.
Khi bạn khai báo rel="canonical" đúng, bạn đang nói với máy: “đây là tài nguyên đại diện cho nội dung này”. Khi bạn khai báo rel="alternate" đúng với hreflang, bạn đang nói: “đây là các phiên bản tương đương phục vụ các ngữ cảnh ngôn ngữ khác nhau”. Máy dùng các tín hiệu này để quyết định tài nguyên nào nên được trích dẫn trong AI Overviews, tài nguyên nào nên được phục vụ cho người dùng ở ngữ cảnh cụ thể.
Kết hợp với Schema.org (JSON-LD), RFC 8288 tạo thành một lớp tín hiệu ngữ nghĩa hoàn chỉnh mà dịch vụ SEO AI Overviews của VLINK ASIA xây dựng hệ thống xung quanh.
Đọc Tiếp RFC 8288 Ở Đâu? #
Nếu bạn muốn đọc trực tiếp spec, RFC 8288 được publish tại https://www.rfc-editor.org/rfc/rfc8288. Ngoài ra, IANA Link Relations registry (nơi tất cả registered relation types được liệt kê) ở tại https://www.iana.org/assignments/link-relations/link-relations.xhtml.
Đây là nguồn tham chiếu chuẩn. Không phải blog SEO. Không phải video YouTube. Là spec kỹ thuật được duy trì bởi tổ chức chuẩn hóa Internet.
Học SEO Từ Bản Chất Tại VLINK ASIA #
RFC 8288 chỉ là một trong nhiều nền tảng kỹ thuật mà Khóa học SEO Master tại VLINK ASIA đưa vào chương trình giảng dạy. Không phải để học viên trở thành kỹ sư mạng, mà để họ hiểu tại sao một tín hiệu có lúc được Google đọc và có lúc bị bỏ qua. Tại sao canonical không phải lệnh tuyệt đối. Tại sao internal link không phải là việc đếm số lượng.
Khi bạn hiểu bản chất, bạn không cần chạy theo mẹo mới sau mỗi lần Google cập nhật thuật toán. Bạn nhìn được những gì không thay đổi: nguyên lý hoạt động của hệ thống liên kết, ngữ nghĩa tài nguyên, và hành trình ra quyết định của người dùng.
36 buổi học trực tiếp. Lớp dưới 5 người. Quận 7, TP.HCM.
Xem lộ trình và học phí Khóa học SEO Master →
Hoặc nếu bạn muốn hiểu rõ hơn về lý do học phí 25 triệu là mức đầu tư hợp lý cho năng lực SEO Strategist, đọc thêm tại học phí Khóa học SEO Master.
10 FAQ cho bài RFC 8288 #
1. RFC 8288 có bắt buộc phải triển khai không? #
Không bắt buộc. RFC 8288 là chuẩn kỹ thuật mô tả cách khai báo liên kết có ngữ nghĩa giữa các tài nguyên web. Triển khai đúng giúp công cụ tìm kiếm và trình duyệt hiểu rõ hơn quan hệ giữa các URL, từ đó xử lý canonical, hreflang và phân trang chính xác hơn.
2. RFC 8288 khác gì so với việc chỉ đặt thẻ <link> trong HTML? #
Thẻ <link> trong HTML là một cách triển khai RFC 8288 ở tầng markup. RFC 8288 còn cho phép khai báo liên kết qua HTTP Link header, hoạt động ở tầng máy chủ trước khi HTML được parse, và áp dụng được cho cả tài nguyên không phải HTML như PDF hay JSON.
3. Google có đọc canonical khai báo qua HTTP header không? #
Có. Google Search Central xác nhận Googlebot đọc rel="canonical" từ cả HTTP header lẫn HTML. Nếu hai tầng mâu thuẫn nhau, Google có thể bỏ qua cả hai và tự chọn canonical dựa trên tín hiệu tổng thể.
4. Tôi có thể dùng HTTP header để khai báo hreflang không? #
Có. Cú pháp là Link: </en/>; rel="alternate"; hreflang="en" trong HTTP response header. Cách này đặc biệt hữu ích khi website có hàng nghìn URL đa ngôn ngữ và muốn xử lý hreflang tập trung ở tầng Nginx, Cloudflare Workers hay CDN thay vì trong từng trang HTML.
5. rel="nofollow" có phải là một registered relation type theo RFC 8288 không? #
Không. nofollow không có trong IANA Link Relations registry. Đây là một HTML microformat convention do Google tự giới thiệu năm 2005. Google xử lý nofollow theo logic riêng, không theo định nghĩa RFC 8288.
6. RFC 8288 có liên quan đến Schema.org không? #
Không trực tiếp, nhưng cùng triết lý. RFC 8288 khai báo quan hệ ngữ nghĩa ở tầng liên kết (HTTP header và HTML <link>), còn Schema.org khai báo quan hệ ngữ nghĩa ở tầng dữ liệu có cấu trúc (JSON-LD, Microdata). Cả hai đều giúp máy hiểu đúng tài nguyên và mối quan hệ giữa chúng.
7. Làm thế nào để kiểm tra website có đang khai báo HTTP Link header không? #
Dùng lệnh curl -I https://your-url.com trong terminal và tìm dòng bắt đầu bằng Link: trong response. Hoặc dùng tab Network trong Chrome DevTools, chọn request của trang, xem phần Response Headers.
8. Nếu canonical trong HTTP header khác canonical trong HTML thì Google xử lý thế nào? #
Google coi đây là tín hiệu mâu thuẫn và có thể bỏ qua cả hai, tự suy luận canonical dựa trên các tín hiệu khác như internal link, sitemap, và lịch sử index. Nguyên tắc là hai tầng phải nhất quán, hoặc chỉ dùng một tầng duy nhất.
9. RFC 8288 có ảnh hưởng đến cách AI như ChatGPT hay Google AI Overviews đọc nội dung không? #
Có ảnh hưởng gián tiếp. Các crawler dùng để thu thập dữ liệu huấn luyện và phục vụ AI Overviews đều parse HTTP headers và HTML link elements. Khai báo canonical đúng giúp AI hiểu đâu là tài nguyên đại diện cho một chủ đề, từ đó tăng khả năng trang đúng được trích dẫn thay vì phiên bản trùng lặp.
10. RFC 8288 có được cập nhật sau năm 2017 không? #
RFC 8288 phát hành tháng 10/2017 vẫn là phiên bản hiện hành, thay thế RFC 5988 (2010). IANA Link Relations registry được cập nhật liên tục khi có relation type mới được đăng ký, nhưng cấu trúc cốt lõi của RFC 8288 không thay đổi. Bạn có thể theo dõi registry tại iana.org/assignments/link-relations.
Ung Ho SEO Wiki
Bước tiếp theo
Muốn SEO lên top bền vững, hãy đi tiếp theo đúng cấp độ của bạn
Bài viết này chỉ là một phần trong hệ thống SEO của VLINK Asia. Bạn có thể đọc thêm tài liệu miễn phí, bắt đầu từ nền tảng, học full-stack SEO hoặc làm trực tiếp trên website thật của mình.
Trung tâm tài liệu
Kho tài liệu SEO thực chiến về Entity SEO, SEO cho AI, technical SEO, content, internal link, KPI, schema và cấu trúc website.
Vào Trung tâm tài liệuSEO Launchpad
Khóa học SEO nền tảng 8 buổi trong 1 tháng, phù hợp với người mới hoặc team cần hiểu đúng SEO trước khi triển khai sâu.
Xem SEO LaunchpadKhóa học SEO Master
Chương trình 36 buổi trong 3 tháng, học SEO tổng thể từ chiến lược, technical, content, entity, schema, internal link đến đo lường.
Xem SEO MasterMentor SEO 1:1
Mentor trực tiếp trên website của bạn: rà URL, menu, cấu trúc nội dung, internal link, KPI, landing page và kế hoạch SEO thực tế.
Xem Mentor SEO 1:1