Playbook này dành cho ai?

Agency gửi bạn landing page mới. Nhìn thì đẹp. Nhưng dòng tiêu đề to nhất trên trang lại không phải một h1 — nó chỉ là một khối chữ được phóng cỡ lớn. Hệ quả: Google không hiểu trang nói về cái gì, và bài SEO bạn trả tiền có thể không bao giờ lên hạng. Bạn không cần biết lập trình để phát hiện lỗi này — chỉ cần biết cách mở DevTools và đọc.

Playbook này dành cho bạn nếu bạn làm Marketing/Sales, đụng vào CMS, làm việc với dev/agency, và muốn đọc được một trang web đủ để soi lỗi, kiểm tra tracking, và báo cáo vấn đề cho team kỹ thuật. Đây là module đọc-hiểu, không dạy viết code — mọi đoạn code dưới đây là để bạn nhận ra, không phải để gõ lại.

Bạn sẽ đạt được gì?

Đọc được HTML cơ bản: nhận ra tag, hiểu cấu trúc một trang
Biết CSS làm gì và JavaScript làm gì — đặc biệt vì sao tracking pixel chạy bằng JavaScript
Dùng được DevTools (Inspect) để soi một phần tử, xem lỗi, kiểm tra trang nặng bao nhiêu
Viết một bug report mà dev đọc xong làm được ngay, thay vì "web bị lỗi"

Bạn cần chuẩn bị gì?

Trình duyệt Chrome hoặc Edge.
Một trang web bất kỳ của bạn để mở ra soi.

Bức tranh toàn cảnh

Một trang web được dựng bằng ba ngôn ngữ, mỗi cái một vai. Ẩn dụ dễ nhớ nhất là cơ thể người:

Ngôn ngữ	Vai	Quyết định
HTML	Khung xương	Cấu trúc — có những phần gì: tiêu đề, đoạn văn, ảnh, nút
CSS	Lớp da	Trình bày — màu, font, khoảng cách, bố cục
JavaScript	Cơ bắp	Hành vi — tương tác, hiệu ứng, và tracking

Ba lớp dựng nên một trang: HTML khung xương, CSS lớp da, JavaScript cơ bắp.

Cùng một bộ xương HTML, thay lớp da CSS là ra giao diện khác hẳn. Tách ba vai này ra, bạn đọc được mọi trang — và biết khi "trang lỗi" thì hỏi đúng người: lỗi cấu trúc (HTML), lỗi trình bày (CSS), hay lỗi hành vi/tracking (JavaScript).

Đọc code AI viết ra — đẹp mắt không bằng đúng cấu trúc

AI giờ dựng xong một landing page trong 30 giây. Nhưng chạy được không có nghĩa là đúng. Một trang AI sinh ra có thể trông hoàn hảo mà tiêu đề không phải h1, ảnh không có alt, heading nhảy cấp lung tung — những lỗi Google và trình đọc màn hình rất ghét, nhưng mắt thường không thấy. Kỹ năng đọc trong bài này chính là lớp đánh giá mà AI không tự làm thay bạn: bạn mở ra, đọc cấu trúc, và biết thứ AI đưa có dùng được không.

1. HTML — khung xương của trang

HTML (Hypertext Markup Language) nói cho trình duyệt biết trang có cấu trúc gì. Nó được tạo bởi các tag (thẻ). Mỗi tag có một tên mang một ý nghĩa.

Có hai kiểu tag:

Tag bao — có mở và đóng, nội dung nằm giữa: <p>Đoạn văn của tôi.</p>. Tên tag luôn viết thường.
Tag tự đóng — không có phần đóng riêng: <img src="anh.jpg">, <br> (xuống dòng).

Các tag lồng vào nhau thành cây — đây chính là DOM bạn gặp ở M1:

<body>
  <h1>Hoa đẹp</h1>
  <p>Một đoạn mô tả về hoa.</p>
  <img src="hoa.jpg" alt="Bó hoa hồng">
</body>

Bạn không cần thuộc tag. Chỉ cần nhận ra một nhúm tag marketer hay đụng:

