Quảng cáo Google bị từ chối vì lỗi trang đích khi đích quảng cáo không hoạt động đúng cách hoặc Google AdsBot nhận mã lỗi lúc truy cập. Trang vẫn mở được trên máy của người quản trị không có nghĩa URL đã hợp lệ trên mọi thiết bị, khu vực và chuỗi theo dõi. Cách xử lý đúng là ghi lại nhãn từ chối, kiểm tra URL mở rộng, xác định lỗi HTTP/DNS/redirect/AdsBot, sửa đúng đầu mối rồi mới gửi xét duyệt.
Ai cần xử lý quảng cáo Google bị từ chối vì trang đích?
Bài này dành cho người quản trị Google Ads, marketing in-house, chủ website và kỹ thuật viên phụ trách hosting, CDN hoặc tracking. Mục tiêu là giúp bốn vai trò cùng nhìn một chuỗi bằng chứng, thay vì người chạy quảng cáo chỉ thử sửa URL còn kỹ thuật chỉ trả lời “trang vẫn vào bình thường”.
Nếu tài khoản hiện trạng thái tạm ngưng cấp tài khoản, hãy chuyển sang quy trình tài khoản Google Ads bị tạm ngưng. Nếu nhãn cảnh báo nằm ở một giao dịch, bài thanh toán Google Ads bị từ chối mới là URL sở hữu. Bài hiện tại chỉ đi sâu khi lý do từ chối gắn với đích đến, URL hoặc khả năng thu thập dữ liệu.
Thuê tài khoản không phải cách sửa lỗi trang đích. Hãy chỉ xem phạm vi thuê tài khoản Google Ads Invoice khi bằng chứng cho thấy nhu cầu thực sự nằm ở hạn mức, thanh toán theo kỳ, đối soát hay quyền truy cập. Không dùng tài khoản khác để né một website hoặc đích đến chưa tuân thủ.
Phân biệt sáu nhóm lỗi đích đến trước khi sửa
“Trang đích không hoạt động” chỉ là một nhánh trong Yêu cầu đối với đích đến của quảng cáo. Google hiện tách các nhãn như đích đến không hoạt động, không khớp, không thể thu thập thông tin, không thể truy cập, trải nghiệm đích đến và không đủ nội dung gốc. Mỗi nhãn cần một đầu mối và loại bằng chứng khác nhau.
| Nhãn quan sát | Dấu hiệu chính | Đầu mối đầu tiên | Không nên làm |
|---|---|---|---|
| Đích đến không hoạt động | 4xx, 5xx, DNS, timeout, redirect lỗi hoặc trang yêu cầu xác thực | Website, hosting, CDN/WAF | Chỉ mở URL trên một máy rồi kết luận đã ổn |
| Đích đến không khớp | URL hiển thị, URL cuối cùng hoặc chuỗi redirect khác miền/nội dung | Google Ads + tracking + web | Rút gọn URL hoặc thêm redirect chéo miền |
| Không thể thu thập thông tin | AdsBot bị chặn hoặc tốc độ crawl bị hạn chế | Robots, CDN, firewall, security plugin | Tắt toàn bộ bảo mật trên production |
| Không thể truy cập | URL không truy cập được từ một khu vực/thiết bị hoặc bị giới hạn quyền | Hosting, CDN, geo rule, authentication | Chỉ test từ mạng văn phòng |
| Trải nghiệm đích đến | Trang khó điều hướng, bị che hoặc không hoàn thành được thao tác chính | UX, nội dung, web | Chỉ đổi mẫu quảng cáo |
| Không đủ nội dung gốc | Trang cầu nối, sao chép hoặc không thêm giá trị độc lập | Chủ sản phẩm, biên tập, pháp lý | Thêm vài đoạn chung chung để xin duyệt |
Trong Google Ads, hãy mở chi tiết trạng thái của chính quảng cáo hoặc thành phần bị từ chối. Ghi nguyên văn nhãn, URL liên quan, thời điểm phát hiện và phạm vi ảnh hưởng. Nếu nhiều quảng cáo cùng dùng một domain bị lỗi, ưu tiên kiểm tra hạ tầng chung trước khi sửa từng mẫu.
URL mở rộng mới là đích cần kiểm tra
URL người quản trị nhìn thấy trong trường URL cuối cùng có thể chưa phải URL mà Google thực sự kiểm tra. Theo Google, URL mở rộng là kết quả kết hợp URL cuối cùng với mẫu theo dõi và các tham số áp dụng. Chỉ cần một tham số sai, redirect JavaScript, tracker hết hạn hoặc quy tắc chuyển miền khác là URL mở rộng có thể hỏng trong khi URL gốc vẫn mở.
Công cụ Kiểm tra trang đích của Google Ads có thể dùng ở cấp chiến dịch, nhóm quảng cáo, quảng cáo/thành phần hoặc từ khoá. Tuy nhiên, Google cũng nêu công cụ này không kiểm tra hành vi vi phạm chính sách, không hỗ trợ mọi redirect JavaScript và không phát hiện tất cả lỗi parallel tracking. Kết quả “Tìm thấy trang” vì thế chưa đủ để kết luận tuân thủ.
Nếu chiến dịch đang dùng Final URL expansion trong AI Max, danh sách trang có thể rộng hơn URL đã ghim trong một mẫu quảng cáo. Khi đó, hãy đối chiếu phạm vi trong bài AI Max cho chiến dịch Search và kiểm tra page feed/URL exclusion nếu có. Đừng sửa một URL duy nhất trong khi hệ thống vẫn được phép chọn những trang cũ hoặc trang lỗi khác.
Chẩn đoán trang đích không hoạt động theo 8 bước
Quy trình nên đi từ bằng chứng Google Ads sang URL mở rộng, hạ tầng, khả năng thu thập dữ liệu và trải nghiệm thật. Trật tự này giúp giữ nguyên dấu vết ban đầu và giao việc đúng người. Nếu sửa nhiều lớp cùng lúc, đội ngũ khó biết thay đổi nào thực sự xử lý lỗi.
Bước 1: ghi nguyên văn nhãn từ chối
Chụp trạng thái của quảng cáo/thành phần, lý do chi tiết, URL bị nêu, mã khách hàng, chiến dịch, thời gian và phạm vi. Phân biệt “không hoạt động” với “không khớp” hoặc “không thể thu thập thông tin”. Nếu giao việc cho kỹ thuật, gửi đúng nhãn thay vì chỉ nói “Google không duyệt website”.
Bước 2: lấy URL mở rộng và chuỗi redirect
Dùng chức năng Test trong các lựa chọn URL để xem URL mở rộng. Ghi URL cuối cùng, mẫu theo dõi, tham số tùy chỉnh, ValueTrack, redirect trung gian và domain cuối. Nếu chỉ một cấp bị lỗi, kiểm tra override ở từ khoá, sitelink hoặc quảng cáo trước khi sửa template toàn tài khoản.
Bước 3: kiểm tra HTTP, DNS, TLS và redirect
Yêu cầu kỹ thuật kiểm tra cả phản hồi ban đầu lẫn trang sau redirect. Một URL có thể trả 301 rồi đi vào 404, lặp redirect, timeout, lỗi chứng chỉ TLS hoặc phân giải DNS khác theo khu vực. Google liệt kê 403, 404 và 500 là ví dụ không được chấp nhận; mục tiêu cuối là nội dung hợp lệ trả 200, không phải ép mọi URL hỏng trả 200.
Bước 4: kiểm tra AdsBot, robots và tường lửa
Rà quy tắc cho AdsBot-Google và AdsBot-Google-Mobile, plugin bảo mật, chống bot, giới hạn tần suất và thử thách JavaScript. Kiểm tra thêm lệnh chặn trung tâm dữ liệu, chặn khu vực và quy tắc theo user-agent. Tài liệu về trình thu thập đặc biệt của Google cho biết lựa chọn thu thập dữ liệu dành cho hai AdsBot này ảnh hưởng khả năng kiểm tra chất lượng trang của Google Ads.
Không nên cho phép truy cập chỉ dựa vào chuỗi user-agent vì chuỗi này có thể bị giả mạo. Với nhật ký truy cập quan trọng, kỹ thuật cần đối chiếu IP hoặc DNS ngược theo hướng dẫn xác minh của Google.
Bước 5: kiểm tra theo khu vực, thiết bị và trạng thái
Thử máy tính/di động, trình duyệt phổ biến, mạng không đăng nhập và khu vực mà quảng cáo nhắm tới. Kiểm tra trang có yêu cầu cookie, đăng nhập, tuổi, vị trí hoặc mã truy cập hay không. Trang chỉ hoạt động khi có cookie quản trị viên hoặc khi truy cập từ Việt Nam không đủ để chứng minh tính sẵn sàng toàn cầu.
Bước 6: kiểm tra nội dung và thao tác chính
Mã 200 chưa chứng minh trang đáp ứng được nhu cầu. Trước tiên, kiểm tra H1 và nội dung có khớp lời hứa quảng cáo, trang có bị trống hoặc chỉ hiện khung chờ hay không. Sau đó, thử biểu mẫu, nút và thao tác chính; quan sát cửa sổ bật lên; kiểm tra nút quay lại có bị can thiệp hay không.
Với trang mua hàng, hãy thử chọn sản phẩm và thêm giỏ bằng dữ liệu an toàn. Không tạo đơn thật nếu chưa được phép.
Sửa lỗi và gửi xét duyệt lại Google Ads
Chỉ chuyển sang sửa và gửi lại sau khi sáu bước chẩn đoán đã xác định được lớp lỗi. Hai bước cuối cần lưu người phụ trách, thời điểm, thay đổi và kết quả kiểm tra sau sửa.
Bước 7: sửa đúng đầu mối và kiểm tra lại
Mã HTTP/DNS/TLS thuộc hosting; thử thách bot thuộc CDN/WAF; chuyển hướng hoặc mẫu theo dõi thuộc web và tracking; nội dung và thao tác chính thuộc chủ trang. Mỗi thay đổi cần có thời điểm, người phụ trách, trạng thái trước/sau và kết quả kiểm tra. Nếu phải thay URL, chọn trang cùng tên miền, cùng sản phẩm/dịch vụ và thật sự hoàn thành lời hứa của quảng cáo.
Bước 8: lưu quảng cáo hoặc gửi khiếu nại
Sau khi sửa và test lại URL mở rộng, lưu quảng cáo/thành phần để được xem xét. Nếu lỗi nằm ở template cấp nhóm, chiến dịch hoặc tài khoản, Google có thể yêu cầu khiếu nại sau khi sửa. Chỉ chọn lý do “quyết định sai” khi bằng chứng hạ tầng cho thấy URL đã tuân thủ; không dùng khiếu nại thay cho việc khắc phục.
Bằng chứng cần có cho từng lỗi trang đích Google Ads
Một hồ sơ đủ dùng cho phép người nhận xác định URL nào lỗi, lỗi ở lớp nào và thay đổi nào đã được xác minh. Chụp màn hình trang mở được chỉ là một mảnh bằng chứng. Hãy kèm phản hồi máy chủ, chuỗi chuyển hướng, URL mở rộng, nhật ký và kiểm tra thao tác chính theo phạm vi thực tế.
Trong quy trình nội bộ Lumie dùng để phối hợp giữa quảng cáo, web và hạ tầng, trạng thái quan sát được luôn tách khỏi kết luận. Ví dụ, “trình duyệt nhận HTTP 403 lúc 09:15” là quan sát; “WAF chặn AdsBot” chỉ là kết luận khi nhật ký và quy tắc chặn cùng xác nhận.
| Lớp | Bằng chứng cần giữ | Kết quả đạt | Chủ thể xác nhận |
|---|---|---|---|
| Google Ads | Nhãn từ chối, URL, campaign/ad/asset, thời điểm | Phân loại đúng nhánh chính sách | Người quản trị Ads |
| URL | URL cuối, URL mở rộng, template, tham số, redirect chain | Cùng domain/nội dung; chuỗi hợp lệ | Ads + tracking + web |
| Hạ tầng | HTTP status, DNS, TLS, timeout, region/device test | Nội dung hợp lệ trả 200 ổn định | Hosting/CDN |
| Crawl | Robots, WAF/CDN rule, log request đã xác minh | AdsBot không bị chặn/challenge | Security/DevOps |
| Hiển thị | Máy tính/di động, phiên ẩn danh, nội dung và thao tác chính | Trang dễ điều hướng và thao tác được | Web/UX/chủ nội dung |
| Nhật ký thay đổi | Người phụ trách, thời gian, thay đổi, kết quả trước/sau | Có thể tái hiện và đối chiếu | Người điều phối |
Khi dùng lệnh dòng để kiểm tra, curl -I chỉ cho biết header của yêu cầu cụ thể; một số máy chủ xử lý HEAD khác GET. Thử user-agent AdsBot giúp phát hiện quy tắc chặn hiển nhiên nhưng không chứng minh yêu cầu thật đến từ Google.
Nếu dùng nhật ký truy cập làm bằng chứng, kỹ thuật cần xác minh yêu cầu của Google theo IP hoặc DNS ngược. Không công bố địa chỉ IP, mã truy cập, cookie hay tham số nhạy cảm trong phiếu hỗ trợ có nhiều người xem.
Các nguyên nhân thường gặp trên WordPress, CDN và hệ thống tracking
Trên WordPress, lỗi thường nằm ở tương tác giữa permalink, cache, plugin bảo mật, CDN/WAF, chế độ bảo trì và chuỗi theo dõi. Không nên tắt hàng loạt plugin để “thử cho nhanh” trên website đang bán hàng. Hãy sao lưu đúng tài sản, thay đổi một lớp, xóa cache phù hợp và test lại URL mở rộng.
| Thành phần | Nguyên nhân có thể | Cách khoanh vùng | Sửa có kiểm soát |
|---|---|---|---|
| WordPress/permalink | Slug đổi, redirect cũ, trang nháp/xoá, rewrite lỗi | So URL Ads, canonical, redirect chain và REST/public status | Khôi phục URL owner hoặc cập nhật Final URL trực tiếp |
| Cache/CDN | HTML cũ, edge lỗi theo region, cache mã 5xx/maintenance | Test nhiều region, header cache và origin | Purge đúng layer; sửa origin nếu lỗi gốc |
| WAF/bot protection | 403, challenge, rate limit, geo/datacenter block | Log rule ID, response và request đã xác minh | Rule hẹp cho AdsBot hợp lệ; không tắt WAF toàn cục |
| Tracking | Template sai, tracker hết hạn, tham số gây 404, redirect JS | So test có/không có template và từng cấp override | Sửa template/parameter đúng owner; kiểm tra conversion sau đó |
| Nội dung/UX | Trang trống, popup che, login wall, CTA/form hỏng, sai sản phẩm | Render anonymous desktop/mobile và thử primary task | Sửa trang hoặc chọn URL phù hợp thật |
Nếu trang cần làm lại cấu trúc, thông tin, biểu mẫu hay khả năng hiển thị đa thiết bị, hãy chuyển sang phạm vi thiết kế landing page chạy quảng cáo. Đây không phải một mẹo xin duyệt. Sau khi sửa URL hoặc mẫu theo dõi, kiểm tra lại chuyển đổi và phân bổ; nếu tracking đã gãy, chuyển sang phạm vi sửa đo lường chuyển đổi.
Khi nào nên gửi xét duyệt lại hoặc khiếu nại?
Chỉ gửi xét duyệt lại khi đã có bằng chứng URL mở rộng hoạt động và nguyên nhân ban đầu đã được sửa. Nếu chỉ thay vài chữ trong quảng cáo mà lỗi nằm ở WAF, DNS hoặc mẫu theo dõi, lần xem xét tiếp theo vẫn có thể gặp cùng phản hồi. Nhật ký thay đổi ngắn giúp người hỗ trợ hiểu phần nào đã được sửa.
- Đã sửa quảng cáo/thành phần: lưu thay đổi để hệ thống xem xét nội dung mới.
- Đã sửa mẫu theo dõi cấp cao: thực hiện quy trình khiếu nại/xem xét theo giao diện tài khoản sau khi kiểm tra.
- Không thay đổi vì quyết định có vẻ sai: chỉ khiếu nại với bằng chứng URL, phản hồi máy chủ và phạm vi truy cập rõ ràng.
- Trang vẫn không ổn định: không gửi lặp lại; sửa hạ tầng hoặc chọn một đích đến hợp lệ khác.
Google không bảo đảm phê duyệt chỉ vì trang trả 200, và Lumie không cam kết thời gian hay kết quả xem xét. Trang còn phải đáp ứng các chính sách khác về sản phẩm, nội dung, minh bạch và khu vực phân phối.
Năm việc không nên làm khi quảng cáo bị từ chối
Những thay đổi không có bằng chứng có thể làm mất dấu vết, phá tracking hoặc tăng rủi ro chính sách. Đội ngũ cần một người giữ nhật ký thay đổi và một điều kiện dừng rõ cho mỗi lần thử.
- Không tạo tài khoản hoặc tên miền khác để né xét duyệt: việc này không sửa trang đích và có thể tăng rủi ro vi phạm hệ thống.
- Không cloaking: không hiển thị một nội dung cho Google và nội dung khác cho người dùng.
- Không tắt bảo mật toàn cục: sửa quy tắc hẹp sau khi xác định đầu mối và yêu cầu truy cập.
- Không ép trang lỗi trả 200: soft 404/soft error không biến thành nội dung hợp lệ chỉ nhờ status code.
- Không khiếu nại lặp lại khi chưa sửa: mỗi lần gửi phải có thay đổi hoặc bằng chứng mới có liên quan.
Khi nào cần giao cho web, hạ tầng hay đơn vị vận hành?
Chủ thể xử lý được quyết định bởi lớp bằng chứng, không phải bởi người phát hiện lỗi. Marketing chụp nhãn và URL; web sửa trang hoặc chuyển hướng; DevOps sửa DNS, TLS, CDN/WAF. Đơn vị đo lường sửa mẫu theo dõi và tham số; chủ nội dung xác nhận lời hứa của trang.
| Tình huống | Đầu mối chính | Đầu vào cần gửi | Đầu ra cần nhận |
|---|---|---|---|
| 403/5xx/timeout/DNS/TLS | Hosting, CDN, DevOps | URL mở rộng, response, thời gian, region/device | Nguyên nhân, rule/config đã sửa, test sau sửa |
| Redirect/template/parameter | Web + tracking + Ads | Final URL, template từng cấp, chuỗi redirect | Chuỗi ổn định, cùng domain/nội dung, conversion còn hoạt động |
| Trang trống, sai nội dung, CTA/form hỏng | Web/UX/chủ nội dung | Lời hứa quảng cáo, viewport, bước task bị lỗi | Trang render đúng và hoàn tất task |
| Nhiều chiến dịch/tên miền cùng lỗi | Người điều phối Google Ads | Phạm vi tài khoản, lịch sử thay đổi, nhật ký và sơ đồ đầu mối | Kế hoạch khắc phục, thứ tự kiểm tra và hồ sơ xét duyệt |
Nếu doanh nghiệp cần một đầu mối rà cả cấu trúc chiến dịch, URL, tracking và hồ sơ xét duyệt, có thể xác định phạm vi trong dịch vụ quản lý Google Ads. Lumie cần mã khách hàng, nhãn từ chối, URL mở rộng và thay đổi gần nhất. Bằng chứng gửi kèm phải che dữ liệu nhạy cảm. Đầu ra đầu tiên là phân đầu mối và thứ tự khắc phục, không phải cam kết được duyệt.
Câu hỏi thường gặp khi quảng cáo Google bị từ chối
Các câu trả lời sau giúp chọn bước tiếp theo. Trạng thái trong chính tài khoản, URL mở rộng và log máy chủ vẫn là bằng chứng chính cho từng trường hợp.
Vì sao trang mở được nhưng Google Ads vẫn báo không hoạt động?
Trang có thể chỉ mở được theo cookie, IP, khu vực hoặc trình duyệt của người quản trị. Google có thể đang kiểm tra URL mở rộng có mẫu theo dõi/tham số, hoặc AdsBot bị WAF, DNS, chuyển hướng hay quá thời gian chặn. Hãy so đúng URL và phản hồi máy chủ thay vì chỉ mở trang chủ.
HTTP 200 có đủ để quảng cáo được duyệt không?
Không. HTTP 200 chỉ loại được một nhóm lỗi kỹ thuật cho yêu cầu đã thử. Trang còn phải hoạt động trên thiết bị/khu vực phù hợp, không là lỗi mềm, cung cấp nội dung đủ phục vụ truy vấn và tuân thủ các chính sách liên quan.
Có nên xoá quảng cáo và tạo lại không?
Không nên làm trước khi xác định đầu mối. Nếu lỗi nằm ở tên miền, WAF, chuyển hướng hoặc mẫu theo dõi cấp tài khoản, quảng cáo mới vẫn dùng cùng đích lỗi. Việc tạo lại còn làm lịch sử thay đổi khó đọc hơn.
Bao lâu Google xem xét lại?
Thời gian có thể thay đổi theo loại nội dung, phạm vi và hệ thống xét duyệt. Bài này không đưa ra một mốc cam kết. Hãy kiểm tra trạng thái trong tài khoản, tránh gửi lặp khi chưa có thay đổi và lưu hồ sơ để chuyển hỗ trợ nếu cần.
Checklist chốt trước khi gửi lại Google
Một lần gửi lại chỉ nên bắt đầu khi đã khoá được URL, đầu mối, bằng chứng và trạng thái sau sửa. Trước khi lưu hoặc khiếu nại, đội ngũ xác nhận:
- Nhãn từ chối và URL mở rộng đã được ghi đúng.
- Chuỗi chuyển hướng hợp lệ; nội dung hợp lệ trả HTTP 200.
- DNS, TLS và thời gian phản hồi ổn định; AdsBot không bị chặn.
- Phiên ẩn danh trên máy tính và di động hoàn thành được thao tác chính.
- Tracking và chuyển đổi còn hoạt động; nhật ký có người phụ trách và thời điểm.
Nếu một ô còn chưa xác định, hãy giữ nguyên trạng thái thay vì đánh dấu đạt cho đủ danh sách. Nhờ đó, Lumie hoặc đội kỹ thuật nhìn thấy chính xác lớp còn thiếu bằng chứng. Website vẫn được bảo vệ và quy trình khắc phục không biến thành chuỗi thử ngẫu nhiên.