Dịch vụ SEO cho website mới: dựng kiến trúc tìm kiếm trước khi dựng giao diện

Website mới có một lợi thế mà không dự án nào khác có được: chưa có gì để sửa. Không có URL cũ phải giữ, không có template kế thừa, không có bảy năm nội dung chồng chéo, không có nợ kỹ thuật tích lũy qua bốn đời agency. Toàn bộ kiến trúc có thể được dựng đúng ngay từ đầu.

Đồng thời nó có một bất lợi mà các website đang chạy không gặp: không có dữ liệu thật. Không có báo cáo truy vấn trong Search Console, không có lịch sử chuyển đổi, không có bằng chứng nào cho biết khách hàng của doanh nghiệp thực sự gõ gì. Mọi quyết định ban đầu đều dựa trên ước lượng và suy luận, và điều nguy hiểm là các ước lượng đó thường được trình bày như sự thật.

Trang này mô tả cách RED xử lý cả hai mặt: khai thác lợi thế kiến trúc bằng cách đưa SEO vào giai đoạn trước wireframe thay vì sau khi bàn giao, và kiểm soát bất lợi dữ liệu bằng một sổ giả định ghi rõ mức tin cậy của từng phán đoán cùng kế hoạch thay thế chúng bằng dữ liệu thật.

Một ranh giới đặt trước. Tài liệu Search Essentials của Google mô tả các yêu cầu kỹ thuật, chính sách chống spam và các thực hành hướng tới người dùng — kèm ghi chú rằng đáp ứng chúng không bảo đảm website sẽ được đưa vào kết quả tìm kiếm. Tài liệu hướng dẫn đưa website lên Google cũng nói Google thường tự tìm thấy website, còn Search Console và sitemap là công cụ hỗ trợ khâu phát hiện và theo dõi, không phải cơ chế bảo đảm. Vì vậy RED không cam kết website mới được index trong bao nhiêu giờ, không cam kết có lưu lượng sau bao nhiêu tuần, và không đưa ra dự báo doanh thu từ kênh tìm kiếm cho một website chưa có dữ liệu nào.

SEO phải vào trước sitemap thiết kế, không phải sau khi bàn giao

Câu hỏi mở đầu: nhu cầu tìm kiếm và cách doanh nghiệp phân loại sản phẩm dịch vụ ảnh hưởng thế nào đến cấu trúc điều hướng và bản wireframe?

Trình tự phổ biến trong các dự án website là: doanh nghiệp chốt sitemap thiết kế với đơn vị thiết kế, dựng giao diện, phát triển, bàn giao, rồi mới mời một đơn vị SEO vào "tối ưu". Đến lúc đó, những thứ quan trọng nhất đã cố định: có bao nhiêu tầng danh mục, trang dịch vụ nằm ở đâu trong cây, URL sinh theo quy tắc gì, template nào tồn tại. Đơn vị SEO chỉ còn chỉnh được thẻ tiêu đề và viết thêm nội dung — hai thứ ít giá trị nhất trong danh sách.

Chi phí sửa kiến trúc sau khi đã phát triển cao hơn nhiều lần chi phí thiết kế nó đúng ngay từ đầu, và trong nhiều trường hợp doanh nghiệp chọn không sửa vì đã hết ngân sách. Kết quả là website vận hành nhiều năm với một cấu trúc không phục vụ cách người dùng thực sự tìm kiếm.

Bản thiết kế kiến trúc tìm kiếm

Quy tắc URL cần chốt trước khi dev bắt đầu

Tài liệu của Google về cấu trúc URL nêu rằng URL dễ đọc và có logic giúp việc quản lý website và giúp crawl hiệu quả hơn, đồng thời khuyên tránh các mẫu URL phức tạp không cần thiết. Điều tài liệu không nói: URL tự nó không tạo ra thứ hạng. Đặt từ khóa vào slug không phải là một chiến thuật xếp hạng.

Giá trị thật của việc chốt quy tắc URL sớm nằm ở chỗ khác. Nó quyết định URL có ổn định qua các lần thay đổi nội dung không, có sinh trùng lặp khi thêm bộ lọc không, có phải sửa hàng loạt khi mở rộng danh mục không. Ba câu hỏi cần chốt với đội phát triển trước khi viết dòng code đầu tiên: slug sinh tự động từ tiêu đề hay đặt thủ công, có nhúng ID hoặc mã sản phẩm không, và tham số lọc sinh URL riêng hay giữ nguyên URL gốc.

Ranh giới cần giữ

