SEO khi thiết kế lại website: tham gia từ bản wireframe, không phải sau khi bàn giao

Có một kịch bản lặp lại đủ nhiều để trở thành khuôn mẫu. Doanh nghiệp làm lại website: giao diện đẹp hơn, tốc độ tốt hơn, cấu trúc gọn hơn, tỷ lệ hoàn tất biểu mẫu trong thử nghiệm nội bộ cao hơn. Ba tuần sau khi lên môi trường thật, lưu lượng tự nhiên giảm bốn mươi phần trăm. Không ai hiểu tại sao, vì URL không hề thay đổi.

Nguyên nhân thường không nằm ở URL. Nó nằm ở những thứ biến mất trong quá trình thiết kế lại mà không ai ghi nhận: nội dung bị cắt vì không vừa với bố cục mới, hai trăm liên kết theo ngữ cảnh trong thân bài bị bỏ khi chuyển sang hệ thống khối nội dung mới, thẻ canonical được sinh khác đi bởi template mới, dữ liệu có cấu trúc chưa được dựng lại, hoặc điều hướng mới được xây bằng JavaScript và crawler không còn nhìn thấy đường vào các trang sâu.

Phân tích ngành đầu năm 2026 chỉ ra rằng các dự án redesign thất bại chủ yếu khi chúng được coi là việc làm mới giao diện — và rằng cần có sự đồng thuận giữa các bên, có đường cơ sở, có bản crawl trước, và có quy trình kiểm tra chất lượng ở cả trước lẫn sau khi phát hành.

Trang này mô tả cách RED tham gia một dự án redesign: lập bản kiểm kê thay đổi trước khi giao diện được duyệt, đăng ký các thành phần không được mất, so sánh sơ đồ điều hướng cũ và mới, đánh giá nội dung theo hướng giữ, cải thiện, gộp hay bỏ, ghi lại các đánh đổi giữa thiết kế và tìm kiếm, nghiệm thu từng template trước launch, chuyển sang quy trình migration khi thay đổi URL vượt ngưỡng, và giám sát hồi quy theo nhóm sau launch.

Ranh giới đặt trước: RED không cam kết redesign sẽ không làm giảm lưu lượng, và không cam kết rằng giao diện mới sẽ cải thiện thứ hạng hoặc tỷ lệ chuyển đổi.

Lập bản kiểm kê thay đổi trước khi duyệt giao diện

Câu hỏi: thiết kế mới thay đổi những gì — điều hướng, URL, nội dung, cách dựng trang, template, hay cấu hình đo lường?

Câu hỏi này phải được đặt ở giai đoạn wireframe, không phải sau khi bàn giao. Đây là điểm quyết định của toàn bộ dự án, vì mọi thứ đắt tiền để sửa đều được cố định trong giai đoạn thiết kế: cấu trúc điều hướng, các loại template, cách tổ chức nội dung trên trang, và công nghệ dựng giao diện.

Khi đơn vị SEO được mời vào sau khi website đã bàn giao, những gì còn sửa được chỉ là các chi tiết bề mặt. Kết quả là bản báo cáo sau launch liệt kê hàng loạt vấn đề mà không vấn đề nào sửa được trong ngân sách còn lại.

Bản kiểm kê thay đổi của dự án redesign

Hai dòng có mức rủi ro rất cao — thay đổi URL và thay đổi nền tảng — là các dấu hiệu cho thấy dự án không còn là redesign thuần túy. Khi chúng xuất hiện, cần chuyển sang quy trình nặng hơn, và phần sau của trang này mô tả tiêu chí đó.

Nguyên tắc làm việc của RED: các mốc rà soát SEO được đặt vào ba điểm trong quy trình thiết kế — sau khi chốt sơ đồ trang và trước khi vẽ wireframe, sau khi chốt wireframe và trước khi thiết kế chi tiết, và sau khi chốt thiết kế và trước khi bắt đầu phát triển. Ba điểm này tương ứng với ba nhóm quyết định khác nhau, và mỗi nhóm càng để muộn thì càng đắt để sửa.