Tag	Nghĩa
`h1`…`h6`	Tiêu đề, `h1` quan trọng nhất trang (chỉ nên có một)
`p`	Đoạn văn
`a`	Liên kết (link)
`img`	Ảnh
`title`	Tiêu đề trang — hiện trên tab + trên kết quả Google
`meta`	Dữ liệu mô tả trang (gồm meta description cho Google)

2. Semantic HTML — vì sao Google quan tâm tag nào

Semantic HTML nghĩa là dùng đúng tag mang đúng nghĩa, để trình duyệt, trình đọc màn hình, và công cụ tìm kiếm hiểu trang. Đây là chỗ HTML chạm thẳng vào SEO của bạn.

Ví dụ cùng một dòng chữ to "Khóa học Web cơ bản":

Viết đúng: <h1>Khóa học Web cơ bản</h1> → Google hiểu đây là chủ đề chính của trang.
Viết sai (như landing page ở đầu bài): một khối <div> được phóng cỡ chữ cho to → trông y hệt, nhưng Google không thấy tiêu đề nào, không biết trang nói về gì.

Hai thứ semantic quan trọng nhất với marketer, cả hai đều cho Google:

title và meta description — nằm trong phần đầu trang, là cái Google hiển thị trên kết quả tìm kiếm. Viết tốt = nhiều click hơn.
Heading đúng cấp — h1 cho tiêu đề chính, h2 cho mục lớn, h3 cho mục con. Đừng nhảy cóc hay nhồi nhiều h1.

Vài attribute (thuộc tính) đặt bên trong tag cũng đáng biết:

Attribute	Làm gì	Vì sao quan trọng
`alt`	Mô tả ảnh bằng chữ	Google đọc ảnh qua `alt`; thiếu = mất điểm SEO + bất tiện cho người khiếm thị
`href`	Địa chỉ đích của link	Sai = link gãy
`class` / `id`	Nhãn để định vị một phần tử	Dev và tracking dùng để "trỏ" tới đúng phần tử

Phần cấu trúc dữ liệu nâng cao để Google hiển thị sao/giá/review (structured data) thuộc về bài Được Google tìm thấy — nó cũng là HTML, nhưng là chuyện SEO.

3. CSS — lớp da quyết định giao diện

CSS (Cascading Style Sheets) quyết định trang trông thế nào: màu, font, cỡ chữ, khoảng cách, bố cục cột. Bạn không cần viết CSS — chỉ cần hiểu nó làm gì, để khi dev nói "sửa CSS chỗ này" bạn biết họ đang đụng vào trình bày, không phải nội dung.

Điểm cần nhớ: CSS đổi hình thức, không đổi nội dung. Cùng một bộ HTML, gắn bộ CSS khác là ra một giao diện khác hẳn — như thay áo cho cùng một người. Vì vậy:

Khi bạn muốn đổi chữ trên trang (sửa câu, đổi tiêu đề) → đó là HTML/nội dung, sửa trong CMS.
Khi bạn muốn đổi màu nút, khoảng cách, font → đó là CSS, thường phải nhờ dev (hoặc chỉnh trong phần "thiết kế" của CMS).

CSS "trỏ" tới phần tử cần tô bằng selector — thường theo tag, theo class, hoặc theo id. Bạn chỉ cần hiểu ở mức ý niệm: khi dev nói "class .btn-mua đang sai màu", họ đang nói tới một nhãn gắn trên nút, và CSS dùng nhãn đó để biết tô nút nào.

4. JavaScript — cơ bắp, và là nơi tracking sống

JavaScript (JS) làm trang động: popup hiện ra, slider chạy, nút bấm phản hồi, nội dung tải thêm khi cuộn. Nhưng với marketer, JS có một vai trò ít người nói tới: gần như mọi tracking đều chạy bằng JavaScript.

Google Analytics, Meta Pixel, TikTok Pixel, Hotjar, công cụ A/B test — tất cả được nhúng vào trang dưới dạng một đoạn JavaScript. Khi khách mở trang, đoạn JS đó chạy và "bắn" dữ liệu về cho công cụ đo. Hệ quả thực tế bạn phải nắm:

Chặn JavaScript = mất tracking. Khách dùng trình chặn quảng cáo/JS → pixel không bắn → họ "vô hình" trong báo cáo. Đây là một lý do số liệu GA không bao giờ khớp 100% thực tế.
JS lỗi có thể làm hỏng cả tính năng — nút "Thêm vào giỏ" không phản hồi thường là lỗi JavaScript, không phải lỗi nội dung.
JS load chậm = pixel bắn muộn / trang giật. Càng nhiều script bên thứ ba, trang càng nặng (chuyện này nối sang page speed ở bài Được Google tìm thấy).

Bạn không học viết JS. Bạn chỉ cần biết: khi tính năng "động" hỏng hoặc tracking không lên số, nghi ngờ đầu tiên là JavaScript — và bài tiếp theo cho bạn công cụ tự kiểm chứng điều đó.

5. DevTools — kính lúp soi mọi trang

Mọi trình duyệt có sẵn một bộ DevTools (công cụ cho nhà phát triển) miễn phí. Bạn mở bằng: chuột phải vào trang → "Kiểm tra" / "Inspect" (hoặc phím F12). Marketer dùng đúng ba tab:

Tab Elements (Phần tử) — xem HTML thật của trang. Bấm vào biểu tượng mũi tên góc trái, rồi click vào bất cứ thứ gì trên trang → DevTools nhảy tới đúng đoạn HTML của nó. Đây là cách bạn kiểm tra tiêu đề có phải h1 thật không, ảnh có alt không.

Tab Console — xem lỗi. Những dòng chữ đỏ ở đây là lỗi JavaScript. Bạn không cần hiểu nội dung lỗi — chỉ cần biết: có nhiều dòng đỏ = trang đang có vấn đề về hành vi/tracking, và bạn nên chụp lại để gửi dev.

Tab Network (Mạng) — xem trang tải gì. Tải lại trang khi tab này mở → bạn thấy mọi file trang gọi về, dung lượng từng cái, và tổng nặng bao nhiêu. Hai việc marketer làm ở đây: (1) kiểm tra pixel có thật sự bắn không (lọc tên pixel), (2) xem ảnh nào nặng làm trang chậm.

DevTools — ba tab marketer dùng: Elements (đọc HTML), Console (xem lỗi đỏ), Network (xem trang tải gì).

Bạn chỉ đọc, không sửa. Mọi thay đổi trong DevTools chỉ là tạm thời trên máy bạn — tải lại trang là mất. Đây là kính lúp, không phải bàn sửa.

6. Viết bug report mà dev hiểu ngay

Đây là kỹ năng giao tiếp số một với team kỹ thuật — và là chỗ marketer hay làm dev phát điên. "Web bị lỗi" không phải bug report; nó là một câu đố. Dev nhận tin đó phải hỏi lại năm lần mới làm được, mất rất nhiều thời gian.

Một bug report tốt có năm phần:

Phần	Trả lời câu	Ví dụ
URL chính xác	Lỗi ở trang nào?	`corelearn.co/khoa-hoc/web-co-ban`
Thiết bị + trình duyệt	Xảy ra ở đâu?	iPhone 13, Safari · hoặc Windows, Chrome
Bước tái hiện	Làm gì thì ra lỗi?	"Bấm nút Đăng ký → điền email → bấm Gửi"
Kỳ vọng vs thực tế	Đáng lẽ gì / thực tế gì?	"Đáng lẽ hiện 'Cảm ơn'; thực tế nút xoay mãi không xong"
Bằng chứng	Trông thế nào?	Ảnh chụp màn hình / quay màn hình / ảnh tab Console

So sánh nhanh:

❌ "Form đăng ký bị lỗi, sửa giúp."

✅ "Trang corelearn.co/dang-ky, trên iPhone Safari: bấm Gửi sau khi điền email thì nút xoay mãi không xong, không có thông báo. Trên Chrome máy tính thì bình thường. Đính kèm video + ảnh tab Console (có 2 dòng đỏ). Đáng lẽ phải hiện 'Cảm ơn đã đăng ký'."

Bug report cụt vs đủ: bên trái dev phải hỏi lại 5 vòng, bên phải đủ 5 phần nên sửa được ngay.

Cái thứ hai cho dev biết: trang nào, thiết bị nào (gợi ý lỗi chỉ trên mobile Safari), bước tái hiện, và có manh mối từ Console. Họ sửa được ngay, không phải hỏi lại.

