Google Search Console cho tám domain: property, bản ghi TXT, sitemap

Chiều 01/10/2026, năm landing app của mình chuyển sang domain .io.vn riêng trong cùng một buổi, và tới tối thì cả bảy app đều đã có domain. Chuyện chọn domain và trỏ về Vercel mình đã viết ở bài Chọn domain cho app indie. Bài này là phần làm ngay sau đó: đưa tất cả vào Google Search Console.

Tổng cộng tám domain: lockboxy.io.vn, linkeeper.io.vn, minivid.io.vn, ringsy.io.vn, talkzy.io.vn, baton.io.vn, stampzy.io.vn, và domain cá nhân vanthuongdao.id.vn, nơi chứa portfolio ở www., blog này ở /blog và /vi/blog, và trang showcase app ở apps.. Giờ cả tám nằm chung một tài khoản Google dưới dạng domain property, cái nào cũng đã nộp sitemap. Trên đường đi mình lỡ tay xoá mất một bản ghi xác minh, và học được bước nào đáng làm tay, bước nào không.

#Domain property hay URL-prefix property

Search Console có hai loại property, và chọn loại nào quyết định bạn nhìn thấy được bao nhiêu phần của site.

Với các site của mình thì domain property là lựa chọn hiển nhiên. Landing nào cũng redirect / sang một locale, có www bên cạnh apex, và truy cập được qua cả http lẫn https. URL-prefix property chỉ thấy một trong các biến thể đó, phần còn lại mình lại phải thêm property khác.

Domain cá nhân là chỗ thấy lợi rõ nhất. Một domain property cho vanthuongdao.id.vn phủ luôn www.vanthuongdao.id.vn (portfolio và blog) lẫn apps.vanthuongdao.id.vn (showcase). Showcase chỉ là một CNAME trên domain đó, nên không cần property hay xác minh riêng. Trang và sitemap của nó tự hiện ra dưới domain cha.

URL-prefix vẫn có chỗ dùng. Landing của Lockboxy đọc token xác minh Google từ biến môi trường cho một property dạng thẻ meta, như mình kể ở bài SEO và GEO cho landing page của app. Đó là phương án dự phòng tốt, nhưng hễ có quyền vào DNS là mình chọn domain property.

#Xác minh ở Mắt Bão, và bản ghi TXT mình lỡ xoá

Xác minh chỉ cần một bản ghi. Search Console đưa bạn một giá trị dạng google-site-verification=…, bạn thêm nó thành bản ghi TXT ở gốc domain (@). Đợi vài phút, bấm Verify. Với mấy domain .io.vn thì việc này bình thường: một token, một bản ghi, xong.

Domain cá nhân thì không mới. Zone của nó đã có sẵn một TXT trên @: token xác minh Google cũ từ hồi mình mới dựng domain. Mình thêm bản ghi mới trong bảng DNS của Mắt Bão, chọn TXT, host @, dán token mới rồi lưu. Xong xem lại zone thì token cũ đã biến mất.

Ở Mắt Bão, tạo bản ghi TXT thứ hai trên cùng một host sẽ thay luôn bản ghi đang có. Nó không thêm một bản ghi nữa bên cạnh, và cũng không cảnh báo gì. Về mặt DNS, một tên có thể có nhiều giá trị TXT, và đa số nhà đăng ký cho bạn thêm từng dòng riêng. Bảng này thì lưu chúng thành một bản ghi nhiều giá trị, và nút "thêm" sẽ ghi đè.

Cách đúng để giữ cả hai:

1. Tìm bản ghi TXT đang có trên @ và sửa nó.
2. Dùng "+ Thêm giá trị" để thêm token mới thành giá trị thứ hai của cùng bản ghi đó.
3. Lưu, rồi kiểm tra cả hai giá trị đều đã được publish.

# Mọi giá trị TXT trên apex: phải thấy đủ cả hai token
dig +short TXT vanthuongdao.id.vn

Trường hợp của mình thì thiệt hại có giới hạn. Token cũ thuộc về một lần xác minh trước đó, và mình xác minh lại domain bằng tài khoản giờ đang giữ cả tám property. Nhưng TXT trên @ cũng là chỗ đặt bản ghi SPF cho email, và chỗ các dịch vụ khác đặt token xác minh của họ. Ghi đè kiểu đó làm hỏng những thứ chẳng liên quan gì tới Search Console, mà không có gì báo cho bạn biết. Nếu bảng DNS ở nhà đăng ký của bạn trông giống vậy, lưu xong là chạy dig ngay.

Xác minh xong cũng đừng xoá bản ghi Google. Google thỉnh thoảng kiểm lại, và property nào mất bản ghi thì cũng mất luôn trạng thái đã xác minh.

#Sitemap: mỗi site một cái, nộp sau khi deploy đã lên