Không để danh sách từ khóa quyết định trải nghiệm một cách máy móc. Có một kiểu sai phổ biến: lấy bảng từ khóa, mỗi từ khóa thành một mục menu, kết quả là điều hướng có hai mươi mục trong đó mười lăm mục là biến thể cách gọi của cùng một thứ. Người dùng không phân biệt được, còn website thì tự tạo trùng lặp nội bộ.

Dữ liệu tìm kiếm cho biết người ta dùng từ nào và quan tâm điều gì. Nó không thay thế được logic sản phẩm và không thay thế được nguyên tắc thiết kế điều hướng. Kiến trúc tốt là chỗ giao giữa cách doanh nghiệp tổ chức sản phẩm, cách người mua nghĩ, và cách người ta gõ vào ô tìm kiếm. Phần nghiên cứu để xác định nhóm nhu cầu và ngôn ngữ khách hàng nằm ở nghiên cứu từ khóa; phần triển khai giao diện và phát triển thuộc thiết kế website.

Launch cần một bộ trang tối thiểu, không cần một thư viện nội dung

Câu hỏi: trang nào bắt buộc phải có trước ngày go-live, và trang nào có thể phát triển dần sau đó?

Có hai thái cực đều sai. Thái cực thứ nhất là launch với một trang chủ và trang liên hệ, coi phần còn lại là việc của giai đoạn sau — website tồn tại nhưng không có gì để được tìm thấy. Thái cực thứ hai là cố xuất bản hàng trăm trang trước ngày launch để "phủ từ khóa", trong đó phần lớn là trang mỏng viết vội cho đủ số lượng.

Thái cực thứ hai nguy hiểm hơn vì nó tốn kém và phản tác dụng. Tài liệu của Google về tạo nội dung hữu ích mô tả hướng tiếp cận đặt người dùng làm trung tâm, có mục đích rõ ràng, có bằng chứng gốc và nguồn dẫn minh bạch. Đây không phải công thức về số lượng chữ hay số lượng bài. Một website mới xuất bản ba trăm trang mỏng đang tự tạo cho mình một khối nội dung phải dọn dẹp về sau, chứ không tạo được lợi thế nào.

Bộ trang tối thiểu để launch

Cách chọn nội dung hỗ trợ cho giai đoạn đầu

Khi chưa có dữ liệu truy vấn, nguồn tốt nhất không phải công cụ nghiên cứu từ khóa mà là đội bán hàng và đội chăm sóc khách hàng. Họ nghe những câu hỏi thật, bằng ngôn ngữ thật, từ những người thật sự đang cân nhắc mua. Một buổi làm việc hai giờ với đội bán hàng thường cho ra danh sách câu hỏi hữu ích hơn nhiều so với một bảng từ khóa xuất từ công cụ.

Cách làm: ghi lại các câu hỏi lặp lại, nhóm theo giai đoạn quyết định, chọn ra nhóm có tần suất cao nhất, viết mỗi nhóm thành một trang có nội dung đủ để trả lời trọn vẹn. Số lượng ít nhưng mỗi trang giải quyết được một việc cụ thể — đây là cách xây nền tốt hơn nhiều so với xuất bản đại trà.

Nguyên tắc không thỏa hiệp: không tạo trang trống hoặc trang chỉ có tiêu đề và vài dòng để "giữ chỗ URL". Trang giữ chỗ không giữ được gì cả, và nếu số lượng lớn thì chúng làm loãng chính website vừa dựng.

Template cần tiêu chí nghiệm thu trước khi nhập nội dung

Câu hỏi: thẻ tiêu đề, thẻ H1, canonical, đường dẫn phân cấp, dữ liệu có cấu trúc, hình ảnh và liên kết nội bộ được kiểm soát ở cấp nào?

Ở cấp template, không phải ở cấp từng trang. Đây là điểm khác biệt lớn nhất giữa dự án website mới và dự án tối ưu website đang chạy. Với website đang chạy, thường phải sửa từng trang vì template đã cố định. Với website mới, mỗi template được nghiệm thu đúng một lần và mọi trang sinh ra từ nó đều đúng theo.

Nếu bỏ qua bước này, hậu quả xuất hiện muộn: sau khi nhập nội dung cho ba nghìn sản phẩm mới phát hiện template sản phẩm sinh thẻ tiêu đề trùng nhau, hoặc đường dẫn phân cấp trỏ sai, hoặc mỗi biến thể sản phẩm sinh một URL riêng với canonical tự trỏ. Lúc đó chi phí sửa gấp nhiều lần.

Tiêu chí nghiệm thu template