Phần thực hiện thiết kế và phát triển thuộc thiết kế website; vai trò của RED trong giai đoạn này là rà soát và cảnh báo, không phải quyết định thay đội thiết kế.

Đăng ký các thành phần không được mất

Câu hỏi: những thành phần nào trên trang hiện tại đang mang chức năng quan trọng và có thể biến mất mà không ai chú ý?

Sự biến mất này hầu như không bao giờ là quyết định có chủ đích. Nó xảy ra vì trong quá trình thiết kế lại, mỗi thành phần được đánh giá theo tiêu chí thẩm mỹ và trải nghiệm — và một số thành phần trông thừa theo tiêu chí đó nhưng lại đang làm việc quan trọng.

Sổ đăng ký thành phần quan trọng

Nguyên tắc cần giữ: không giữ một thành phần chỉ vì lý do SEO khi nó không còn giá trị cho người dùng. Có những khối nội dung được thêm vào từ nhiều năm trước với mục đích duy nhất là nhồi thêm chữ vào trang — chúng không nên được chuyển sang bản mới. Mỗi thành phần cần một quyết định có lý do, và lý do "vì SEO" không đủ nếu không giải thích được nó phục vụ người đọc thế nào.

Ngược lại, việc bỏ một thành phần vì nó không hợp với bố cục mới cũng cần là quyết định có ý thức, được ghi lại, chứ không phải kết quả phụ của quá trình thiết kế.

So sánh sơ đồ điều hướng cũ và mới

Câu hỏi: các trang quan trọng có bị đẩy sâu hơn, mất liên kết từ trang trung tâm, hoặc trở thành trang mồ côi không?

Đây là loại thiệt hại âm thầm nhất trong dự án redesign, vì nó không hiển thị ở đâu cả. Website mới nhìn gọn gàng hơn, menu ít mục hơn, mọi thứ trông ngăn nắp — và đúng là ngăn nắp hơn với người dùng đang biết mình tìm gì. Nhưng cấu trúc liên kết mà crawler nhìn thấy đã thay đổi hoàn toàn.

Ví dụ điển hình: menu cũ có bốn mươi mục liệt kê toàn bộ danh mục con; menu mới rút xuống sáu mục lớn với các danh mục con chỉ hiện khi rê chuột hoặc chỉ tồn tại trong trang danh mục cha. Từ góc độ trải nghiệm, đây là cải thiện. Từ góc độ cấu trúc liên kết, ba mươi tư trang vừa mất đi liên kết từ mọi trang trên website.

So sánh sơ đồ điều hướng

Cách thực hiện: chạy hai bản crawl — một trên website hiện tại, một trên môi trường thử nghiệm của bản mới — với cùng cấu hình, bắt đầu từ trang chủ, chỉ đi theo liên kết, không nạp sitemap. Sau đó so sánh danh sách URL tìm được và số liên kết trỏ tới từng URL.

Ranh giới cần giữ: không đánh giá chất lượng cấu trúc thông tin chỉ bằng độ sâu. Một trang nằm ở bước thứ tư nhưng có đường dẫn rõ ràng và được liên kết từ các trang liên quan có thể tốt hơn một trang nằm ở bước thứ hai nhưng chỉ có một liên kết duy nhất từ một menu ẩn. Độ sâu là một chỉ báo, không phải tiêu chuẩn.

Nguyên tắc làm việc: khi phát hiện một trang quan trọng mất đường vào, giải pháp không nhất thiết là đưa nó trở lại menu chính. Có thể là thêm liên kết từ trang danh mục cha, thêm khối nội dung liên quan, hoặc thiết kế lại trang trung tâm để nó thực sự liệt kê các trang con. Việc chọn giải pháp nào là quyết định chung giữa đội thiết kế và RED.

Giữ nội dung không có nghĩa sao chép nguyên website cũ

Câu hỏi: nội dung nào phải giữ, nội dung nào nên cải thiện, nội dung nào nên gộp, và nội dung nào nên bỏ?

Redesign là cơ hội tốt để dọn dẹp nội dung tích tụ qua nhiều năm. Nhưng cơ hội đó thường bị dùng sai theo một trong hai hướng: hoặc chuyển nguyên toàn bộ nội dung cũ sang bản mới mà không đánh giá gì, hoặc cắt bỏ hàng loạt vì "làm lại từ đầu cho gọn".