Mỗi landing là một app Next.js có sitemap.ts, phục vụ ở /sitemap.xml. Nó liệt kê mọi trang được index ở cả hai ngôn ngữ kèm hreflang. Sitemap của portfolio có mọi bài blog bằng tiếng Anh và tiếng Việt, kèm entry ảnh cho ảnh bìa. Vậy site nào cũng có sitemap riêng, còn domain cá nhân có hai, mỗi host một cái:

https://lockboxy.io.vn/sitemap.xml
https://minivid.io.vn/sitemap.xml
…
https://www.vanthuongdao.id.vn/sitemap.xml
https://apps.vanthuongdao.id.vn/sitemap.xml   # cùng domain property

Sitemap của showcase nộp vào property vanthuongdao.id.vn. Domain property nhận sitemap từ bất kỳ subdomain nào của nó.

Thứ tự quan trọng hơn mình tưởng. Search Console sẽ thử tải sitemap khá sớm sau khi bạn nộp. Nếu site trên domain đó chưa lên, vì DNS còn đang lan, chứng chỉ chưa được cấp, hay bản deploy với SITE_URL mới chưa xong, thì lần tải đầu fail, và sitemap bị đánh dấu "Couldn't fetch". Không phải vĩnh viễn, nhưng giờ bạn phải chờ Google thử lại chứ không còn chờ deploy của chính mình.

Có một cách sai rất âm thầm. Project Vercel của landing Minivid không gắn Git, nên push lên main không deploy gì cả. Production phải chạy vercel --prod từ repo. Giả sử mình push thay đổi domain rồi đi thẳng vào Search Console, sitemap sẽ do bản deploy cũ phục vụ, với URL trên host cũ.

Nên trước khi nộp, mình kiểm tra sitemap đã chạy trên domain mới và liệt kê đúng domain mới:

curl -sI https://minivid.io.vn/sitemap.xml | head -1   # HTTP/2 200
curl -s https://minivid.io.vn/sitemap.xml | grep -o '<loc>[^<]*' | head -3

Ra 200, và các entry <loc> bắt đầu bằng https://minivid.io.vn. Rồi mới nộp.

#Không cần request indexing cho từng trang

Property mới xác minh xong, rất dễ bị cám dỗ mở URL Inspection và bấm "Request indexing" cho từng trang một. Với một site đã có sitemap chạy đúng, việc đó phần lớn là công cốc.

Hạn mức yêu cầu thủ công khá nhỏ, khoảng mười lần mỗi ngày cho một property. Quan trọng hơn, sitemap đã báo cho Google mọi trang, còn link nội bộ cho Google biết trang nào quan trọng: trang chủ của mỗi landing link tới guide, FAQ và các trang pháp lý, còn showcase link tới cả bảy landing. Hai tín hiệu đó là cách Google tìm và crawl lại một site theo nhịp bình thường.

Mình chỉ dùng yêu cầu thủ công cho:

• Trang chủ của site vừa đổi domain, để Google sớm thấy host canonical mới.
• Một hai trang chính vừa thay đổi lớn, như một guide được viết lại.
• Kiểm tra một bản sửa. Live test của URL Inspection cho thấy Google đang thấy gì ngay lúc này. Đó là công cụ cho một thay đổi kiểu bản sửa hreflang x-default ở landing Lockboxy, khi câu hỏi là Google giờ đã đọc trang đúng ý mình chưa.

Mọi thứ khác để sitemap lo. Một trang vài tuần mà vẫn chưa được index thì vấn đề thường nằm ở chính trang đó (nội dung mỏng, canonical sai, dính noindex), và request indexing thêm lần nữa cũng không đổi được gì.

#Rút ra

• Có quyền vào DNS thì dùng domain property. Một bản ghi TXT phủ apex, www, mọi subdomain và cả hai giao thức, nên subdomain như apps. không cần property riêng.
• Ở Mắt Bão, thêm TXT mới trên @ sẽ thay bản ghi đang có. Hãy sửa bản ghi cũ và dùng "+ Thêm giá trị". Kiểm bằng dig +short TXT <domain> sau mỗi lần đổi.
• Xác minh xong vẫn giữ bản ghi TXT của Google, và để ý SPF cùng các token xác minh khác cũng nằm trên @.
• Nộp từng sitemap sau khi deploy đã chạy trên domain mới. Kiểm 200 và đúng host trong <loc> trước, nhất là với project không tự deploy khi push.
• Domain property nhận sitemap từ các subdomain của nó, nên sitemap của subdomain cứ nộp vào đó.
• Đừng request indexing cho từng trang. Sitemap và link nội bộ làm việc đó rồi. Để dành khoảng 10 lượt mỗi ngày cho trang chủ, thay đổi quan trọng và kiểm tra bản sửa.

Cả tám site đều bắt đầu từ apps.vanthuongdao.id.vn.