Tóm tắt nhanh

Khái niệm	Một dòng
HTML / CSS / JS	Khung xương / lớp da / cơ bắp. Cấu trúc / trình bày / hành vi
Semantic HTML	Dùng đúng tag mang đúng nghĩa — `h1`, `title`, `alt` là chuyện SEO
CSS đổi hình thức	Không đổi nội dung; sửa chữ = CMS, sửa màu/font = CSS
JavaScript = tracking	Pixel/GA chạy bằng JS; chặn JS = mất số; tính năng "động" hỏng = nghi JS
DevTools	Chuột phải → Kiểm tra. Elements / Console / Network. Chỉ đọc
Bug report 5 phần	URL · thiết bị+trình duyệt · bước tái hiện · kỳ vọng vs thực tế · bằng chứng

Thử thực hành

Soi một trang của bạn. Mở DevTools (chuột phải → Kiểm tra). Dùng tab Elements tìm: tiêu đề chính có phải h1 thật không? Ảnh chính có alt không?
Đếm lỗi Console. Mở tab Console trên trang đó — có dòng đỏ nào không? (Không cần hiểu, chỉ cần đếm.)
Viết một bug report. Chọn một lỗi thật (hoặc giả định) trên trang bạn, viết đủ 5 phần. Gửi thử cho dev và xem họ có hỏi lại không.

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

Tôi đổi chữ trên trang nhưng không lên — lỗi gì? Nội dung là HTML, thường sửa trong CMS. Nếu sửa trong CMS rồi mà chưa lên, có thể là cache (trang đang phục vụ bản cũ) — thử ẩn danh (M1). Nếu đổi màu/khoảng cách không được thì đó là CSS, cần dev.

Số trên Google Analytics ít hơn thực tế, có phải tracking hỏng? Không hẳn. Một phần khách chặn JavaScript/quảng cáo nên pixel không bắn — GA luôn thấp hơn thực tế đôi chút. Chỉ nghi hỏng khi số tụt đột ngột — lúc đó mở tab Network kiểm tra pixel có bắn không.

Tôi sửa trong DevTools thấy đẹp hơn, lưu lại được không? Không. DevTools chỉ sửa tạm trên máy bạn, tải lại là mất. Nó để xem và thử, không phải để sửa thật. Muốn sửa thật phải vào CMS hoặc nhờ dev.

Sai lầm thường gặp

Báo "web bị lỗi" cụt lủn. Thiếu URL + thiết bị + bước tái hiện = dev phải hỏi lại, tốn rất nhiều thời gian.
Nhầm sửa nội dung với sửa giao diện. Đổi chữ = HTML/CMS; đổi màu/font/layout = CSS. Yêu cầu sai chỗ làm dev bối rối.
Tưởng tiêu đề to là h1. Mắt thường không phân biệt được h1 thật với div phóng cỡ chữ — phải mở Elements mới biết. Đây là lỗi SEO ẩn rất phổ biến.
Quên kiểm tra trên mobile. Nhiều lỗi chỉ xuất hiện trên một thiết bị/trình duyệt; báo cáo không ghi thiết bị làm dev không tái hiện được.

Giới hạn

Đọc-hiểu không thay được dev. Bạn sẽ phát hiện và mô tả lỗi chính xác hơn nhiều — nhưng việc sửa HTML/CSS/JS thật vẫn nên để người có chuyên môn, vì một thay đổi nhỏ sai chỗ có thể làm hỏng phần khác hoặc làm rớt tracking. Mục tiêu đúng của module: bạn thành một người báo lỗi giỏi và một người đọc trang tự tin, không phải một lập trình viên nửa mùa.

Bước tiếp theo

Bạn đã đọc được khung xương của trang và biết báo lỗi đúng cách. Câu hỏi tiếp theo của một người làm content: những tấm ảnh và video tôi đưa lên trang — vì sao chúng mờ, nặng, hay bị crop?

→ Asset cho web dạy bạn chọn định dạng ảnh đúng, hiểu resolution vs kích thước, nén không vỡ, và xuất video đúng tỉ lệ cho YouTube và Instagram.