Về dữ liệu có cấu trúc, cần giữ một giới hạn: chỉ khai loại tương ứng với nội dung thật sự có trên trang. Khai đánh dấu đánh giá khi trang chưa có đánh giá nào, hoặc khai đánh dấu sự kiện trên trang không phải sự kiện, là vi phạm hướng dẫn về dữ liệu có cấu trúc chứ không phải mẹo tối ưu. Danh sách loại đánh dấu áp dụng cho từng template cần được chốt dựa trên nội dung thực tế, không dựa trên mong muốn có kết quả hiển thị nổi bật.

Toàn bộ nhóm tiêu chí về canonical, thẻ robots, mã trạng thái và khả năng dựng nội dung thuộc phạm vi SEO kỹ thuật, được áp dụng ở giai đoạn trước launch thay vì giai đoạn khắc phục.

Website mới phải quản lý giả định như quản lý rủi ro

Câu hỏi: khi chưa có báo cáo truy vấn, chưa có lịch sử chuyển đổi, chưa có bất kỳ dữ liệu bên thứ nhất nào — những gì trong kế hoạch là sự thật và những gì là phán đoán?

Đây là phần bị bỏ qua trong hầu hết đề xuất dịch vụ SEO cho website mới. Bảng từ khóa được trình bày với cột lượng tìm kiếm và cột độ khó, nhìn như dữ liệu chắc chắn. Thực tế các con số đó là ước lượng của công cụ, xây trên mô hình riêng của từng nhà cung cấp, và có thể lệch đáng kể so với lưu lượng thật — đặc biệt với thị trường tiếng Việt và với các truy vấn ngách.

RED không loại bỏ các con số này khỏi quá trình lập kế hoạch. Chúng vẫn hữu ích để so sánh tương đối giữa các nhóm chủ đề. Nhưng chúng phải được ghi đúng tên: ước lượng của công cụ, không phải nhu cầu đã xác minh.

Sổ giả định của website mới

Cách dùng bảng này trong vận hành: mỗi giả định mức tin cậy thấp hoặc trung bình cần một điều kiện kiểm chứng và một mốc thời gian xem lại. Sau mốc đó, hoặc dữ liệu xác nhận và giả định được nâng lên thành dữ kiện, hoặc dữ liệu bác bỏ và kế hoạch được điều chỉnh. Cái không chấp nhận được là một giả định nằm im trong kế hoạch suốt hai năm mà không ai kiểm tra lại.

Bảng này cũng là công cụ giao tiếp với ban lãnh đạo. Khi trình bày kế hoạch, việc phân biệt rõ đâu là dữ kiện, đâu là ước lượng và đâu là suy luận giúp kỳ vọng được đặt đúng ngay từ đầu — thay vì tạo cảm giác chắc chắn giả rồi phải giải thích về sau.

Mô phỏng crawl trước khi launch

Câu hỏi: từ trang chủ, một crawler có đi tới được mọi trang quan trọng không, và đi qua bao nhiêu bước?

Không thể trả lời câu này bằng cách nhìn sitemap. Sitemap liệt kê URL mà website muốn được biết đến; nó không phản ánh cấu trúc liên kết thật. Một trang có trong sitemap nhưng không có liên kết nội bộ nào trỏ tới vẫn là trang mồ côi, và mồ côi ngay từ ngày đầu tiên là tình huống hoàn toàn có thể tránh được ở dự án website mới.

Cách kiểm tra là chạy crawl trên môi trường thử nghiệm, bắt đầu từ trang chủ, chỉ đi theo liên kết — không nạp sitemap.

Mô phỏng crawl trước launch

Bẫy crawl là rủi ro đáng chú ý với website thương mại điện tử và website có bộ lọc. Một danh mục có sáu bộ lọc, mỗi bộ ba giá trị, nếu mỗi tổ hợp sinh một URL riêng có thể lập chỉ mục thì một danh mục thật sinh ra hàng trăm URL. Website mới có thể ngăn chuyện này ngay từ khâu thiết kế — bằng cách quyết định trước tổ hợp nào sinh URL riêng, tổ hợp nào chỉ thay đổi hiển thị mà không đổi URL, và tổ hợp nào có URL riêng nhưng không cho index.

Trường hợp điều hướng phụ thuộc JavaScript cần lưu ý riêng. Nếu chênh lệch giữa crawl có dựng trang và crawl không dựng trang lớn, nghĩa là phần lớn cấu trúc liên kết chỉ tồn tại sau khi mã JavaScript chạy. Điều này không tự động là lỗi, nhưng cần xử lý ở khâu thiết kế thay vì phát hiện sau launch.

