SEO Shopify: khai thác đúng những gì nền tảng đã làm sẵn trước khi tùy chỉnh
Dịch vụ SEO Shopify của RED: ma trận built-in và tùy chỉnh, sơ đồ crawl collection–product, sổ rủi ro theme/app, kiểm tra Markets và ma trận redirect vòng đời sản phẩm.
Phần lớn công việc gọi là "SEO Shopify" trên thị trường thuộc một trong hai nhóm, và cả hai đều bỏ qua điều quan trọng nhất về nền tảng này.
Nhóm thứ nhất là danh sách kiểm tra chung: viết lại thẻ tiêu đề, thêm thẻ mô tả, thêm thuộc tính mô tả cho ảnh, cài một ứng dụng tối ưu tốc độ, cài một ứng dụng SEO. Nhóm thứ hai là tùy chỉnh sâu: sửa file cấu hình robots, chèn thẻ canonical thủ công, viết mã để thay đổi cách sinh URL — thường được thực hiện mà không kiểm tra xem nền tảng đã xử lý những việc đó chưa.
Điều quan trọng bị bỏ qua: Shopify là nền tảng có nhiều thành phần kỹ thuật được tạo tự động. Tài liệu chính thức của Shopify nêu rõ nền tảng tự sinh thẻ canonical, tệp sitemap, tệp robots và chứng chỉ bảo mật, trong khi các phần như thẻ tiêu đề, thẻ mô tả, cấu trúc URL và thuộc tính mô tả ảnh do người quản trị nhập. Nghĩa là một phần đáng kể các hạng mục trong danh sách kiểm tra chung đã được xử lý, còn một số việc tùy chỉnh sâu là can thiệp vào thứ đang hoạt động đúng.
Trang này mô tả cách RED làm việc với Shopify: kiểm kê những gì nền tảng đã làm sẵn trước khi đề xuất bất kỳ thay đổi nào, kiểm tra đường đi từ danh mục tới sản phẩm, lập sổ rủi ro cho giao diện và các ứng dụng cài thêm, kiểm tra cấu hình đa thị trường thay vì tin vào việc bật công tắc, xác minh cách xử lý biến thể sản phẩm trên chính giao diện đang chạy, xây ma trận chuyển hướng theo vòng đời sản phẩm, áp dụng quy trình migration khi chuyển vào hoặc ra khỏi nền tảng, và ghi nhật ký các thay đổi trong trang quản trị.
Ranh giới đặt trước: RED không cam kết được lập chỉ mục hay có thứ hạng, không tùy chỉnh các thành phần mặc định khi không có lý do cụ thể, và không đưa ra kết luận về hành vi của giao diện hoặc ứng dụng khi chưa kiểm chứng trên chính cửa hàng đó.
Bắt đầu bằng việc kiểm kê những gì nền tảng đã làm sẵn
Câu hỏi: thành phần nào Shopify tự xử lý, thành phần nào do người quản trị nhập, và thành phần nào cần can thiệp vào mã giao diện?
Việc trả lời câu hỏi này trước tiên tránh được hai loại lãng phí. Loại thứ nhất là làm lại việc đã có — cài một ứng dụng để sinh sitemap trong khi nền tảng đã sinh, hoặc chèn thẻ canonical thủ công trong khi giao diện đã có sẵn. Loại thứ hai nghiêm trọng hơn: can thiệp vào một cơ chế đang hoạt động đúng và tạo ra xung đột.
Ma trận thành phần sẵn có và thành phần cần tùy chỉnh
| Thành phần | Ai xử lý | Việc cần làm | Khi nào cân nhắc tùy chỉnh |
|---|---|---|---|
| Thẻ canonical | Nền tảng tự sinh | Kiểm tra giá trị thực tế trên các loại trang | Khi giao diện tùy chỉnh làm sai giá trị |
| Tệp sitemap | Nền tảng tự tạo và cập nhật | Nộp trong Search Console, kiểm tra nội dung | Hiếm khi cần |
| Tệp robots | Nền tảng tạo mặc định, có thể tùy chỉnh qua tệp mẫu | Đọc và hiểu quy tắc mặc định trước | Chỉ khi có lý do cụ thể được ghi lại |
| Chứng chỉ bảo mật | Nền tảng cung cấp | Kiểm tra hoạt động đúng | Không |
| Thẻ tiêu đề và thẻ mô tả | Người quản trị nhập | Viết theo quy tắc, tránh trùng lặp | Đây là việc thủ công, không phải tùy chỉnh |
| Cấu trúc URL | Nền tảng quy định phần tiền tố, người quản trị đặt phần định danh | Đặt định danh có nghĩa, ổn định | Không thay đổi được phần tiền tố |
| Thuộc tính mô tả ảnh | Người quản trị nhập | Viết mô tả đúng nội dung ảnh | — |
| Dữ liệu có cấu trúc | Tùy giao diện | Kiểm tra loại nào đang được khai và có hợp lệ không | Bổ sung khi giao diện thiếu loại cần thiết |
| Chuyển hướng URL | Có công cụ trong trang quản trị | Thiết lập khi đổi định danh sản phẩm | — |
Về tệp robots: Shopify cho phép tùy chỉnh thông qua một tệp mẫu, nhưng chính tài liệu của nền tảng lưu ý rằng cấu hình mặc định nhìn chung phù hợp với nền tảng và việc thay đổi cần có lý do. Nguyên tắc RED áp dụng: mọi thay đổi ở tệp này phải kèm một dòng ghi rõ vì sao thay đổi, ai quyết định, và ngày thực hiện. Đây là loại thay đổi có thể gây hậu quả trên diện rộng mà không tạo ra lỗi nào nhìn thấy được.
Một điểm cần làm rõ về tài liệu nền tảng
Tài liệu trợ giúp của Shopify có nêu một số hướng dẫn về cách viết nội dung, trong đó có phần đề cập tới mật độ từ khóa. Cần phân biệt rõ: đây là gợi ý của nền tảng dành cho người bán, không phải quy tắc xếp hạng của Google. Tài liệu của Google về tạo nội dung hữu ích tập trung vào tính nguyên bản, kiến thức trực tiếp và giá trị cho người đọc — không nêu bất kỳ ngưỡng mật độ từ khóa nào.
RED viết nội dung theo nguyên tắc phục vụ người đọc và không tối ưu theo các ngưỡng số học về từ khóa. Đây là điểm cần nói rõ vì nhiều đơn vị dịch vụ trích dẫn tài liệu của nền tảng như thể đó là quy tắc của công cụ tìm kiếm.
Kiểm tra đường đi từ danh mục tới sản phẩm
Câu hỏi: từ trang chủ, một crawler có đi tới được mọi sản phẩm quan trọng không?
Tài liệu của Google về cấu trúc website thương mại điện tử nhấn mạnh việc các liên kết từ trang danh mục tới trang sản phẩm phải là liên kết mà crawler đi theo được. Trên Shopify, đây là chỗ dễ phát sinh vấn đề vì nhiều giao diện hiện đại xây phần lọc và phân trang bằng JavaScript, và một số cấu hình làm sản phẩm chỉ tiếp cận được qua thao tác của người dùng.
Sơ đồ crawl từ danh mục tới sản phẩm
| Hạng mục kiểm tra | Cách kiểm tra | Ngưỡng cần xem lại |
|---|---|---|
| Điều hướng chính | Kiểm tra các mục menu là liên kết chuẩn có địa chỉ đích | Menu dùng sự kiện thay vì liên kết |
| Trang danh mục | Mỗi danh mục có URL riêng, truy cập trực tiếp được | Danh mục chỉ tồn tại dưới dạng bộ lọc |
| Phân trang trong danh mục | Trang thứ hai trở đi có URL riêng, truy cập trực tiếp được | Chỉ tải thêm khi cuộn hoặc bấm, không có URL |
| Sản phẩm mồ côi | So sánh danh sách sản phẩm trong trang quản trị với danh sách crawl được | Bất kỳ sản phẩm nào không xuất hiện trong kết quả crawl |
| Sản phẩm không thuộc danh mục nào | Kiểm tra trong trang quản trị | Sản phẩm chỉ tiếp cận được qua tìm kiếm nội bộ |
| Đường dẫn phân cấp | Có tồn tại và trỏ đúng danh mục không | Không có, hoặc trỏ sai |
| Sản phẩm liên quan | Có liên kết giữa các sản phẩm cùng nhóm không | Không có liên kết ngang |
| Bộ lọc trong danh mục | Tổ hợp lọc nào sinh URL riêng và có được lập chỉ mục không | Sinh hàng loạt URL không kiểm soát |
Cách thực hiện: chạy một bản crawl bắt đầu từ trang chủ, chỉ đi theo liên kết, không nạp sitemap. Sau đó đối chiếu danh sách URL tìm được với danh sách sản phẩm trong trang quản trị. Chênh lệch giữa hai danh sách chính là nhóm sản phẩm mồ côi.
Nguyên tắc: không dựa vào tệp sitemap và ô tìm kiếm nội bộ làm cơ chế phát hiện sản phẩm. Sitemap giúp Google biết URL tồn tại nhưng không thay thế được cấu trúc liên kết; ô tìm kiếm nội bộ thì crawler không sử dụng.
Về bộ lọc: đây là nguồn sinh URL lớn nhất trên các cửa hàng có nhiều thuộc tính sản phẩm. Cần quyết định trước tổ hợp nào đáng có URL riêng được lập chỉ mục — thường là các tổ hợp có nhu cầu tìm kiếm thật — và tổ hợp nào chỉ nên thay đổi hiển thị. Nguyên tắc kiến trúc chung cho website thương mại điện tử thuộc SEO thương mại điện tử; phần này mô tả cách áp dụng trong ràng buộc của nền tảng.
Giao diện và ứng dụng cài thêm tạo ra nợ kỹ thuật
Câu hỏi: các ứng dụng đang cài chèn thêm gì vào trang, và giao diện đang dựng nội dung thế nào?
Đây là đặc thù lớn nhất của Shopify so với các nền tảng khác. Một cửa hàng vận hành vài năm thường tích lũy nhiều ứng dụng, mỗi ứng dụng chèn mã của nó vào giao diện. Khi gỡ ứng dụng, phần mã chèn vào không phải lúc nào cũng được xóa hết — để lại các đoạn mã không còn tác dụng nhưng vẫn tải trên mọi trang.
Vấn đề không nằm ở việc dùng ứng dụng. Nhiều ứng dụng mang lại giá trị thật. Vấn đề nằm ở việc không ai theo dõi tổng thể những gì đang được chèn vào.
Sổ rủi ro của giao diện và ứng dụng
| Nguồn rủi ro | Vấn đề có thể phát sinh | Cách kiểm tra | Ai chịu trách nhiệm |
|---|---|---|---|
| Giao diện tùy chỉnh | Thẻ canonical sai, thiếu thẻ tiêu đề chính, cấu trúc tiêu đề dùng sai mục đích | Crawl và kiểm tra mã sau khi dựng trang | Đơn vị phát triển giao diện |
| Mã chèn từ ứng dụng | Tăng thời gian tải, chặn hiển thị nội dung | Kiểm tra danh sách tài nguyên tải trên trang | Người quản trị cửa hàng |
| Ứng dụng đã gỡ | Mã còn sót lại vẫn tải | Rà soát mã giao diện tìm phần còn lại | Đơn vị phát triển |
| Công cụ dựng trang | Sinh cấu trúc phức tạp, nội dung phụ thuộc JavaScript | So sánh HTML nguồn và HTML sau khi dựng | Người quản trị |
| Ứng dụng đánh giá sản phẩm | Khai dữ liệu có cấu trúc không khớp nội dung hiển thị | Công cụ kiểm tra dữ liệu có cấu trúc | Người quản trị |
| Ứng dụng lọc và tìm kiếm | Sinh URL không kiểm soát, hoặc làm danh sách sản phẩm không crawl được | Crawl trang danh mục | Người quản trị |
| Ứng dụng chuyển hướng | Tạo chuỗi chuyển hướng nhiều bước | Kiểm tra chuỗi chuyển hướng | Người quản trị |
| Ứng dụng đa ngôn ngữ | Xung đột với cơ chế đa thị trường của nền tảng | Kiểm tra khai báo hreflang thực tế | Người quản trị |
Nguyên tắc chẩn đoán: không kết luận một ứng dụng gây ra vấn đề khi chưa có bằng chứng. Cách xác minh là so sánh trước và sau — chụp trạng thái, thực hiện thay đổi trên môi trường thử nghiệm hoặc trong khung giờ thấp điểm, chụp lại, đối chiếu. Việc gỡ hàng loạt ứng dụng dựa trên phỏng đoán có thể làm hỏng chức năng kinh doanh mà không giải quyết vấn đề gốc.
Về việc thêm ứng dụng mới: mỗi lần cài một ứng dụng là một thay đổi trên toàn bộ cửa hàng. Cần có bước đánh giá trước — ứng dụng này chèn gì vào trang, có thay thế được chức năng đã có không, ai chịu trách nhiệm gỡ khi không dùng nữa — và ghi vào nhật ký thay đổi.
Cấu hình đa thị trường cần kiểm tra, không chỉ bật công tắc
Câu hỏi: các phiên bản theo thị trường có đang sinh ra khai báo đúng không?
Tài liệu của Shopify nêu rằng khi cấu hình đa thị trường được thiết lập đúng, nền tảng xử lý URL theo thị trường, khai báo hreflang, thẻ canonical và tệp sitemap cho các phiên bản quốc tế. Điều này giảm đáng kể khối lượng công việc kỹ thuật so với việc tự triển khai.
Nhưng cụm từ quan trọng trong câu trên là "khi được thiết lập đúng". Việc bật một tính năng không đảm bảo đầu ra chính xác trong mọi trường hợp, đặc biệt với các giao diện đã tùy chỉnh nhiều hoặc khi có ứng dụng đa ngôn ngữ chạy song song.
Bảng kiểm tra cấu hình đa thị trường
| Hạng mục | Cần xác minh | Cách kiểm tra | Lỗi hay gặp |
|---|---|---|---|
| Khả năng phục vụ thực tế | Thị trường này có thực sự bán và giao được không | Xác nhận với đội kinh doanh | Bật thị trường mà chưa giao hàng tới được |
| Cấu trúc URL theo thị trường | Mỗi thị trường có URL riêng, truy cập trực tiếp được | Truy cập thử từng phiên bản | Phiên bản chỉ hiện khi phát hiện vị trí |
| Ngôn ngữ | Nội dung hiển thị đúng ngôn ngữ của phiên bản | Kiểm tra thủ công | Trộn lẫn ngôn ngữ trên cùng trang |
| Khai báo hreflang | Đối xứng giữa các phiên bản, mã hợp lệ | Crawl và đối chiếu | Thêm thị trường mới nhưng phiên bản cũ chưa cập nhật |
| Thẻ canonical | Mỗi phiên bản tự trỏ | Crawl và kiểm tra giá trị | Giao diện tùy chỉnh ghi đè giá trị |
| Tệp sitemap quốc tế | Có sinh cho từng phiên bản không | Truy cập trực tiếp | Chỉ có sitemap của thị trường chính |
| Điều hướng người dùng | Không chuyển hướng bắt buộc theo vị trí | Kiểm tra hành vi khi truy cập trực tiếp | Tự động chuyển hướng làm crawler không thấy phiên bản khác |
| Đơn vị tiền tệ và giá | Hiển thị đúng theo thị trường | Kiểm tra thủ công | Giá hiển thị đúng nhưng thanh toán không hỗ trợ |
| Ứng dụng dịch chạy song song | Có xung đột với cơ chế của nền tảng không | Kiểm tra khai báo thực tế | Hai cơ chế cùng sinh hreflang khác nhau |
Dòng cuối cùng là nguyên nhân của nhiều sự cố khó chẩn đoán. Khi một cửa hàng vừa dùng cơ chế đa thị trường của nền tảng vừa cài một ứng dụng dịch có tính năng tương tự, hai cơ chế có thể sinh ra khai báo mâu thuẫn. Cần chọn một cơ chế và tắt cơ chế còn lại.
Dòng đầu tiên là cổng chặn. Việc bật một thị trường trong trang quản trị dễ hơn nhiều so với việc thực sự phục vụ được thị trường đó. Nếu chưa giao hàng tới nơi, chưa nhận được thanh toán, hoặc chưa có ai hỗ trợ bằng ngôn ngữ đó, thì việc mở phiên bản chỉ tạo ra trải nghiệm xấu.
Nguyên tắc chiến lược cho việc mở rộng ra nhiều thị trường — cách chọn thị trường, cách bản địa hóa, cách đo lường theo quốc gia — thuộc SEO quốc tế; phần này mô tả cách xác minh việc triển khai trên nền tảng.
Biến thể sản phẩm và thẻ canonical phải kiểm trên giao diện thật
Câu hỏi: các biến thể sản phẩm sinh ra URL thế nào, và thẻ canonical đang trỏ đâu?
Đây là chỗ không nên suy đoán từ hành vi mặc định, vì kết quả phụ thuộc vào giao diện đang dùng và các ứng dụng đang cài. Cùng một nền tảng nhưng hai cửa hàng với hai giao diện khác nhau có thể xử lý biến thể theo hai cách khác nhau.
Kiểm tra biến thể sản phẩm và thẻ canonical
| Hạng mục | Cần xác minh | Cách kiểm tra |
|---|---|---|
| URL của biến thể | Chọn biến thể có làm URL thay đổi không | Chọn thử từng biến thể và quan sát địa chỉ |
| Thẻ canonical trên URL biến thể | Trỏ về đâu | Xem mã nguồn trang sau khi chọn biến thể |
| Nội dung theo biến thể | Tiêu đề, mô tả, ảnh có thay đổi không | So sánh giữa các biến thể |
| Truy cập trực tiếp URL biến thể | Trang có hiển thị đúng biến thể không | Mở URL trong tab mới |
| Dữ liệu có cấu trúc | Loại nào đang được khai, có phản ánh đúng nhóm sản phẩm và biến thể không | Công cụ kiểm tra của Google |
| Liên kết nội bộ | Trang danh mục trỏ tới URL nào | Kiểm tra mã trang danh mục |
| URL có tham số | Các tham số theo dõi có sinh trang được lập chỉ mục không | Crawl và kiểm tra |
Nguyên tắc quyết định: biến thể có nhu cầu tìm kiếm riêng — người ta thực sự tìm theo màu, theo kích cỡ, theo dung lượng — thì đáng có trang riêng với thẻ canonical tự trỏ. Biến thể không có nhu cầu tìm kiếm riêng thì nên gộp về trang sản phẩm chính.
Câu hỏi kiểm tra thực dụng: có ai gõ tên sản phẩm kèm thuộc tính này khi tìm kiếm không? Với một số ngành hàng, câu trả lời là có và rõ ràng; với ngành hàng khác thì không. Việc áp dụng một quy tắc chung cho mọi cửa hàng là sai.
Tài liệu của Google về dữ liệu có cấu trúc cho thương mại điện tử mô tả các loại đánh dấu phù hợp với sản phẩm, nhóm sản phẩm và đường dẫn phân cấp. Cần lưu ý rằng việc khai đúng dữ liệu có cấu trúc không đảm bảo kết quả sẽ hiển thị dưới dạng nổi bật — đây là điều kiện để đủ tư cách, không phải cam kết.
Vòng đời sản phẩm cần ma trận chuyển hướng
Câu hỏi: khi sản phẩm đổi tên, hết hàng, ngừng kinh doanh hoặc có sản phẩm thay thế, xử lý URL thế nào?
Với cửa hàng có danh mục thay đổi thường xuyên, đây là công việc lặp lại chứ không phải sự kiện. Việc không có quy tắc rõ ràng dẫn tới hai kiểu xử lý sai: hoặc để hàng loạt trang trả về lỗi không tìm thấy, hoặc chuyển hướng tất cả về trang chủ.
Cách thứ hai là kiểu sai mà tài liệu của Google cảnh báo: chuyển hướng nhiều URL không liên quan về một đích chung có thể bị xử lý như trang không tồn tại.
Ma trận chuyển hướng theo vòng đời sản phẩm
| Tình huống | Xử lý URL | Xử lý nội dung | Lý do |
|---|---|---|---|
| Đổi định danh sản phẩm | Thiết lập chuyển hướng từ định danh cũ sang mới | Giữ nguyên nội dung | URL cũ có thể đang có liên kết trỏ tới |
| Hết hàng tạm thời | Giữ nguyên URL, trả mã 200 | Hiển thị rõ tình trạng, cho phép đăng ký nhận thông báo | Sản phẩm sẽ quay lại |
| Ngừng kinh doanh, có sản phẩm thay thế tương đương | Chuyển hướng tới sản phẩm thay thế | — | Người dùng vẫn tìm được thứ tương tự |
| Ngừng kinh doanh, không có thay thế trực tiếp | Chuyển hướng tới danh mục cha | — | Danh mục phục vụ cùng nhu cầu ở mức khái quát |
| Ngừng kinh doanh, không còn ngành hàng đó | Trả mã 404 hoặc 410 | — | Không có đích nào phù hợp |
| Sản phẩm theo mùa, sẽ quay lại | Giữ nguyên URL | Ghi rõ thời điểm dự kiến có lại | Giữ tín hiệu tích lũy |
| Xóa danh mục | Chuyển hướng tới danh mục cha hoặc danh mục tương đương | — | Tránh mất đường vào các sản phẩm bên trong |
Nguyên tắc với sản phẩm hết hàng tạm thời: giữ trang thay vì xóa. Việc xóa trang mỗi lần hết hàng rồi tạo lại khi có hàng làm mất toàn bộ tín hiệu tích lũy của URL đó, và với sản phẩm bán chạy thì chu kỳ này lặp lại nhiều lần.
Về việc đổi định danh sản phẩm: đây là thao tác dễ thực hiện trong trang quản trị và dễ bị làm mà không thiết lập chuyển hướng. Cần một quy tắc vận hành rõ ràng cho đội quản lý danh mục — mỗi lần đổi định danh phải kèm một chuyển hướng — và ghi vào nhật ký thay đổi.
Với các cửa hàng có nguồn cấp dữ liệu sản phẩm cho các kênh khác, cần kiểm tra tính đồng bộ: URL trong nguồn cấp dữ liệu phải khớp với URL thật trên website.
Chuyển vào hoặc ra khỏi nền tảng là dự án migration
Câu hỏi: khi chuyển cửa hàng từ nền tảng khác sang Shopify, hoặc ngược lại, cần làm gì?
Đây không phải một hạng mục trong danh sách SEO Shopify mà là một dự án riêng với quy trình riêng. Cấu trúc URL của Shopify có các phần tiền tố cố định, khác với hầu hết các nền tảng khác — nghĩa là gần như toàn bộ URL sẽ thay đổi khi chuyển sang.
Khi URL thay đổi trên diện rộng, các yêu cầu về bản đồ URL, chuyển hướng và thông báo trong Search Console theo tài liệu của Google được áp dụng đầy đủ.
Cổng kiểm soát khi chuyển nền tảng
| Giai đoạn | Việc cần làm | Điều kiện đi tiếp |
|---|---|---|
| Trước khi bắt đầu | Crawl toàn bộ website cũ, lưu lại danh sách URL, thẻ tiêu đề, thẻ mô tả, nội dung | Có bản ghi đầy đủ |
| Kiểm kê URL | Hợp nhất từ crawl, dữ liệu phân tích, Search Console và dữ liệu liên kết | Không bỏ sót URL có lưu lượng hoặc có liên kết trỏ tới |
| Lập bản đồ chuyển hướng | Mỗi URL cũ có đích cụ thể, có lý do | Nhóm URL ưu tiên cao đã mapping xong và kiểm tra thủ công |
| Chuyển nội dung | Thẻ tiêu đề, thẻ mô tả, mô tả sản phẩm chuyển sang đầy đủ | Kiểm mẫu trên nhiều loại trang |
| Kiểm tra trước phát hành | Chạy toàn bộ danh sách chuyển hướng trên môi trường thử nghiệm | Không có chuyển hướng sai đích hoặc nhiều bước |
| Ngày phát hành | Kiểm tra tệp robots, thẻ chặn lập chỉ mục, chứng chỉ | Không còn thiết lập của môi trường thử nghiệm |
| Sau phát hành | Nộp sitemap mới, giám sát theo nhóm URL | Nhóm ưu tiên cao chuyển hướng đúng |
Quy trình đầy đủ cùng các nguyên tắc về kiểm tra tương đương trang và giám sát sau launch thuộc SEO Migration.
RED không cam kết chuyển nền tảng không làm giảm lưu lượng. Tài liệu của Google nêu rõ nên dự kiến biến động tạm thời trong quá trình xử lý việc chuyển đổi. Chuẩn bị kỹ làm giảm mức độ và thời gian biến động chứ không loại bỏ nó.
Ghi nhật ký các thay đổi trong trang quản trị
Câu hỏi: ai đã xuất bản giao diện mới, cài ứng dụng, sửa cấu hình thị trường hoặc đổi định danh sản phẩm?
Trên Shopify, nhiều thay đổi có tác động lớn được thực hiện bằng vài thao tác trong trang quản trị — không qua quy trình phát hành, không có ghi chú, không ai ngoài người thực hiện biết. Xuất bản một giao diện mới thay đổi mã trên toàn bộ cửa hàng; cài một ứng dụng chèn mã vào mọi trang; đổi định danh một sản phẩm bán chạy làm URL cũ mất hiệu lực.
Nhật ký thay đổi trên nền tảng
| Loại thay đổi | Trường cần ghi | Vì sao |
|---|---|---|
| Xuất bản giao diện | Ngày, phiên bản, người thực hiện, phạm vi thay đổi | Nguyên nhân phổ biến nhất của biến động đột ngột |
| Cài hoặc gỡ ứng dụng | Ngày, tên ứng dụng, mục đích, người quyết định | Ảnh hưởng tới mọi trang |
| Thay đổi cấu hình thị trường | Ngày, thị trường nào, thay đổi gì | Ảnh hưởng tới khai báo hreflang và canonical |
| Đổi định danh sản phẩm hoặc danh mục | Ngày, URL cũ, URL mới, đã thiết lập chuyển hướng chưa | URL cũ mất hiệu lực ngay |
| Sửa tệp robots | Ngày, thay đổi gì, lý do, người phê duyệt | Có thể ảnh hưởng toàn bộ cửa hàng |
| Thay đổi cấu hình theo dõi | Ngày, thay đổi gì | Tạo đứt gãy trong dữ liệu |
| Xóa hoặc ẩn sản phẩm hàng loạt | Ngày, phạm vi, lý do | Ảnh hưởng số lượng trang được lập chỉ mục |
Cách triển khai đơn giản nhất và bền vững nhất: một bảng tính dùng chung, cập nhật ngay khi thực hiện thay đổi, với các trường tối thiểu là ngày, người thực hiện, thay đổi gì và phạm vi. Không cần công cụ phức tạp — cần kỷ luật.
Giá trị của nhật ký thể hiện rõ nhất khi có sự cố. Khi lưu lượng giảm, bước đầu tiên là mở nhật ký xem trong cửa sổ thời gian đó có gì. Không có nhật ký thì việc chẩn đoán bắt đầu bằng việc hỏi từng người xem họ đã làm gì — mất nhiều ngày và kết quả không đáng tin.
Câu hỏi thường gặp
Shopify có sẵn sitemap, thẻ canonical và tệp robots không?
Có. Tài liệu của Shopify nêu rằng nền tảng tự sinh thẻ canonical, tệp sitemap, tệp robots và chứng chỉ bảo mật. Tệp sitemap được cập nhật tự động khi có thay đổi về sản phẩm, ảnh chính, trang, danh mục và bài viết. Việc cần làm là kiểm tra các giá trị thực tế trên cửa hàng của mình — vì giao diện tùy chỉnh hoặc ứng dụng có thể làm sai lệch — chứ không phải cài thêm công cụ để làm lại những việc đã có.
Có nên sửa tệp robots không?
Chỉ khi có lý do cụ thể được ghi lại. Shopify cho phép tùy chỉnh qua một tệp mẫu, nhưng chính tài liệu của nền tảng lưu ý rằng cấu hình mặc định nhìn chung phù hợp và việc thay đổi cần có lý do. Đây là loại thay đổi có thể gây hậu quả trên diện rộng mà không tạo ra lỗi nào nhìn thấy được, nên mỗi chỉnh sửa cần ghi rõ vì sao, ai quyết định và ngày thực hiện.
Cấu hình đa thị trường có tự tạo khai báo hreflang không?
Theo tài liệu của Shopify, khi được thiết lập đúng thì nền tảng xử lý URL theo thị trường, khai báo hreflang, thẻ canonical và tệp sitemap quốc tế. Nhưng vẫn cần kiểm tra đầu ra thực tế, đặc biệt với giao diện đã tùy chỉnh nhiều hoặc khi có ứng dụng đa ngôn ngữ chạy song song — hai cơ chế cùng sinh khai báo có thể tạo ra kết quả mâu thuẫn.
Ứng dụng cài thêm có ảnh hưởng tới SEO không?
Có thể, theo nhiều cách: chèn mã làm tăng thời gian tải, khai dữ liệu có cấu trúc không khớp nội dung hiển thị, sinh URL không kiểm soát, hoặc để lại mã còn sót sau khi gỡ. Nhưng không nên kết luận một ứng dụng gây ra vấn đề khi chưa có bằng chứng. Cách xác minh là so sánh trạng thái trước và sau khi thay đổi, không phải gỡ hàng loạt dựa trên phỏng đoán.
Đổi định danh sản phẩm có cần thiết lập chuyển hướng không?
Có. Đổi định danh làm URL cũ mất hiệu lực ngay, và URL cũ có thể đang có liên kết từ bên ngoài trỏ tới hoặc đang được index. Thao tác này rất dễ thực hiện trong trang quản trị nên cũng rất dễ bị làm mà quên thiết lập chuyển hướng — cần một quy tắc vận hành rõ ràng cho đội quản lý danh mục và ghi vào nhật ký thay đổi.
Chuyển cửa hàng sang Shopify có cần quy trình migration không?
Có. Cấu trúc URL của Shopify có các phần tiền tố cố định khác với hầu hết nền tảng khác, nghĩa là gần như toàn bộ URL sẽ thay đổi. Khi URL thay đổi trên diện rộng, các yêu cầu về bản đồ URL, chuyển hướng và thông báo trong Search Console theo tài liệu của Google được áp dụng đầy đủ. Đây là một dự án riêng, không phải một hạng mục trong danh sách công việc SEO thông thường.
Gửi thông tin cửa hàng để RED đánh giá phạm vi
Nếu cửa hàng Shopify đang không có kết quả như mong đợi, hoặc doanh nghiệp đang chuẩn bị chuyển sang nền tảng này, hãy gửi cho RED:
- Địa chỉ cửa hàng và quy mô danh mục sản phẩm
- Giao diện đang dùng và danh sách các ứng dụng đã cài
- Có sử dụng cấu hình đa thị trường không, phục vụ những thị trường nào
- Quyền truy cập Search Console và công cụ phân tích, nếu chia sẻ được
- Nếu đang chuẩn bị chuyển nền tảng: website hiện tại và mốc thời gian dự kiến
RED sẽ kiểm kê những gì nền tảng đã xử lý, xác định các điểm cần can thiệp thật sự và phản hồi bằng bản mô tả phạm vi. RED không cam kết được lập chỉ mục hay có thứ hạng, không tùy chỉnh các thành phần mặc định khi không có lý do cụ thể, và không kết luận về hành vi của giao diện hoặc ứng dụng khi chưa kiểm chứng trên chính cửa hàng đó.