Hướng thứ hai nguy hiểm hơn, vì việc cắt thường được quyết định theo tiêu chí bố cục — trang nào không vừa với thiết kế mới thì bỏ — chứ không theo tiêu chí giá trị.

Ma trận đánh giá nội dung

Nguyên tắc: mọi quyết định bỏ phải dựa trên bằng chứng, không dựa trên bố cục. Trước khi cắt một trang, cần kiểm tra ba thứ: trang đó có lưu lượng tự nhiên không, có liên kết từ bên ngoài trỏ tới không, và đội bán hàng có đang dùng nó không. Một trang không có lưu lượng vẫn có thể đang mang backlink hoặc đang được gửi cho khách hàng trong quá trình tư vấn.

Về việc trình bày lại: chuyển một trang từ dạng văn bản dài sang dạng có nhiều khối trực quan là thay đổi hợp lệ và thường cải thiện trải nghiệm. Nhưng cần phân biệt giữa trình bày lại và cắt bớt. Nếu sau khi chuyển đổi, trang chỉ còn một phần ba lượng thông tin so với trước, thì đó không phải trình bày lại.

Trường hợp cần chú ý riêng: nội dung nằm trong các trang chi tiết sản phẩm hoặc dịch vụ. Khi chuyển sang một hệ thống khối nội dung mới với các trường cố định, phần mô tả tự do thường bị nén lại để vừa với cấu trúc. Cần kiểm tra mẫu trên nhiều trang thay vì chỉ xem một trang đại diện.

Thiết kế và tìm kiếm đôi khi phải đánh đổi

Câu hỏi: giao diện tối giản, nội dung ẩn trong khối gập, cuộn vô hạn, tương tác bằng JavaScript — những lựa chọn này ảnh hưởng gì?

Đây là phần cần cẩn trọng nhất về mặt phát biểu, vì thị trường có nhiều tuyên bố quá mức theo cả hai chiều: một bên nói nội dung ẩn trong khối gập không được tính, bên kia nói không sao cả.

Điều có thể nói dựa trên tài liệu chính thức: Google có tài liệu riêng về cách xử lý JavaScript, mô tả quy trình crawl, dựng trang rồi mới lập chỉ mục, cùng các điểm cần kiểm tra khi nội dung phụ thuộc vào mã JavaScript. Nguyên tắc thực dụng rút ra là kiểm tra bằng bằng chứng thay vì tranh luận: nội dung có xuất hiện trong bản HTML đã dựng hay không, liên kết có phải thẻ liên kết chuẩn có địa chỉ đích hay không.

Sổ ghi đánh đổi giữa thiết kế và tìm kiếm

Nguyên tắc: người dùng trước, sau đó kiểm tra bằng chứng. RED không đề xuất thêm chữ vào trang chỉ để có nhiều nội dung, và không phản đối một lựa chọn thiết kế chỉ vì nó khác cách làm quen thuộc. Cái RED yêu cầu là mỗi lựa chọn có rủi ro được kiểm tra trên môi trường thử nghiệm và kết quả được ghi lại.

Về việc ghi lại: khi một quyết định thiết kế được giữ dù có rủi ro về mặt tìm kiếm, quyết định đó cần được ghi vào sổ với lý do và các bên đã đồng ý. Điều này tránh việc sáu tháng sau, khi có vấn đề, cuộc thảo luận bắt đầu bằng câu hỏi ai đã quyết định điều này.

Nghiệm thu từng template trước khi phát hành

Câu hỏi: mỗi loại trang được kiểm tra theo tiêu chí nào?

Sai lầm phổ biến trong khâu kiểm tra chất lượng của dự án redesign là kiểm tra trang chủ rất kỹ và các loại trang khác qua loa. Trang chủ là trang được nhìn nhiều nhất trong quá trình thiết kế, nên nó thường ít lỗi nhất — trong khi các template phủ hàng nghìn trang lại là nơi lỗi có tác động lớn nhất.

Cổng nghiệm thu template

