Một doanh nghiệp logistics có thể phục vụ nhiều tuyến, nhiều cảng và nhiều tỉnh thành nhưng chỉ có một vài địa điểm vận hành thực. Nếu schema lại khai báo hàng loạt “chi nhánh” hoặc gắn Product cho mọi dịch vụ, dữ liệu có cấu trúc sẽ mô tả sai doanh nghiệp.
Với Schema Logistics B2B, EnterDizi ưu tiên một nguyên tắc: schema phải mô tả đúng doanh nghiệp, dịch vụ và phạm vi phục vụ đang có thật trên trang. Mục tiêu là giúp máy tìm kiếm hiểu quan hệ giữa công ty, chi nhánh, dịch vụ và khu vực; không biến schema thành mẹo “cộng điểm” địa phương.
Trước khi cấu hình, cần sửa ba nhầm lẫn thường gặp
LogisticsBusiness không phải tên type chuẩn để dùng mặc định
Schema.org hiện không có type chuẩn mang tên “LogisticsBusiness” như Restaurant hay MedicalBusiness. Vì vậy, doanh nghiệp logistics có địa điểm thực nên bắt đầu từ LocalBusiness hoặc Organization.
Phần dịch vụ được mô tả bằng Service và Offer khi phù hợp, thay vì tạo một type nghe sát ngành nhưng không tồn tại.
LocalBusiness trên Schema.org đại diện cho một doanh nghiệp hoặc chi nhánh có địa điểm vật lý cụ thể. Cách dùng này cũng phù hợp với hướng dẫn LocalBusiness của Google Search Central, trong đó mỗi địa điểm địa phương nên được mô tả như một LocalBusiness và ưu tiên subtype cụ thể nhất nếu có.
Với một forwarder đặt trụ sở tại TP.HCM nhưng nhận hàng đi Mỹ, châu Âu và nhiều tỉnh thành, không nên tự tạo “LogisticsBusiness” chỉ vì tên type nghe sát ngành. Tên ngành, dịch vụ và khu vực có thể thể hiện qua description, Service, Offer, hasOfferCatalog và areaServed.
Product không phải schema mặc định cho dịch vụ logistics
Product phù hợp khi trang thực sự nói về một sản phẩm cụ thể. Các yêu cầu Product của Google tập trung vào trang sản phẩm, giá, tình trạng hàng, review và các trải nghiệm mua sắm; với merchant listing, trang còn phải là nơi người mua có thể mua sản phẩm.
Dịch vụ vận chuyển FCL, LCL, khai báo hải quan, trucking hay kho bãi không tự nhiên trở thành Product chỉ vì doanh nghiệp muốn Google hiểu đó là một “gói dịch vụ”. Về mặt ngữ nghĩa, Service trên Schema.org phù hợp hơn cho dịch vụ giao nhận, vận chuyển và các dịch vụ được một tổ chức cung cấp.
Product chỉ nên xuất hiện nếu doanh nghiệp thật sự có trang sản phẩm, như pallet, thùng đóng gói hoặc thiết bị tracking có tên, hình ảnh và offer cụ thể. Nếu trang chỉ nhận RFQ cho dịch vụ vận tải, ép Product vào sẽ làm schema lệch khỏi nội dung người đọc nhìn thấy.
Service Area nên dùng areaServed, không phải nhồi địa danh
Schema.org hiện dùng areaServed để mô tả khu vực mà một Organization, Service hoặc Offer phục vụ; thuộc tính serviceArea cũ đã được đánh dấu là superseded. areaServed có thể nhận Text, Place, AdministrativeArea hoặc GeoShape tùy mức độ chi tiết.
Điểm quan trọng là areaServed mô tả phạm vi phục vụ, không phải một danh sách từ khóa địa phương để lặp tên thành phố. Nếu doanh nghiệp thực sự phục vụ TP.HCM, Bình Dương, Đồng Nai và các cảng liên quan, schema nên phản ánh đúng phạm vi đó và nội dung trên trang cũng phải nói rõ năng lực tương ứng.
Không nên kỳ vọng areaServed tự động làm thứ hạng local tăng. Nguyên tắc dữ liệu có cấu trúc của Google nêu rõ structured data có thể giúp trang đủ điều kiện cho một số tính năng hiển thị nhưng không bảo đảm rich result; markup sai hoặc gây hiểu lầm còn có thể bị bỏ qua.
Chọn schema theo thực thể thật trước khi nghĩ đến rich result
Trụ sở hoặc chi nhánh có địa điểm thật: dùng LocalBusiness
Nếu khách hàng hoặc đối tác có thể nhận diện một địa điểm doanh nghiệp cụ thể, LocalBusiness là nền hợp lý để mô tả tên công ty, địa chỉ, điện thoại, URL, logo, giờ làm việc và các thông tin liên quan.
Không nên tạo một LocalBusiness riêng cho mỗi tỉnh chỉ vì công ty có thể nhận hàng ở tỉnh đó. LocalBusiness mô tả một địa điểm kinh doanh thực, trong khi areaServed mới là nơi phù hợp để mô tả phạm vi phục vụ rộng hơn.
Nếu doanh nghiệp có nhiều văn phòng thật, mỗi địa điểm nên có dữ liệu nhất quán với trang location tương ứng. Tránh để website ghi một địa chỉ, Google Business Profile ghi địa chỉ khác và schema lại sinh thêm một phiên bản thứ ba.
Doanh nghiệp ở cấp thương hiệu hoặc mạng lưới: dùng Organization làm node gốc
Organization phù hợp để làm thực thể thương hiệu ở cấp toàn công ty, đặc biệt khi website có nhiều chi nhánh, nhiều dịch vụ hoặc nhiều thị trường.
Từ node Organization có thể liên kết đến các địa điểm LocalBusiness, các Service, contactPoint, logo, sameAs và các thuộc tính nhận diện khác. Cách tổ chức này giúp schema phản ánh kiến trúc doanh nghiệp thay vì tạo nhiều node rời rạc không biết thuộc cùng một công ty hay không.
Trang dịch vụ: dùng Service và Offer khi phù hợp
Một trang “vận chuyển đường biển Việt Nam – Mỹ” nên mô tả đúng dịch vụ được cung cấp. Service có thể chứa serviceType, provider, areaServed, offers và các thuộc tính liên quan; Offer có thể mô tả việc doanh nghiệp đang chào cung cấp dịch vụ đó.
Nếu giá không cố định và doanh nghiệp nhận RFQ theo tuyến, trọng lượng, container, incoterm hoặc lịch tàu, không cần bịa giá chỉ để lấp trường price. Có thể giữ offer ở mức phù hợp với dữ liệu thật và để CTA báo giá nằm trong nội dung hiển thị.
Nếu doanh nghiệp có danh mục dịch vụ, hasOfferCatalog hoặc OfferCatalog có thể giúp tổ chức các nhóm như vận tải biển, hàng không, trucking, khai quan và kho bãi. Mục tiêu là mô tả mối quan hệ thật, không phải gắn càng nhiều schema càng tốt.
Trang sản phẩm thật: lúc đó mới cân nhắc Product
Nếu website logistics có bán một sản phẩm hữu hình riêng, Product có thể đúng. Khi đó trang phải tập trung vào một sản phẩm hoặc biến thể cụ thể và dữ liệu Product phải khớp với nội dung hiển thị như name, image, offer, availability hoặc review nếu có thật.
Đối với trang dịch vụ logistics, Product không nên được dùng chỉ vì muốn có price hoặc availability. Tài liệu Product của Google dành trải nghiệm rich result cho sản phẩm và các ngữ cảnh mua sắm; vì vậy dùng Product cho dịch vụ vận tải có thể đúng cú pháp nhưng sai ý nghĩa.
areaServed nên được gắn vào dịch vụ, không chỉ gắn vào công ty
Một lỗi phổ biến là đặt areaServed ở Organization rồi cho rằng mọi dịch vụ của doanh nghiệp đều phục vụ toàn bộ khu vực đó. Thực tế, tuyến biển quốc tế, trucking nội địa, kho lạnh và khai báo hải quan có thể có phạm vi phục vụ khác nhau.
Nếu dịch vụ vận tải biển chỉ khai thác một số tuyến, Service nên thể hiện areaServed tương ứng với thị trường hoặc khu vực mà dịch vụ đó thực sự hoạt động. Nếu trucking chỉ nhận ở miền Nam, không nên kế thừa areaServed “Vietnam” từ một node tổng rồi khiến mọi dịch vụ trông như phủ toàn quốc.
Cách này cũng giúp nội dung và schema đi cùng nhau. Trang nào nói về tuyến Việt Nam – Mỹ thì schema mô tả đúng tuyến hoặc khu vực liên quan; trang nào nói về dịch vụ giao nhận tại TP.HCM thì areaServed phản ánh phạm vi địa phương tương ứng.
Một cấu trúc JSON-LD phù hợp hơn cho doanh nghiệp logistics
Ví dụ dưới đây dùng LocalBusiness làm thực thể địa điểm và Service làm thực thể dịch vụ. Đây là khung minh họa, không phải đoạn mã để copy nguyên cho mọi doanh nghiệp.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "LocalBusiness",
"@id": "https://example.com/#business",
"name": "ABC Logistics",
"url": "https://example.com/",
"telephone": "+84-28-xxxx-xxxx",
"address": {
"@type": "PostalAddress",
"streetAddress": "Địa chỉ thực tế",
"addressLocality": "Ho Chi Minh City",
"addressCountry": "VN"
},
"areaServed": [
{"@type": "AdministrativeArea", "name": "Ho Chi Minh City"},
{"@type": "AdministrativeArea", "name": "Binh Duong"},
{"@type": "AdministrativeArea", "name": "Dong Nai"}
]
},
{
"@type": "Service",
"@id": "https://example.com/van-tai-bien-viet-nam-my/#service",
"name": "Vận chuyển đường biển Việt Nam - Mỹ",
"serviceType": "Ocean Freight",
"provider": {"@id": "https://example.com/#business"},
"areaServed": [
{"@type": "Country", "name": "Vietnam"},
{"@type": "Country", "name": "United States"}
],
"url": "https://example.com/van-tai-bien-viet-nam-my/"
}
]
}Điểm cần giữ không phải từng dòng code, mà là quan hệ giữa các thực thể. Business là đơn vị cung cấp, Service là dịch vụ cụ thể, areaServed thuộc về đúng node cần mô tả và mọi URL đều phải dẫn tới nội dung thật.
Nếu doanh nghiệp có nhiều chi nhánh, có thể tạo từng LocalBusiness với @id riêng và liên kết về Organization. Nếu có nhiều dịch vụ, mỗi Service nên có @id ổn định để tránh plugin tạo node trùng lặp mỗi lần render.
Khi nào nên lồng Product vào hệ thống schema
Product chỉ nên đứng cạnh hệ thống LocalBusiness/Organization khi website có một thực thể sản phẩm đúng nghĩa.
Ví dụ, doanh nghiệp logistics vừa cung cấp dịch vụ vừa bán thiết bị giám sát nhiệt độ container. Trang thiết bị đó có thể dùng Product, còn trang vận chuyển cold chain vẫn dùng Service. Hai node có thể cùng thuộc thương hiệu nhưng không nên ép về cùng một type.
Nếu một trang là “dịch vụ kho lạnh”, đừng đổi thành Product chỉ vì có bảng giá. Nếu một trang là “thiết bị logger nhiệt độ model X”, có hình ảnh, mã sản phẩm và offer cụ thể, Product mới có cơ sở rõ ràng hơn.
Phân biệt này giúp website tránh một lỗi thường gặp: schema nhìn có vẻ “nhiều tính năng” nhưng không khớp nội dung. Nguyên tắc chung của Google yêu cầu structured data phải mô tả nội dung mà người dùng thực sự nhìn thấy trên trang.
Service Area trên website và Service Area trên Google Business Profile không phải một việc
areaServed trong JSON-LD là dữ liệu trên website. Service area trong Google Business Profile là cấu hình hồ sơ doanh nghiệp trên hệ sinh thái Google Maps/Business Profile. Hai phần nên nhất quán về logic nhưng không nên coi chúng là cùng một trường dữ liệu.
Doanh nghiệp phục vụ theo khu vực vẫn cần một hồ sơ gắn với cơ sở trung tâm hoặc địa điểm đủ điều kiện; văn phòng ảo không nên được dùng chỉ để tạo thêm vùng hiện diện. Đây cũng là nguyên tắc được nêu trong hướng dẫn Service Area của Google Business Profile.
Với doanh nghiệp logistics, điều này đặc biệt quan trọng vì “có thể lấy hàng tại Hà Nội” không đồng nghĩa với “có chi nhánh Hà Nội”. Website có thể nói rõ khu vực phục vụ, nhưng schema và Business Profile không nên biến vùng phục vụ thành địa chỉ giả.
Muốn hiện diện địa phương tốt hơn, nội dung phải chứng minh được phạm vi phục vụ
Nếu trang chỉ gắn areaServed = “Ho Chi Minh City” nhưng không có bất kỳ thông tin nào về điểm lấy hàng, cảng, tuyến, thời gian vận hành, kho hoặc đầu mối phục vụ tại khu vực đó, schema đang nói nhiều hơn nội dung.
Cách tốt hơn là xây trang dịch vụ có bối cảnh địa phương thật: tuyến đang khai thác, cảng thường dùng, loại hàng phù hợp, phạm vi pickup, thời gian cut-off, đầu mối liên hệ và điều kiện báo giá. Khi đó schema chỉ đóng vai trò tóm tắt lại một thực thể đã được nội dung chứng minh.
Không cần nhắc tên địa phương ở mọi heading. Chỉ nên đưa khu vực vào nơi nó giúp người đọc hiểu phạm vi dịch vụ hoặc ra quyết định.
Đừng coi schema là “điểm cộng local SEO” tách rời khỏi website
Structured data giúp máy tìm kiếm hiểu trang tốt hơn và có thể tạo điều kiện cho một số hình thức hiển thị. Nhưng Google không công bố một cơ chế kiểu “thêm areaServed = cộng điểm local”.
Nếu doanh nghiệp muốn tăng khả năng được hiểu đúng theo khu vực, schema cần đi cùng dữ liệu nhất quán: tên doanh nghiệp, địa chỉ thật, số điện thoại, trang location, Google Business Profile, nội dung dịch vụ, tuyến vận tải và tín hiệu thương hiệu.
Vì vậy, tiêu đề “ăn điểm hiển thị địa phương” nên được hiểu theo nghĩa tăng độ rõ của thực thể, không phải cam kết tăng thứ hạng. Đây là cách diễn đạt an toàn hơn cho cả SEO lẫn kỳ vọng kinh doanh.
Cấu hình schema theo kiến trúc website thay vì từng trang rời rạc
Schema mạnh nhất khi các node có cùng @id và được tái sử dụng có kiểm soát. Nếu homepage có một Organization, trang dịch vụ lại tự sinh một Organization khác tên gần giống, còn plugin SEO tạo thêm LocalBusiness thứ ba, Google có thể nhận nhiều node không đồng nhất thay vì một thực thể rõ ràng.
Ở cấp website, nên chốt trước ba lớp: thực thể công ty, thực thể địa điểm và thực thể dịch vụ. Sau đó từng trang chỉ tham chiếu lại đúng node cần thiết.
Trang chủ có thể giữ Organization hoặc LocalBusiness chính. Trang chi nhánh mô tả LocalBusiness cụ thể. Trang dịch vụ mô tả Service và provider trỏ về thực thể doanh nghiệp. Trang sản phẩm thực mới dùng Product.
Nếu dùng Rank Math, Yoast hoặc plugin schema riêng, cần kiểm tra đầu ra cuối cùng thay vì chỉ nhìn giao diện cấu hình. Hai plugin cùng sinh Organization hoặc Product rất dễ tạo markup trùng mà người quản trị không nhận ra.
Quy trình kiểm tra schema trước khi publish
Bước 1: Xác định thực thể chính của trang
Hỏi trang này đang nói về công ty, một chi nhánh, một dịch vụ hay một sản phẩm. Nếu chưa trả lời được câu này, chưa nên chọn @type.
Bước 2: Kiểm tra type có tồn tại và đúng nghĩa
Không dùng tên type vì nghe “đúng ngành”. Hãy đối chiếu Schema.org và tài liệu Google nếu mục tiêu là một rich result cụ thể.
Bước 3: Chỉ thêm thuộc tính có dữ liệu thật
Địa chỉ, số điện thoại, rating, giá, availability, service area hay sameAs đều phải khớp với thông tin doanh nghiệp đang công bố. Thiếu dữ liệu thì bỏ, không điền cho đủ.
Bước 4: Gắn areaServed đúng node
Phạm vi toàn công ty có thể nằm ở Organization. Phạm vi của một dịch vụ cụ thể nên nằm ở Service hoặc Offer liên quan. Không mặc định mọi node đều phục vụ cùng một khu vực.
Bước 5: Kiểm tra nội dung hiển thị
Nếu JSON-LD nói doanh nghiệp phục vụ một khu vực, trang nên có nội dung hỗ trợ cho thông tin đó. Nếu Product có giá, người dùng cũng phải nhìn thấy giá hoặc offer tương ứng trên trang.
Bước 6: Test bằng công cụ phù hợp
Rich Results Test giúp kiểm tra các loại structured data mà Google hỗ trợ cho rich result. Schema Markup Validator hữu ích để kiểm tra cú pháp và quan hệ Schema.org rộng hơn, kể cả những type không tạo rich result riêng trên Google.
Bước 7: Kiểm tra URL đã index và theo dõi Search Console
Sau khi publish, cần dùng URL Inspection để xem Google đã crawl markup mới chưa. Nếu website có báo cáo enhancement tương ứng, theo dõi lỗi và cảnh báo thay vì coi việc plugin báo “schema valid” là kết thúc.
Những lỗi dễ gặp khi tối ưu schema cho doanh nghiệp logistics
Có nên dùng @type “LogisticsBusiness” vì đúng tên ngành hơn không?
Không nên nếu type đó không tồn tại trong Schema.org. Với doanh nghiệp logistics có địa điểm thực, LocalBusiness hoặc Organization kết hợp Service thường an toàn và đúng ngữ nghĩa hơn.
Có nên dùng Product cho dịch vụ vận tải để được hiển thị giá đẹp hơn không?
Không nên chỉ vì mục tiêu hiển thị. Product phải mô tả sản phẩm đúng nghĩa và nội dung trang phải phù hợp với yêu cầu của Google cho product rich results. Dịch vụ logistics nên được mô tả bằng Service/Offer nếu đó mới là bản chất của trang.
areaServed càng nhiều tỉnh thì càng mạnh local SEO phải không?
Không có cơ sở để coi số lượng khu vực trong areaServed là điểm xếp hạng. Chỉ nên khai báo nơi doanh nghiệp thực sự phục vụ và có nội dung hoặc vận hành hỗ trợ cho phạm vi đó.
Có nên tạo LocalBusiness cho mỗi thành phố mà doanh nghiệp có thể lấy hàng?
Không. LocalBusiness đại diện cho địa điểm doanh nghiệp cụ thể. Khu vực pickup hoặc service area không tự biến thành một chi nhánh.
Có cần đặt cùng một schema trên mọi trang?
Không. Thực thể doanh nghiệp có thể được tham chiếu xuyên site, nhưng từng trang cần thêm đúng entity chính của nó. Trang dịch vụ khác trang sản phẩm; trang location khác bài blog.
Một hệ thống schema tốt không dừng ở việc “valid”
Một đoạn JSON-LD có thể hợp cú pháp nhưng vẫn mô tả sai doanh nghiệp. Đó là lý do QA schema cần nhìn cả ba lớp: cú pháp, ý nghĩa và độ khớp với nội dung hiển thị.
Với Schema Logistics B2B, lớp ý nghĩa đặc biệt quan trọng vì doanh nghiệp thường có nhiều tuyến, nhiều dịch vụ và vùng phục vụ rộng. Nếu tất cả được nhồi vào một node duy nhất, schema khó phản ánh đúng cấu trúc vận hành.
Một hệ thống SEO Logistics B2B tốt nên nối thực thể công ty với từng dịch vụ, tuyến vận tải và điểm chạm RFQ. Khi cấu trúc website và schema cùng nói một câu chuyện, internal link và hành trình báo giá sẽ tự nhiên hơn thay vì trở thành các lớp tối ưu tách rời.
Schema nên giúp Google hiểu đúng, không giúp doanh nghiệp “trông lớn hơn”
Nếu công ty chỉ có một văn phòng nhưng phục vụ toàn quốc, hãy nói đúng như vậy. Nếu chỉ một số dịch vụ phủ toàn quốc, areaServed nên nằm ở những dịch vụ đó. Nếu chưa bán sản phẩm, không cần Product.
Cách làm này có vẻ ít “markup” hơn, nhưng bền hơn khi website mở rộng. Khi có thêm chi nhánh, tuyến hoặc sản phẩm thật, doanh nghiệp chỉ cần thêm node mới vào hệ thống thay vì sửa lại một cấu trúc đã phóng đại từ đầu.
Nếu website logistics đang có nhiều plugin cùng sinh schema hoặc đội web chưa rõ nên dùng LocalBusiness, Organization hay Service cho từng loại trang, hãy bắt đầu bằng một lần audit entity và đầu ra JSON-LD trên các trang chính.
EnterDizi có thể rà node trùng, mapping schema và phạm vi areaServed trước khi triển khai rộng để tránh sửa lại cả hệ thống sau này.