Khả năng lập chỉ mục và hệ đo lường phải kiểm cùng lúc

Câu hỏi: launch mà đo sai thì lấy gì làm đường cơ sở cho toàn bộ giai đoạn sau?

Đây là lỗi có hậu quả không đảo ngược được. Một trang bị noindex nhầm có thể sửa trong một giờ và trạng thái sẽ được cập nhật lại. Một tháng dữ liệu bị mất vì mã đo lường cài sai thì không có cách nào lấy lại. Với website mới, tháng đầu tiên chính là đường cơ sở cho mọi so sánh về sau.

Vì vậy hai nhóm kiểm tra này phải nằm trong cùng một danh sách go-live, không tách thành hai giai đoạn.

Bộ kiểm tra đường cơ sở ngày launch

Mục cuối cùng thường bị bỏ vì nó không mang lại lợi ích tức thì. Ba tháng sau, khi cần biết một cấu hình có tồn tại từ ngày đầu hay được thêm vào sau, bản ghi này là thứ duy nhất trả lời được.

Về kỳ vọng thời gian: tài liệu của Google nói Google thường tự phát hiện website và các công cụ như Search Console, sitemap hỗ trợ khâu phát hiện — không nói sau bao lâu. RED không đưa ra con số giờ hay ngày cho việc website mới được index, vì con số đó không nằm trong quyền kiểm soát của bên triển khai và phụ thuộc nhiều yếu tố không quan sát được.

Ba tháng đầu là vòng học, không phải giai đoạn chứng minh kết quả

Câu hỏi: dữ liệu đầu tiên dùng để làm gì?

Để thay thế các giả định trong sổ đã lập, không để chứng minh dự án thành công hay thất bại. Đây là điểm cần thống nhất với ban lãnh đạo từ đầu, vì áp lực báo cáo kết quả trong quý đầu tiên thường dẫn đến hai phản ứng sai: hoặc đảo hướng chiến lược dựa trên vài chục lượt hiển thị, hoặc trình bày các con số nhỏ như bằng chứng của xu hướng lớn.

Dữ liệu của ba tháng đầu có đặc điểm là ít và nhiễu. Một truy vấn có ba lượt nhấp trong tháng không nói lên điều gì về nhu cầu thật của thị trường. Cần đủ khối lượng trước khi rút kết luận, và với website ngách thì khối lượng đó có thể mất nhiều hơn ba tháng để tích lũy.

Vòng học từ dữ liệu đầu tiên

Nhịp làm việc phù hợp cho giai đoạn này: xem dữ liệu hàng tuần để phát hiện sự cố kỹ thuật, nhưng chỉ điều chỉnh chiến lược theo chu kỳ dài hơn khi đã có đủ khối lượng. Sự cố kỹ thuật — một nhóm URL rơi khỏi chỉ mục, một template lỗi — cần phản ứng nhanh. Câu hỏi chiến lược — nên đầu tư vào nhóm chủ đề nào — cần kiên nhẫn.

RED không đưa ra dự báo lưu lượng hoặc số lượng khách hàng tiềm năng cho website mới ở giai đoạn này, vì bất kỳ con số nào được đưa ra khi chưa có dữ liệu đều là suy đoán được trình bày dưới dạng cam kết.

Ranh giới với migration và với dự án thiết kế lại

Ba loại dự án hay bị gọi lẫn nhau. Website mới là website chưa có lịch sử trên công cụ tìm kiếm — không có URL cũ, không có tín hiệu tích lũy, không có gì phải chuyển. SEO Migration xử lý website đang có lịch sử và đang đổi URL, tên miền hoặc nền tảng, với phần việc nặng nhất là mapping và bảo toàn tín hiệu. Dự án thiết kế lại xử lý website đang chạy thay đổi giao diện và điều hướng, có thể giữ nguyên URL.

Trường hợp ranh giới hay gặp: doanh nghiệp có một website cũ gần như không có lưu lượng và muốn làm lại từ đầu trên tên miền mới. Đây không hoàn toàn là website mới, vì vẫn cần kiểm tra tên miền cũ có URL nào đang được index hoặc có backlink không. RED xử lý bằng một bước kiểm tra ngắn trước khi quyết định áp dụng quy trình nào — nếu tên miền cũ không có gì đáng chuyển thì làm theo hướng website mới, nếu có thì bổ sung phần mapping.