Nguyên tắc lấy mẫu: chọn ít nhất ba trang cho mỗi template, và chọn theo hướng đa dạng chứ không chọn trang đẹp nhất. Với template sản phẩm, nên có một sản phẩm nhiều biến thể, một sản phẩm ít thông tin, và một sản phẩm bình thường. Lỗi hệ thống thường lộ ra ở các trường hợp biên.

Ngoài ra, cần một bản crawl đầy đủ của website hiện tại được lưu trước ngày phát hành. Không có bản này thì sau launch không có gì để so sánh, và mọi tranh luận về việc "trước đây có hay không" đều thành phỏng đoán. Các tiêu chuẩn kỹ thuật áp dụng ở bước này thuộc phạm vi SEO kỹ thuật.

Khi thay đổi URL vượt ngưỡng, chuyển sang quy trình migration

Câu hỏi: khi nào một dự án redesign trở thành một dự án migration?

Đây là ranh giới cần xác định sớm, vì hai loại dự án có khối lượng công việc và mức rủi ro khác nhau đáng kể. Tài liệu của Google phân biệt rõ giữa việc chuyển website có thay đổi URL và các thay đổi khác — khi URL thay đổi, các yêu cầu về bản đồ URL, chuyển hướng và thông báo trong Search Console được áp dụng.

Quy tắc chuyển sang quy trình migration

Khi dự án vượt ngưỡng, phần việc bổ sung không nhỏ: kiểm kê toàn bộ URL từ nhiều nguồn, lập bản đồ mapping có lý do cho từng nhóm, kiểm tra tương đương giữa trang cũ và trang đích, thiết lập và kiểm thử bảng chuyển hướng, và giám sát sau launch theo nhóm URL cũ. Quy trình chi tiết thuộc SEO Migration.

Điều RED không làm: không xử lý một dự án thay đổi URL trên diện rộng bằng quy trình redesign đơn giản. Việc này thường xảy ra khi ngân sách đã cạn ở giai đoạn thiết kế và không còn chỗ cho phần migration — nhưng bỏ qua phần đó không làm rủi ro biến mất, nó chỉ chuyển rủi ro sang giai đoạn sau launch.

Giám sát hồi quy sau launch theo nhóm

Câu hỏi: template nào, thư mục nào, nhóm truy vấn nào đang mất khả năng hiển thị?

Nhìn một đường lưu lượng tổng sẽ phát hiện vấn đề muộn hàng tuần. Redesign ảnh hưởng khác nhau tới các nhóm khác nhau — một template có thể hoàn toàn ổn trong khi một template khác mất phần lớn lưu lượng — và đường tổng làm hai chuyện đó triệt tiêu lẫn nhau.

Bảng giám sát hồi quy sau redesign

Dòng về dữ liệu đo lường cần kiểm tra đầu tiên sau launch. Nếu số phiên trong công cụ phân tích giảm mạnh trong khi số nhấp trong Search Console giữ nguyên, vấn đề nằm ở mã theo dõi chứ không phải ở khả năng hiển thị — và việc này cần được loại trừ trước khi bắt đầu điều tra sâu hơn.

Nhóm đối chứng giữ cho chẩn đoán không bị lệch. Nếu các trang không nằm trong phạm vi redesign cũng giảm cùng thời điểm với biên độ tương tự, nguyên nhân có thể nằm ngoài dự án.

Về điều kiện quay lui: cần được định nghĩa trước launch với ngưỡng cụ thể và người có quyền quyết định. Với redesign giữ nguyên URL, việc quay lui thường khả thi về mặt kỹ thuật nếu bản cũ còn được giữ. Với redesign kèm thay đổi URL, quay lui phức tạp hơn nhiều và ngưỡng nên đặt cao hơn.

RED không cam kết rằng redesign sẽ không làm giảm lưu lượng. Kể cả với một dự án được chuẩn bị kỹ, việc thay đổi cấu trúc và nội dung trên diện rộng có thể dẫn tới biến động trong khi công cụ tìm kiếm xử lý các thay đổi đó.

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

Redesign website có cần SEO tham gia từ giai đoạn wireframe không?

