Câu trả lời ngắn gọn
Lập chỉ mục mobile-first đã hoàn tất. Kể từ tháng 7 năm 2024, Google chỉ sử dụng phiên bản di động của trang web bạn để lập chỉ mục và xếp hạng. Nếu nội dung, dữ liệu có cấu trúc hoặc liên kết nội bộ tồn tại trên desktop nhưng không có trên di động, Google sẽ không nhìn thấy chúng. Trong năm 2026, điều này có ba hệ quả mới mà hầu hết chủ sở hữu trang web vẫn chưa xử lý: INP đã thay thế FID làm Chỉ số Core Web Vital, AI Overviews trích xuất từ nội dung được render trên di động, và Bản cập nhật Core tháng 3 năm 2026 đã tăng trọng số xếp hạng cho trải nghiệm trang di động.
Dưới đây, bạn sẽ tìm thấy quy trình kiểm tra đầy đủ — cùng một kỹ năng Codex có thể sao chép-dán để chạy hầu hết các bước kiểm tra cho bạn.
"Chỉ dành cho thiết bị di động" thực sự có ý nghĩa gì trong năm 2026
Google bắt đầu chuyển các trang web sang lập chỉ mục mobile-first vào năm 2018. Quá trình chuyển đổi mất hơn sáu năm. Kể từ tháng 7 năm 2024, mọi trang web vẫn còn nội dung hiển thị trên desktop nhưng không có nội dung tương đương trên di động đều mất nội dung đó khỏi chỉ mục của Google. Không có tùy chọn từ chối và không có phương án dự phòng chỉ dành cho desktop.
Nhưng câu chuyện không dừng lại ở đó. Ba thay đổi trong giai đoạn 2025–2026 đã thay đổi những gì "mobile-first" yêu cầu từ trang web của bạn:
Thay đổi 1: INP đã thay thế FID — và hầu hết các trang di động đều không đạt
Vào tháng 3 năm 2024, Google đã thay thế First Input Delay (FID) bằng Interaction to Next Paint (INP) làm Chỉ số Core Web Vital. INP đo lường tốc độ phản hồi của trang đối với các thao tác chạm, nhấp và nhấn phím trong toàn bộ phiên trang, không chỉ ở lần tương tác đầu tiên.
Con số thực tế: khoảng 40% trang web vượt qua FID nhưng không vượt qua INP. Trên thiết bị di động, chỉ khoảng 65% trang web đáp ứng ngưỡng "tốt" từ 200 mili giây trở xuống. Bản cập nhật Core tháng 3 năm 2026 đã tăng thêm trọng số xếp hạng của Core Web Vitals. Các trang web không đạt INP trên di động hiện đang mất vị trí vào tay các đối thủ nhanh hơn.
Thay đổi 2: AI Overviews và trình thu thập AI đọc nội dung di động của bạn
AI Overviews của Google xuất hiện trong khoảng 47% lượt tìm kiếm tính đến giữa năm 2026. Khi hệ thống AI của Google tạo câu trả lời, chúng trích xuất từ cùng nội dung được lập chỉ mục trên di động mà tìm kiếm thông thường sử dụng. Các trình thu thập AI của bên thứ ba (GPTBot, ClaudeBot, PerplexityBot) cũng truy cập các trang được render trên di động của bạn.
Nếu phiên bản di động của bạn thiếu dữ liệu có cấu trúc, tiêu đề rõ ràng hoặc văn bản quan trọng, hệ thống AI không thể trích dẫn bạn — ngay cả khi phiên bản desktop có nội dung đó.
Thay đổi 3: Khoảng cách tương đương nội dung hiện có tác động đo lường được đến xếp hạng
Trong năm 2026, các trang web có nội dung di động và desktop không nhất quán cho thấy mức độ hiển thị tìm kiếm tự nhiên thấp hơn 31,2% trung bình so với các trang web có nội dung tương đương hoàn toàn. Các yếu tố phổ biến nhất bị thiếu trên di động: nội dung tab ẩn, liên kết sidebar, đánh dấu dữ liệu có cấu trúc, văn bản alt cho hình ảnh và liên kết điều hướng nội bộ.
Yếu tố nội dung | % trang web thiếu nó trên di động |
|---|---|
Dữ liệu có cấu trúc (JSON-LD) | 23% |
Liên kết nội bộ (menu, breadcrumbs) | 18% |
Văn bản alt cho hình ảnh | 27% |
Văn bản đầy đủ trong tab/accordion | 15% |
Thẻ meta robots | 9% |
Cách kiểm tra xem trang web của bạn có đạt yêu cầu không (phiên bản 2 phút)
Trước khi chạy kiểm tra đầy đủ, hãy kiểm tra ba tín hiệu sau. Mỗi tín hiệu mất chưa đến một phút và cho bạn biết có cần đào sâu hơn không.
Tín hiệu 1: Trạng thái lập chỉ mục trong Google Search Console
Mở Google Search Console → nhấp Settings (biểu tượng bánh răng, góc dưới bên trái) → xem phần "About". Nếu nó hiển thị "Googlebot smartphone" trong mục "Indexing crawler", trang web của bạn đang sử dụng lập chỉ mục mobile-first. Điều này đúng với hầu như mọi trang web trong năm 2026 — nhưng hãy xác minh nó.
Cũng kiểm tra: Công cụ URL Inspection → nhập bất kỳ trang quan trọng nào → mở rộng "Crawl" → xác nhận "Crawled as: Googlebot smartphone." Hãy xem ảnh chụp màn hình mà Google cung cấp — đây chính xác là những gì Google nhìn thấy. Nếu nội dung quan trọng bị thiếu trong ảnh chụp màn hình đó, nó sẽ bị thiếu khỏi chỉ mục.
Tín hiệu 2: PageSpeed Insights với dữ liệu di động thực tế
Truy cập PageSpeed Insights, nhập URL của bạn và xem phần "Discover what your real users are experiencing". Đây là dữ liệu thực địa từ Chrome User Experience Report (CrUX) — cùng dữ liệu mà Google sử dụng để xếp hạng.
Nếu báo cáo di động hiển thị màu cam hoặc đỏ cho INP (Interaction to Next Paint), bạn có một rủi ro xếp hạng đang hoạt động. Ngưỡng là dưới 200 mili giây cho màu xanh lá.
Tín hiệu 3: Kiểm tra nhanh viewport di động bằng Chrome DevTools
Mở Chrome DevTools (F12 hoặc Cmd+Option+I), nhấp biểu tượng thanh công cụ thiết bị (Ctrl+Shift+M), và chọn cài đặt sẵn thiết bị di động như "Pixel 7." Tải lại trang. Quét tìm:
- Văn bản yêu cầu cuộn ngang
- Nút hoặc liên kết quá nhỏ để chạm (dưới 48×48 pixel CSS)
- Nội dung ẩn sau các nút chuyển đổi "đọc thêm" không có trong mã nguồn HTML
- Cửa sổ bật lên che phần lớn màn hình
Mỗi vấn đề trên đều là vấn đề lập chỉ mục di động nếu nội dung hoặc liên kết phía sau chúng khác với những gì người dùng desktop nhìn thấy.
Kiểm tra mobile-first trong 30 phút (với Codex)
Cách nhanh nhất để chạy kiểm tra mobile-first đầy đủ hiện nay là giao cho một tác nhân lập trình AI — Claude Code hoặc Codex — một nhiệm vụ có cấu trúc. Tác nhân đọc mã nguồn trang web của bạn, kiểm tra các quy tắc và tạo ra danh sách sửa lỗi được ưu tiên.
Dưới đây là tệp kỹ năng hoàn chỉnh. Sao chép nó vào dự án của bạn, sau đó yêu cầu tác nhân của bạn chạy nó.
Bước 1: Tạo tệp kỹ năng
Tạo một tệp tại .claude/skills/mobile-first-audit/SKILL.md (cho Claude Code) hoặc .codex/skills/mobile-first-audit/SKILL.md (cho Codex):
name: mobile-first-audit
description: Kiểm tra một URL hoặc danh sách URL về mức độ sẵn sàng lập chỉ mục mobile-first. Kiểm tra tính tương đương nội dung, Core Web Vitals, dữ liệu có cấu trúc, UX di động và quyền truy cập của trình thu thập AI.
# Kiểm tra lập chỉ mục Mobile-First
Chạy kiểm tra lập chỉ mục mobile-first có cấu trúc trên một hoặc nhiều URL. Tác nhân phải báo cáo phát hiện, không thực hiện chỉnh sửa, trừ khi người dùng phê duyệt rõ ràng kế hoạch sửa lỗi.
## Đầu vào
Người dùng cung cấp một hoặc nhiều URL trang. Nếu họ cung cấp URL sitemap hoặc danh sách hơn 5 URL, hãy lấy mẫu 5 URL đại diện cho các loại trang khác nhau (trang chủ, trang sản phẩm, bài viết, trang danh mục, landing page).
## Danh sách kiểm tra
Đối với mỗi URL, kiểm tra và báo cáo tất cả mười một mục dưới đây. Đánh dấu mỗi mục là `PASS`, `WARN` hoặc `FAIL`. Bao gồm bằng chứng cho mọi mục WARN và FAIL.
### 1. Thẻ Meta Viewport
Kiểm tra rằng `<meta name="viewport" content="width=device-width, initial-scale=1">` có mặt trong `<head>` HTML. Nếu thiếu hoặc nếu nó đặt chiều rộng cố định hoặc vô hiệu hóa user-scaling mà không có lý do trợ năng hợp lệ, đánh dấu FAIL.
### 2. Tính tương đương nội dung (Văn bản)
Tìm nạp trang với user-agent desktop và user-agent di động (Googlebot Smartphone). So sánh nội dung văn bản hiển thị. Nếu bất kỳ khối văn bản nào trên 50 từ tồn tại trên desktop nhưng không có trong mã nguồn HTML di động, đánh dấu WARN. Nếu văn bản nội dung quan trọng, tiêu đề hoặc mô tả sản phẩm bị thiếu, đánh dấu FAIL.
### 3. Tính tương đương dữ liệu có cấu trúc
Trích xuất tất cả các khối JSON-LD từ cả hai lần tìm nạp desktop và di động. Nếu bất kỳ loại schema nào có mặt trên desktop nhưng thiếu trên di động, đánh dấu FAIL. Nếu nội dung schema khác nhau giữa các phiên bản, đánh dấu WARN.
### 4. Tính tương đương thẻ Meta
So sánh các thẻ title, meta description, canonical, robots và hreflang giữa phiên bản desktop và di động. Bất kỳ sự khác biệt nào là WARN. Thiếu canonical hoặc thẻ robots xung đột là FAIL.
### 5. Liên kết nội bộ và điều hướng
Đếm số lượng thẻ `<a href>` liên kết nội bộ trong HTML desktop và di động. Nếu phiên bản di động có ít hơn 20%+ liên kết nội bộ, đánh dấu WARN. Nếu liên kết breadcrumb, điều hướng danh mục hoặc liên kết footer có trên desktop nhưng thiếu trên di động, đánh dấu FAIL.
### 6. Văn bản Alt cho hình ảnh
Đếm hình ảnh trong HTML di động. Báo cáo số lượng và tỷ lệ phần trăm thiếu thuộc tính alt. Nếu hơn 10% hình ảnh thiếu văn bản alt, đánh dấu WARN. Nếu hình ảnh hero hoặc hình ảnh sản phẩm thiếu văn bản alt, đánh dấu FAIL.
### 7. Core Web Vitals (Dữ liệu thực địa)
Tra cứu dữ liệu thực địa Chrome UX Report (CrUX) của URL. Nếu có thể truy cập qua PageSpeed Insights API hoặc tra cứu CrUX trực tiếp, báo cáo LCP, INP và CLS cho di động. Đánh dấu ngưỡng: LCP > 2,5s = WARN, > 4,0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0,1 = WARN, > 0,25 = FAIL.
Nếu dữ liệu CrUX không khả dụng (không đủ lưu lượng truy cập), ghi chú điều này và sử dụng dữ liệu phòng thí nghiệm từ Lighthouse làm phương án dự phòng với lưu ý rằng dữ liệu phòng thí nghiệm không được sử dụng để xếp hạng.
### 8. Kích thước mục tiêu chạm
Kiểm tra CSS cho các nút, liên kết và phần tử tương tác. Gắn cờ bất kỳ phần tử nào có chiều cao hoặc chiều rộng tính toán dưới 48 pixel CSS. Gắn cờ các phần tử tương tác liền kề có khoảng cách dưới 8px. Đánh dấu WARN cho 1-3 vi phạm, FAIL cho 4+.
### 9. Kích thước phông chữ
Kiểm tra rằng văn bản nội dung sử dụng font-size tính toán ít nhất 16px. Gắn cờ bất kỳ văn bản nào dưới 12px. Đánh dấu WARN nếu văn bản nội dung là 14-15px, FAIL nếu dưới 12px.
### 10. Cửa sổ xen kẽ và cửa sổ bật lên
Kiểm tra trực quan viewport di động. Nếu cửa sổ bật lên, biểu ngữ hoặc cửa sổ xen kẽ che phủ hơn 30% viewport ban đầu và không bắt buộc về mặt pháp lý (đồng ý cookie, xác minh độ tuổi), đánh dấu WARN. Nếu cửa sổ bật lên ngăn cuộn hoặc đọc nội dung, đánh dấu FAIL.
### 11. Quyền truy cập của trình thu thập AI
Kiểm tra robots.txt để tìm quy tắc chặn GPTBot, ClaudeBot, PerplexityBot, Google-Extended hoặc OAI-SearchBot. Nếu bất kỳ trình thu thập AI nào bị chặn, ghi chú đó là lựa chọn có chủ đích. Nếu trình thu thập AI được phép nhưng trang không có dữ liệu có cấu trúc, đánh dấu WARN (hệ thống AI phụ thuộc vào dữ liệu có cấu trúc để trích dẫn).
## Định dạng đầu ra
Tạo báo cáo Markdown:
```markdown
# Báo cáo kiểm tra Mobile-First
**Ngày:** YYYY-MM-DD
**Số URL đã kiểm tra:** N
**Điểm tổng thể:** X/11 mục PASS trung bình mỗi URL
## Tóm tắt
| Kiểm tra | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |
## Phát hiện chi tiết
### URL 1: [url]
**Mục FAIL (phải sửa):**
- [Tên mục]: [bằng chứng và hướng dẫn sửa]
**Mục WARN (nên sửa):**
- [Tên mục]: [bằng chứng và hướng dẫn sửa]
**Mục PASS:** [danh sách]
### Hàng đợi sửa lỗi ưu tiên
1. [Sửa lỗi ưu tiên cao nhất] — ảnh hưởng trực tiếp đến lập chỉ mục
2. [Sửa lỗi tiếp theo] — ảnh hưởng đến xếp hạng
3. ...Quy tắc
- Không thực hiện bất kỳ thay đổi nào đối với trang web nếu không có sự phê duyệt rõ ràng của người dùng về kế hoạch sửa lỗi.
- Nếu bạn không thể kiểm tra một mục vì trang yêu cầu xác thực, ghi chú là "NOT CHECKED — authentication required."
- Đối với dữ liệu CrUX, sử dụng Chrome UX Report API chính thức hoặc PageSpeed Insights API nếu có sẵn. Nếu không thể truy cập cả hai, sử dụng Lighthouse mobile audit làm phương án dự phòng.
- Không bao giờ bịa đặt chỉ số, điểm số hoặc kết quả kiểm tra. Nếu dữ liệu không khả dụng, hãy nói rõ.
- Không truy cập hoặc tiết lộ khóa API, cookie, token hoặc thông tin xác thực.
### Bước 2: Chạy kiểm tra
Yêu cầu tác nhân của bạn: **"Run the mobile-first audit skill on [your URL]"** và dán URL bạn muốn kiểm tra. Tác nhân sẽ tạo báo cáo với PASS/WARN/FAIL cho mỗi trong số 11 mục kiểm tra, cùng với hàng đợi sửa lỗi ưu tiên.
Nếu bạn muốn kiểm tra nhiều trang cùng lúc, cung cấp danh sách: **"Run the mobile-first audit on these 5 URLs: [URL1, URL2, URL3, URL4, URL5]"**.
## Sửa lỗi #1: Tính tương đương nội dung — những gì cần kiểm tra đầu tiên
Tính tương đương nội dung là sửa lỗi có tác động cao nhất vì nó trực tiếp xác định những gì Google có thể lập chỉ mục. Dưới đây là những gì thường bị hỏng nhất và cách sửa từng cái.
### Nội dung ẩn trong tab và accordion
Nhiều trang web trên di động thu gọn nội dung dài vào tab, accordion hoặc nút chuyển đổi "đọc thêm". Điều này ổn **miễn là nội dung có trong mã nguồn HTML** — Google không còn giảm giá trị nội dung bị ẩn vì lý do UX. Nhưng nếu tab của bạn tải nội dung qua JavaScript sau khi người dùng chạm, Googlebot không kích hoạt thao tác chạm đó. Nội dung sẽ vô hình.
**Cách kiểm tra:** Trong Chrome DevTools, nhấp chuột phải vào nội dung ẩn và chọn "Inspect." Nếu bạn thấy văn bản trong bảng Elements, nó có trong DOM và Google có thể nhìn thấy. Nếu bảng Elements hiển thị một vùng chứa trống cho đến khi bạn nhấp vào tab, nội dung được tải động và Google bỏ lỡ nó.
**Cách sửa:** Render phía máy chủ nội dung ẩn vào HTML. Sử dụng CSS (`display: none` hoặc visibility toggles) cho hành vi hiển thị/ẩn thay vì chèn nội dung bằng JavaScript.
### Thiếu dữ liệu có cấu trúc trên di động
Dữ liệu có cấu trúc (JSON-LD) phải có mặt trong HTML di động. Điều này dễ bị bỏ sót nếu theme di động hoặc phiên bản AMP của bạn sử dụng mẫu khác.
**Cách kiểm tra:** Mở trang di động, xem nguồn (`Cmd+Option+U`), và tìm kiếm `application/ld+json`. Sau đó làm tương tự trên desktop. Các khối JSON-LD giống nhau sẽ xuất hiện ở cả hai.
**Cách sửa:** Đảm bảo dữ liệu có cấu trúc của bạn được render phía máy chủ và được bao gồm trong cùng một phản hồi HTML cho cả di động và desktop. Nếu sử dụng CMS, kiểm tra xem plugin schema hoặc theme của bạn có đang tải script có điều kiện dựa trên phát hiện thiết bị không.
### Liên kết điều hướng bị loại bỏ khỏi menu di động
Menu di động thường đơn giản hóa hoặc loại bỏ các liên kết tồn tại trong điều hướng desktop: breadcrumbs, liên kết danh mục, cột footer, liên kết sidebar. Google sử dụng liên kết nội bộ để hiểu cấu trúc trang web và phân phối PageRank. Liên kết thiếu trên di động sẽ thiếu trong đồ thị của Google.
**Cách kiểm tra:** Đếm số thẻ `<a href>` trong mã nguồn desktop so với mã nguồn di động. Một thiết kế responsive nên có số lượng gần như bằng nhau. Nếu số lượng di động thấp hơn 30%+, hãy điều tra những liên kết nào đã biến mất.
**Cách sửa:** Thêm các liên kết điều hướng bị thiếu vào menu di động, menu hamburger hoặc footer. Ưu tiên liên kết đến các trang danh mục quan trọng, bài viết chính và trang cha.
## Sửa lỗi #2: INP — chỉ số tốc độ di động mà hầu hết các trang web bỏ qua
Interaction to Next Paint (INP) đo lường thời gian trang phản hồi trực quan sau khi người dùng chạm, nhấp hoặc nhấn phím. Ngưỡng là **200 mili giây trở xuống**.
Không giống FID, vốn chỉ đo độ trễ đầu vào của tương tác đầu tiên, INP đo mọi tương tác và báo cáo tương tác **tệ nhất**. Điều này làm cho nó trở thành một bài kiểm tra khắt khe hơn nhiều.
### Điều gì làm giảm INP trên di động
Các nguyên nhân phổ biến nhất, theo thứ tự:
1. **JavaScript nặng chạy trên luồng chính.** Các bundle lớn, thành phần React/Vue chưa tối ưu và script theo dõi chặn trình duyệt phản hồi các thao tác chạm.
2. **Trình xử lý nhấp chuột làm quá nhiều việc trước khi cập nhật UI.** Nếu một thao tác chạm kích hoạt lệnh gọi API, cập nhật state và thay đổi DOM trước khi hiển thị bất kỳ phản hồi trực quan nào, INP sẽ bị ảnh hưởng.
3. **Thẻ bên thứ ba.** Analytics, widget trò chuyện, mạng quảng cáo và script cá nhân hóa — đặc biệt khi nhiều thẻ cạnh tranh cho luồng chính.
### Cách chẩn đoán INP
1. Mở [PageSpeed Insights](https://pagespeed.google.com/), nhập URL của bạn, cuộn đến "Discover what your real users are experiencing." Giá trị INP trong mục "Mobile" là những gì Google sử dụng.
2. Trong Chrome DevTools, mở bảng **Performance**, nhấp record, tương tác với trang (chạm nút, mở menu, nhập vào ô nhập liệu), sau đó dừng ghi. Tìm các tác vụ dài (được đánh dấu màu đỏ, 200ms+). Đây là các vấn đề INP của bạn.
3. Bạn cũng có thể hỏi tác nhân AI của mình: **"Check the Core Web Vitals for [URL] and tell me specifically what is hurting INP on mobile. Give me the top 3 fixes in priority order."**
### Cách sửa INP (thứ tự ưu tiên)
```text
Ưu tiên 1: Trì hoãn hoặc làm chậm các script bên thứ ba không quan trọng.
→ Tải widget trò chuyện, analytics và thẻ quảng cáo sau khi trang có thể tương tác.
→ Sử dụng <script defer> hoặc tải chúng 3-5 giây sau khi trang tải.
Ưu tiên 2: Chia nhỏ các tác vụ JavaScript dài.
→ Code-split theo route. Lazy-load các thành phần dưới màn hình.
→ Chuyển tính toán nặng sang requestIdleCallback() hoặc Web Worker.
Ưu tiên 3: Làm cho trình xử lý nhấp chuột cập nhật UI ngay lập tức.
→ Hiển thị trạng thái tải, spinner hoặc nút bị vô hiệu hóa trong 50ms đầu tiên.
→ Chạy công việc thực tế (gọi API, cập nhật state) sau phản hồi trực quan.Sửa lỗi #3: Mức độ sẵn sàng cho trình thu thập AI (lớp năm 2026)
Lập chỉ mục mobile-first hiện có một lớp AI. Khi AI Overviews của Google hoặc hệ thống AI bên thứ ba trả lời một câu hỏi, chúng trích xuất từ cùng nội dung được lập chỉ mục trên di động. Nếu các trang di động của bạn thiếu các tín hiệu mà hệ thống AI tìm kiếm, bạn mất cơ hội được trích dẫn.
Những gì hệ thống AI cần từ trang di động của bạn
Tín hiệu | Tại sao nó quan trọng | Kiểm tra nhanh |
|---|---|---|
Dữ liệu có cấu trúc (JSON-LD) | Giúp hệ thống AI hiểu thực thể, sản phẩm, bài viết, FAQ | Xem nguồn → tìm |
Hệ thống phân cấp tiêu đề rõ ràng | Trình trích xuất AI sử dụng H1-H4 để phân tích cấu trúc trang | Quét trang của bạn: mỗi phần có tiêu đề mô tả không? |
Khối câu trả lời ngắn gọn | AI Overviews ưu tiên câu trả lời 2-4 câu ở gần đầu trang | Trang của bạn có trả lời câu hỏi chính trong 200 từ đầu tiên không? |
Quyền truy cập robots.txt cho trình thu thập AI | Nếu bị chặn, hệ thống AI không thể tìm nạp nội dung của bạn | Kiểm tra robots.txt cho |
Tệp llms.txt | Giúp hệ thống AI khám phá nội dung chính của bạn hiệu quả | Kiểm tra |
Prompt kiểm tra nhanh mức độ sẵn sàng AI cho tác nhân của bạn
Check [URL] for AI search readiness. Tell me: (1) is JSON-LD structured data present and valid? (2) is there a clear answer to the page's main question in the first 200 words? (3) are AI crawlers allowed in robots.txt? (4) does llms.txt exist at the root? Give me a PASS/FAIL for each and tell me what to fix first.Prompt kiểm tra mobile-first hoàn chỉnh cho người mới bắt đầu
Dưới đây là bộ prompt bạn có thể sao chép vào Claude Code hoặc Codex ngay bây giờ. Mỗi prompt thực hiện một công việc cụ thể — không cần cấu hình gì ngoài việc mở tác nhân và trỏ đến dự án hoặc URL của bạn.
Prompt 1: Kiểm tra di động một trang
Run a mobile-first indexing audit on [YOUR URL HERE].
Check these 8 things and report PASS or FAIL for each with the evidence:
1. Viewport meta tag is correct
2. All body text visible on desktop is also in the mobile HTML source
3. JSON-LD structured data is the same on desktop and mobile
4. Title tag, meta description, and canonical are identical across desktop and mobile
5. Internal link count is roughly equal (not 20%+ fewer on mobile)
6. Images have alt text
7. Mobile Core Web Vitals (LCP, INP, CLS) from CrUX field data if available
8. AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are not blocked in robots.txt
For each FAIL, give me the exact fix in one sentence.Prompt 2: Kiểm tra hàng loạt trên các loại trang
I need to audit mobile-first readiness across different page types on my site. Here are 5 URLs, each representing a different template:
1. [HOMEPAGE URL]
2. [PRODUCT PAGE OR SERVICE PAGE URL]
3. [BLOG POST OR ARTICLE URL]
4. [CATEGORY OR COLLECTION PAGE URL]
5. [ABOUT OR CONTACT PAGE URL]
For each URL, check: viewport meta tag, content parity (text + structured data), meta tags consistency, internal links, image alt coverage, and mobile font/tap-target sizing.
Then produce a single table with all 5 URLs as columns and each check as a row. Color-code PASS green, WARN yellow, FAIL red (use emoji 🟢 🟡 🔴 if colors are not supported). Below the table, list the top 3 fixes across all pages in priority order.Prompt 3: Đào sâu tính tương đương nội dung
Fetch [URL] with both a desktop user-agent and the Googlebot Smartphone user-agent (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).
Compare the two versions and report any differences in:
- Visible text content (highlight blocks missing from mobile)
- Structured data (JSON-LD blocks)
- Meta tags (title, description, canonical, robots, hreflang)
- Internal link count and which sections lost links
- Image alt attributes
Do not make any edits. Just produce a diff report.Prompt 4: Chẩn đoán INP và kế hoạch sửa lỗi
Analyze [URL] for Interaction to Next Paint (INP) issues on mobile.
1. Check if CrUX field data is available and report the current mobile INP value.
2. If CrUX data is unavailable, run a Lighthouse mobile audit and report the Total Blocking Time (TBT) as a proxy indicator.
3. Identify the top 3 JavaScript tasks blocking the main thread during page load and after user interaction.
4. For each problem, give me: the specific file or script causing it, the impact on INP, and the one-line fix.
Format the output as a table: Problem | Source | Impact | Fix.Prompt 5: Kiểm tra trình thu thập AI + dữ liệu có cấu trúc
Check [URL] for AI search and AI crawler readiness:
1. Crawl robots.txt at the domain root. List all rules that mention these user-agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Amazonbot, Bytespider. If any are blocked, flag it.
2. Extract all JSON-LD blocks from the page. Validate each against Schema.org types. Report which types are present and whether they are complete (all required properties filled).
3. Check if /llms.txt exists at the domain root. If it does, report its content summary. If it does not, note that as a missing AI discovery asset.
4. Check if the page has a clear, self-contained answer (2-4 sentences) to its main topic within the first 200 words of body text.
5. Score the page on AI readiness: 0-100. Deduct points for: missing structured data (-30), blocked AI crawlers (-20 per crawler), no llms.txt (-15), no clear answer block (-20), headings not descriptive (-15).FAQ
H: Tôi có thể vẫn sử dụng trang di động riêng biệt (m.example.com) không? Về mặt kỹ thuật là có, nhưng Google khuyến nghị thiết kế responsive. URL di động riêng biệt tăng thêm độ phức tạp: bạn phải duy trì nội dung, thẻ canonical và hreflang giống hệt nhau trên hai bộ URL. Nếu bất kỳ thứ gì bị lệch, Google sẽ lập chỉ mục bất kỳ phiên bản nào nó thu thập lần cuối. Thiết kế responsive loại bỏ hoàn toàn rủi ro này.
H: Nếu trang web của tôi chỉ có desktop — hoàn toàn không có phiên bản di động thì sao? Nếu Googlebot Smartphone không thể truy cập và render nội dung của bạn, nội dung đó sẽ không được lập chỉ mục. Chấm hết. Một trang web chỉ dành cho desktop trong năm 2026 về cơ bản là vô hình với Google. Nếu bạn đang trong tình huống này, chuyển sang theme responsive là nhiệm vụ ưu tiên cao nhất của bạn.
H: Tôi có cần lo lắng về kích thước máy tính bảng không? Googlebot thu thập dưới dạng smartphone, không phải máy tính bảng. Tập trung vào viewport smartphone. Nói như vậy, người dùng máy tính bảng là người dùng thực — đảm bảo thiết kế responsive của bạn không bị hỏng ở độ rộng trung gian (768-1024px).
H: Làm thế nào để biết trang web của tôi đã vượt qua quá trình chuyển đổi mobile-first chưa? Mở Google Search Console → Settings → kiểm tra phần "About" để tìm "Indexing crawler: Googlebot smartphone." Nếu nó hiển thị như vậy, bạn đang sử dụng lập chỉ mục mobile-first. Hầu hết mọi trang web hiện nay đều như vậy.
H: Google có còn thu thập trang web của tôi bằng user-agent desktop cho bất kỳ mục đích gì không? Có. Google thỉnh thoảng thu thập bằng user-agent desktop cho các kiểm tra cụ thể (xác minh mối quan hệ, một số xử lý lại dữ liệu có cấu trúc). Đừng lo lắng nếu bạn thấy Googlebot desktop trong nhật ký của mình. Những lượt truy cập đó không có nghĩa là trang web của bạn đang sử dụng lập chỉ mục desktop-first.
H: Sửa các vấn đề mobile-first có cải thiện khả năng hiển thị trong AI Overviews của tôi không? Sửa chữa lập chỉ mục mobile-first cải thiện nền tảng. Nếu nội dung di động, dữ liệu có cấu trúc và tốc độ trang của bạn đều vững chắc, nội dung của bạn đủ điều kiện để được trích dẫn — nhưng hệ thống AI của Google vẫn chọn những gì để trích dẫn dựa trên mức độ liên quan, uy tín và chất lượng câu trả lời. Sửa các vấn đề mobile-first loại bỏ rào cản; nó không đảm bảo được đưa vào AI.
Tác giả: Julian Mercer, Chuyên gia SEO Kỹ thuật 14 năm tại Auspia. Julian viết về khả năng thu thập, render, schema, kiến trúc trang web và các nền tảng kỹ thuật giúp nội dung có thể được khám phá bởi công cụ tìm kiếm và hệ thống AI.