Về phạm vi trách nhiệm: RED làm phần kiến trúc tìm kiếm, tiêu chí nghiệm thu template, kiểm tra trước launch và giám sát sau launch. Phần thiết kế giao diện, phát triển và deploy do đội phát triển của doanh nghiệp hoặc đơn vị thiết kế website thực hiện — [CẦN RED XÁC NHẬN] phạm vi thực thi kỹ thuật và sản xuất nội dung mà RED nhận trực tiếp.

Câu hỏi thường gặp

SEO nên làm trước hay sau khi thiết kế website?

Trước. Cụ thể là trước khi chốt sitemap thiết kế và bản wireframe. Những thứ ảnh hưởng lớn nhất — cấu trúc điều hướng, cách phân loại danh mục, quy tắc sinh URL, danh sách template cần có — đều được cố định trong giai đoạn này. Mời đơn vị SEO vào sau khi bàn giao thì phần lớn quyết định quan trọng đã không thể thay đổi mà không phát sinh chi phí lớn.

Website mới cần bao nhiêu trang để launch?

Không có con số chung. Nguyên tắc là đủ để phục vụ các dòng doanh thu chính và trả lời các câu hỏi chặn quyết định mua, không phải đủ để "phủ từ khóa". Với phần lớn website dịch vụ, bộ tối thiểu gồm trang chủ, các trang dịch vụ chính, trang giới thiệu, trang liên hệ và một nhóm nhỏ nội dung hỗ trợ được chọn theo mức độ được hỏi nhiều. Website thương mại điện tử cần thêm toàn bộ trang sản phẩm và danh mục.

Có cần xuất bản nhiều bài viết ngay không?

Không. Xuất bản hàng loạt nội dung mỏng để tăng số lượng trang tạo ra một khối phải dọn dẹp về sau chứ không tạo lợi thế. Tài liệu của Google về nội dung hữu ích nhấn mạnh mục đích phục vụ người dùng, tính nguyên bản và nguồn dẫn rõ ràng — không đưa ra công thức về số lượng. Cách hiệu quả hơn là xuất bản ít, chất lượng đủ để trả lời trọn vẹn một nhu cầu, rồi mở rộng theo dữ liệu truy vấn thật sau khi launch.

Bao lâu thì Google index website mới?

Không có mốc thời gian chuẩn. Tài liệu của Google nói Google thường tự tìm thấy website, và Search Console cùng sitemap là công cụ hỗ trợ khâu phát hiện và theo dõi — nhưng không bảo đảm thời điểm crawl hay index. Bất kỳ cam kết cụ thể nào về số giờ hoặc số ngày đều không có cơ sở từ tài liệu chính thức.

Website mới có cần sitemap và Search Console không?

Cần, nhưng cần hiểu đúng vai trò. Sitemap giúp Google phát hiện URL, đặc biệt hữu ích với website mới vốn có ít liên kết từ bên ngoài. Search Console cung cấp dữ liệu để theo dõi trạng thái crawl, index và hiệu quả — đây là nguồn dữ liệu bên thứ nhất duy nhất về cách website xuất hiện trên tìm kiếm. Cả hai đều là công cụ hỗ trợ và theo dõi, không phải cơ chế bảo đảm được index.

Dự án này khác SEO Migration ở điểm nào?

Website mới không có URL cũ, không có tín hiệu tích lũy và không có dữ liệu lịch sử — nên không có phần mapping và bảo toàn tín hiệu, nhưng có thêm phần quản lý giả định vì mọi quyết định ban đầu đều dựa trên ước lượng. Migration thì ngược lại: có dữ liệu lịch sử để dựa vào, nhưng phần việc nặng nhất là chuyển tín hiệu từ cấu trúc cũ sang cấu trúc mới mà không mất mát.

Gửi kế hoạch website để RED đánh giá phạm vi

Nếu doanh nghiệp đang chuẩn bị xây website mới, thời điểm hợp lý để trao đổi là trước khi chốt sitemap thiết kế. Hãy gửi cho RED:

• Danh mục sản phẩm hoặc dịch vụ và các dòng doanh thu chính
• Đối tượng khách hàng và thị trường mục tiêu
• Bản sitemap thiết kế dự kiến hoặc bản wireframe, nếu đã có
• Nền tảng dự kiến và thông tin về đội phát triển
• Mốc thời gian go-live dự kiến

RED sẽ đánh giá kiến trúc tìm kiếm cần thiết, bộ trang tối thiểu cho launch và phạm vi kiểm soát kỹ thuật phù hợp với quy mô dự án, rồi phản hồi bằng bản mô tả phạm vi công việc. RED không cam kết thời gian được index, không cam kết mức lưu lượng và không đưa ra dự báo doanh thu cho website chưa có dữ liệu.