Có, và đây là điểm quyết định của cả dự án. Những thứ đắt tiền nhất để sửa — cấu trúc điều hướng, danh sách template, cách tổ chức nội dung trên trang, công nghệ dựng giao diện — đều được cố định trong giai đoạn thiết kế. Khi đơn vị SEO được mời vào sau khi bàn giao, phần lớn vấn đề chỉ còn có thể ghi nhận chứ không sửa được trong ngân sách còn lại.

Nếu không đổi URL thì có cần quy trình migration không?

Không cần quy trình migration đầy đủ, nhưng vẫn cần kiểm soát chặt. Redesign giữ nguyên URL vẫn có thể làm mất nội dung, mất liên kết nội bộ, mất dữ liệu có cấu trúc, thay đổi thẻ canonical do template mới, hoặc làm nội dung không còn xuất hiện sau khi dựng trang. Những rủi ro này không liên quan tới URL và không được xử lý bởi bảng chuyển hướng.

Có nên giữ toàn bộ nội dung cũ không?

Không. Redesign là cơ hội tốt để dọn dẹp. Nhưng mọi quyết định bỏ phải dựa trên bằng chứng — trang đó có lưu lượng không, có backlink không, đội bán hàng có dùng không — chứ không dựa trên việc nó có vừa với bố cục mới hay không. Việc cắt nội dung theo tiêu chí thiết kế là nguyên nhân phổ biến của việc mất lưu lượng sau redesign.

Nội dung ẩn trong khối gập hoặc dùng JavaScript có ảnh hưởng không?

Cách trả lời đúng là kiểm tra thay vì tranh luận. Google có tài liệu riêng mô tả quy trình crawl, dựng trang rồi lập chỉ mục với nội dung phụ thuộc JavaScript. Điều cần xác minh trên môi trường thử nghiệm: nội dung chính có xuất hiện trong bản HTML đã dựng không, liên kết điều hướng có phải thẻ liên kết chuẩn có địa chỉ đích không, và các thẻ meta sinh bằng mã có mâu thuẫn với HTML nguồn không.

Kiểm tra chất lượng trước launch thế nào?

Theo từng template chứ không chỉ trang chủ. Mỗi loại trang cần được kiểm tra trên ít nhất ba mẫu chọn theo hướng đa dạng, với các hạng mục: thẻ robots, mã trạng thái, canonical, thẻ tiêu đề, nội dung sau khi dựng trang, liên kết nội bộ, dữ liệu có cấu trúc và cấu hình đo lường. Kèm theo là một bản crawl đầy đủ của website hiện tại được lưu trước ngày phát hành để làm cơ sở so sánh.

Redesign có cam kết không tụt lưu lượng không?

Không. Việc thay đổi cấu trúc, nội dung và cách dựng trang trên diện rộng có thể dẫn tới biến động trong khi công cụ tìm kiếm xử lý các thay đổ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ó. RED cũng không cam kết rằng giao diện mới sẽ cải thiện thứ hạng hoặc tỷ lệ chuyển đổi — hai điều đó phụ thuộc vào nhiều yếu tố nằm ngoài phạm vi thiết kế.

Gửi bản thiết kế để RED đánh giá phạm vi

Nếu doanh nghiệp đang chuẩn bị làm lại website, thời điểm hợp lý để trao đổi là trước khi chốt sơ đồ trang và wireframe. Hãy gửi cho RED:

• Website hiện tại và phạm vi dự kiến của việc thiết kế lại
• Sơ đồ trang, wireframe hoặc bản thiết kế đã có
• Có đổi URL, đổi tên miền hoặc đổi nền tảng không
• Quyền truy cập Search Console và công cụ phân tích, nếu chia sẻ được
• Đơn vị thực hiện thiết kế và phát triển, cùng mốc thời gian dự kiến

RED sẽ lập bản kiểm kê thay đổi, xác định các thành phần cần bảo toàn và các mốc rà soát cần đặt trong quy trình thiết kế, rồi phản hồi bằng bản mô tả phạm vi. RED không cam kết redesign sẽ không làm giảm lưu lượng và không cam kết giao diện mới sẽ cải thiện thứ hạng hoặc tỷ lệ chuyển đổi.