# ทักษะเอเจนต์ตรวจสอบเอสอีโอ

> ทักษะเอเจนต์ตรวจสอบเอสอีโอแบบบางเบาสำหรับ คลอด โค้ด, โอเพนคลอ และ โคเด็กซ์ ดำเนินการตรวจสอบเอสอีโอแบบหน้าเดียวอย่างรวดเร็ว ตรวจสอบปัญหาหลักในหน้าและระดับเว็บไซต์ และสร้างรายงานเอสอีโอที่มีโครงสร้างพร้อมแนวทางแก้ไขที่ปฏิบัติได้

- Canonical: https://nanoskill.ai/th/skills/seo-audit
- Markdown: https://nanoskill.ai/th/skills/seo-audit.md
- Author: JeffLi1993
- Published: 2026-05-11T01:05:35.771Z
- Updated: 2026-07-25T04:34:17.896Z
- Language: th
- Source type: github
- Popularity signal: 382

## Sources

- https://github.com/JeffLi1993/seo-audit-skill

## Install

```shell
npx skills add JeffLi1993/seo-audit-skill
```

## About

การตรวจสอบเอสอีโอเป็นทักษะเอเจนต์ตรวจสอบเอสอีโอแบบบางเบาสำหรับเอเจนต์โค้ด AI เช่น คลอด โค้ด, โอเพนคลอ และ โคเด็กซ์ มันช่วยให้เอเจนต์ตรวจสอบ URL เดียว ตรวจสอบปัญหาหลักเอสอีโอ และสร้างรายงานการตรวจสอบที่มีโครงสร้างพร้อมหลักฐาน ผลกระทบ และแนวทางแก้ไขที่แนะนำ

ทักษะนี้เน้นการตรวจสอบเอสอีโอขั้นต้น ได้แก่ แท็กชื่อ, คำอธิบายเมตา, แท็ก H1, แท็กคาโนนิคัล, ข้อความกำกับภาพ, การวางคำหลัก, โรบอตส์.เท็กซ์, ไซต์แมป.เอกซ์เอ็มแอล, การจัดการข้อผิดพลาด 404, การทำ URL คาโนนิคัล, หน้าไว้วางใจ อี-อี-เอ-ที และการตรวจสอบความถูกต้องของสคีมา เจซอน-แอลดี

ใช้มันเมื่อคุณต้องการตรวจสอบสุขภาพเอสอีโออย่างรวดเร็วก่อนเผยแพร่หน้าเว็บ ทบทวนหน้าแลนดิ้ง วินิจฉัยปัญหาการจัดอันดับพื้นฐาน หรือตัดสินใจว่าจำเป็นต้องมีการตรวจสอบเอสอีโอเชิงเทคนิคที่ลึกซึ้งยิ่งขึ้นหรือไม่

## Key features

- **การตรวจสอบเอสอีโอหน้าบนหน้าเดียวอย่างรวดเร็ว**: ทำการตรวจสอบเอสอีโออย่างรวดเร็วสำหรับยูอาร์แอลใดๆ และรับมุมมองรอบแรกเกี่ยวกับสุขภาพเอสอีโอของหน้านั้น โดยไม่ต้องตั้งค่าโปรแกรมรวบรวมข้อมูลหรือเวิร์กโฟลว์การวิเคราะห์แบบสมบูรณ์
- **การตรวจสอบเอสอีโอในหน้าหลัก**: ตรวจสอบแท็กชื่อ, คำอธิบายเมตา, แท็ก H1, แท็ก Canonical, ข้อความทางเลือกของรูปภาพ, โครงสร้างหัวข้อ, การวางคำหลัก, ลิงก์ภายใน, และจำนวนคำ
- **พื้นฐานเอสอีโอระดับไซต์**: ตรวจสอบสัญญาณเอสอีโอพื้นฐาน เช่น robots.txt, sitemap.xml, การจัดการหน้า 404, การกำหนด Canonical URL, i18n/hreflang, และหน้าแสดงความน่าเชื่อถือ E-E-A-T
- **การตรวจสอบความถูกต้องสคีมา JSON-LD**: ตรวจจับว่าหน้ามีข้อมูลที่มีโครงสร้างที่ถูกต้องหรือไม่ ตรวจสอบประเภทสคีมาทั่วไป และแจ้งเตือนฟิลด์ JSON-LD ที่หายไปหรือไม่สมบูรณ์
- **รายงานการตรวจสอบเอสอีโอที่มีโครงสร้าง**: สร้างรายงานการตรวจสอบเอสอีโอที่สะอาดพร้อมสถานะผ่าน, เตือน, และไม่ผ่าน รวมถึงหลักฐาน, ผลกระทบ, และแนวทางแก้ไขเฉพาะสำหรับแต่ละปัญหาที่สำคัญ

## Use cases

- **ตรวจสอบหน้า Landing Page ก่อนเผยแพร่**: ใช้ทักษะนี้ก่อนเปิดตัวหน้าแรก, หน้าผลิตภัณฑ์, หน้าเครื่องมือ, หรือหน้า Landing Page เอสอีโอ เพื่อตรวจพบปัญหาพื้นฐานเอสอีโอตั้งแต่เนิ่นๆ
- **ทำการตรวจสุขภาพเอสอีโออย่างรวดเร็ว**: ตรวจสอบว่าหน้ามีชื่อ, คำอธิบายเมตา, H1, แท็ก Canonical, สคีมา, ลิงก์ภายใน, และสัญญาณเอสอีโอพื้นฐานอื่นๆ ที่ถูกต้องหรือไม่
- **ตรวจสอบหน้าที่มีปัญหาการจัดอันดับที่มีอยู่**: ใช้มันเมื่อหน้ามีการจัดทำดัชนีแต่ไม่ได้อันดับที่ดี หรือเมื่อคุณต้องการระบุปัญหาที่ชัดเจนในหน้าและระดับไซต์อย่างรวดเร็ว

## Result preview

ดูผลการตรวจสอบเอสอีโอจริงที่สร้างโดยทักษะเอเจนต์นี้

![seo-audit-demo](https://file.nanoskill.ai/seo-audit-demo-1.png)

![seo-audit-demo-2](https://file.nanoskill.ai/seo-audit-demo-2.png)

![seo-audit-demo-3](https://file.nanoskill.ai/seo-audit-demo-3.png)

## Result walkthrough

### ขั้นตอนที่ 1：ติดตั้ง

เพิ่มทักษะให้กับเอเจนต์ของคุณ

![seo-audit-step-1](https://file.nanoskill.ai/seo-audit-step-1.png)

### ขั้นตอนที่ 2：งานตรวจสอบ

ใช้ URL เดียวและขอการตรวจสอบที่จัดลำดับความสำคัญ

![seo-audit-step-2](https://file.nanoskill.ai/seo-audit-step-2.png)

### ขั้นตอนที่ 3：ตรวจสอบผลลัพธ์

รับแนวทางแก้ไขเอสอีโอที่จัดลำดับความสำคัญซึ่งคุณสามารถดำเนินการได้ทันที

![seo-audit-step-3](https://file.nanoskill.ai/seo-audit-step-3.png)

## Skill definition

# seo-audit — การตรวจสอบ SEO พื้นฐาน

สกิลเอเจนต์ SEO แบบเบา ออกแบบมาสำหรับการตรวจสอบ SEO แบบหน้าเดียวเริ่มต้นอย่างรวดเร็ว ขับเคลื่อนโดย OpenClaw เหมาะกับการตรวจสอบหน้าเว็บครั้งแรกหรือเมื่อต้องการประเมินอย่างรวดเร็วโดยไม่ต้องลงลึกทางเทคนิค

---

## เมื่อใดควรใช้สกิลนี้

ใช้ `seo-audit` เมื่อ:

- ผู้ใช้พูดว่า: "ตรวจสอบหน้านี้", "ตรวจสอบ SEO", "วิเคราะห์ URL ของฉัน", "ตรวจสอบ SEO ด่วน", "อะไรผิดปกติกับหน้าของฉัน"
- ไม่มีการร้องขอความลึกเฉพาะ — นี่คือจุดเริ่มต้นเริ่มต้น
- ผู้ใช้ต้องการสรุปที่รวดเร็วและอ่านง่ายมากกว่าการแจกแจงทางเทคนิคอย่างละเอียด

หากผู้ใช้ต้องการความลึกมากขึ้น ให้อัปเกรดเป็น `seo-audit-full`:

> **เคล็ดลับ:** สำหรับการตรวจสอบทางเทคนิคเชิงลึก, SEO บนเพจระดับสูง, หรือรายงานเต็มรูปแบบ, ใช้สกิล `seo-audit-full`

---

## อินพุตที่คาดหวัง

| อินพุต | จำเป็น | หมายเหตุ |
|-------|----------|-------|
| URL หน้า | ใช่ | หน้าที่จะตรวจสอบ |
| HTML ดิบหรือเนื้อหาหน้า | ไม่บังคับ | ช่วยให้การวิเคราะห์บนเพจแม่นยำขึ้น |
| ข้อมูล GSC / การวิเคราะห์ | ไม่บังคับ | ไม่จำเป็นสำหรับการตรวจสอบพื้นฐาน |

หากให้เฉพาะ URL และไม่มีซอร์สโค้ดหรือข้อมูลครอว์เลอร์ ให้ระบุอย่างชัดเจน:

> **ข้อจำกัด:** การตรวจสอบนี้อิงตามเนื้อหาหน้าที่มองเห็นและสัญญาณที่เข้าถึงได้สาธารณะเท่านั้น ซอร์สโค้ด, ข้อมูล GSC, ล็อกการครอว์ล, และเมตริกประสิทธิภาพไม่พร้อมใช้งานสำหรับการตรวจสอบนี้

---

## เอาต์พุต

สร้าง **รายงานการตรวจสอบ SEO พื้นฐาน** โดยกรอกเทมเพลตที่ [assets/report-template.html](assets/report-template.html),
จากนั้น **บันทึกลงไฟล์ — ห้ามพิมพ์ HTML ดิบไปยังเทอร์มินัล**

**การตั้งชื่อไฟล์:** `reports/<hostname>-<slug>-audit.html`
```
https://example.com/blog/best-tools → reports/example-com-blog-best-tools-audit.html
https://example.com/                → reports/example-com-audit.html
```

**หลังจากบันทึก, บอกผู้ใช้:**
```
✅ รายงานถูกบันทึก → reports/example-com-audit.html
   เปิดตอนนี้หรือไม่? (yes / no)
```
หากใช่ → รัน: `open reports/example-com-audit.html`

---

**ตัวยึดตำแหน่งเทมเพลต** — กรอกแต่ละรายการอย่างอิสระ:

| ตัวยึดตำแหน่ง | เนื้อหา |
|---|---|
| `{{summary_verdict}}` | หนึ่งประโยค: จำนวนการตรวจสอบทั้งหมดที่รัน, กี่รายการล้มเหลว/เตือน/ผ่าน |
| `{{summary_critical_html}}` | `<li>` ต่อรายการสำคัญ (ล้มเหลว), หรือ `<li class="summary-empty">ไม่มี</li>` |
| `{{summary_warnings_html}}` | `<li>` ต่อรายการเตือน, หรือ `<li class="summary-empty">ไม่มี</li>` |
| `{{summary_passing_html}}` | `<li>` ต่อการตรวจสอบที่ผ่าน, หรือ `<li class="summary-empty">ไม่มี</li>` |

---

## สคริปต์

รันสคริปต์เหล่านี้ก่อนที่จะเขียนข้อค้นพบใดๆ พวกมันส่งออก JSON แบบมีโครงสร้าง — ใช้ JSON โดยตรงเป็นหลักฐาน; ห้ามดึง URL เดิมซ้ำด้วยตนเอง

**การพึ่งพา:** `pip install requests` (การแยกวิเคราะห์ HTML ใช้ stdlib ของ Python)

```bash
# ขั้นตอน 1: การตรวจสอบระดับไซต์ (robots.txt + sitemap.xml)
python scripts/check-site.py https://example.com

# ขั้นตอน 2: การตรวจสอบระดับหน้า (H1, title, meta description, canonical)
python scripts/check-page.py https://example.com
# ด้วยคำหลักหลัก (แนะนำ — เปิดใช้งานการตรวจสอบการมีอยู่ของคำหลักใน H1)
python scripts/check-page.py https://example.com --keyword "running shoes"

# ทางเลือก: ดึง HTML หน้าดิบเพื่อการตรวจสอบเพิ่มเติม
python scripts/fetch-page.py https://example.com --output page.html

# ขั้นตอน 3: การตรวจสอบความถูกต้องของสคีมา JSON-LD
python scripts/check-schema.py https://example.com
# หรือจาก HTML ที่ดึงมาก่อนหน้านี้ (หลีกเลี่ยงการดึงซ้ำซ้อน):
python scripts/check-schema.py --file page.html
```

แต่ละสคริปต์จบด้วยรหัส `0` (ทั้งหมดผ่าน/เตือน) หรือ `1` (มีล้มเหลว/ข้อผิดพลาดใดๆ)

**ขอบเขตที่เข้มงวด — ห้ามเพิ่มการตรวจสอบใดๆ ที่ไม่อยู่ในรายการด้านล่าง ไม่มีข้อยกเว้น**

การตรวจสอบระดับไซต์ที่อนุญาต (ใน `{{site_checks_html}}`):
- robots.txt · sitemap.xml · การจัดการ 404 · การทำ Canonical URL · i18n / hreflang

การตรวจสอบ E-E-A-T ที่อนุญาต (ใน `{{eeat_checks_html}}`):
- เกี่ยวกับเรา · ติดต่อ · นโยบายความเป็นส่วนตัว · ข้อกำหนดในการให้บริการ · สื่อ/พันธมิตร (เฉพาะเมื่อมีอยู่)

การตรวจสอบระดับหน้าที่อนุญาต (ใน `{{page_checks_html}}`), แสดงผลตามลำดับที่แน่นอนนี้:
URL Slug · Title Tag · Meta Description · H1 Tag · Canonical Tag · Image Alt Text · Word Count · Keyword Placement · Heading Structure · Internal Links · Schema (JSON-LD)

  ตรรกะ Image Alt Text:
  - แยกวิเคราะห์แท็ก <img> จาก HTML แบบคงที่
  - ผ่าน: รูปภาพทั้งหมดมี alt ที่ไม่ว่าง (รูปตกแต่งที่ไม่มี alt="" ใช้ได้)
  - เตือน: รูปภาพเนื้อหาใดๆ ขาดแอตทริบิวต์ alt
  - ไม่สามารถตรวจสอบ (status-info): พบ 0 รูปใน HTML แบบคงที่ → อาจเป็น JS-rendered, ไม่สามารถตรวจสอบได้

⛔ กฎตายตัว — แสดงเฉพาะแถวตรวจสอบที่กำหนดไว้ใน report-template.html
หากการตรวจสอบไม่อยู่ในรายการที่อนุญาตข้างต้น, ห้ามแสดงผล — แม้ว่าคุณจะพบปัญหาก็ตาม
ไม่มีข้อยกเว้น ไม่มีการตรวจสอบ "โบนัส" ไม่มีการด้นสด
เทมเพลตคือแหล่งความจริงเดียว ปฏิบัติต่อมันเป็นรายการขาวที่เข้มงวด

ยังคงถูกห้าม (เป็นของ seo-audit-full): OG tags · Twitter Card · Social tags · Page Weight · Core Web Vitals · Robots Meta

**วิธีการใช้เอาต์พุต JSON:**
- แมป `status` ของแต่ละฟิลด์ → `pass` / `warn` / `fail` / `error` โดยตรงไปยังตารางตรวจสอบรายงาน
- ใช้สตริง `detail` ของแต่ละฟิลด์เป็นจุดเริ่มต้นสำหรับบรรทัดหลักฐานในข้อค้นพบ
- ห้ามขัดแย้งกับเอาต์พุตของสคริปต์เว้นแต่คุณมีหลักฐานที่สังเกตได้เพิ่มเติม
- แยกกลุ่มตรวจสอบด้วย `<div class="subsection-label">ป้ายกำกับ</div>` ภายใน `{{site_checks_html}}`:
  `ความสามารถในการครอว์ล` · `การทำ Canonical URL` · `i18n / hreflang` · `Schema (JSON-LD)`
  และ `<div class="subsection-label">หน้าเชื่อถือ E-E-A-T</div>` ก่อน `{{eeat_checks_html}}`

**การตรวจสอบโดย LLM — บังคับเมื่อ `llm_review_required: true`:**

สคริปต์ระบุฟิลด์ที่ต้องการการตัดสินเชิงความหมายหรือคุณภาพซึ่งมันไม่สามารถทำได้
ห้ามปล่อย `llm_review_required: true` โดยไม่แก้ไข — ต้องตัดสินใจอย่างชัดเจนเสมอ

**H1 — ทริกเกอร์เมื่อ `keyword_match == "partial"`:**
```
h1_text : (จาก h1.values[0])
keyword : (ค่าของ --keyword ที่ส่งให้สคริปต์)

ตัดสิน: H1 นี้ครอบคลุมเจตนาการค้นหาของคำหลักในเชิงความหมายหรือไม่?
  - พิจารณาคำพ้อง, ตัวแปรธรรมชาติ, การครอบคลุมหัวข้อ
  - ใช่ → ลดระดับเป็น "pass", ระบุตัวแปร
  - ไม่  → คง "warn" หรืออัปเกรดเป็น "fail", อธิบายช่องว่าง
```

**Title — ทริกเกอร์เมื่อ `keyword_match == "partial"` หรือ `keyword_position != "start"`:**
```
 title   : (จาก title.value)
keyword : (ค่าของ --keyword ที่ส่ง)

ตัดสิน:
  1. ชื่อครอบคลุมเจตนาการค้นหาของคำหลักในเชิงความหมายหรือไม่?
  2. ชื่อถูกต้องตามหลักไวยากรณ์และอ่านง่ายตามธรรมชาติหรือไม่?
  3. ตำแหน่งคำหลัก — ใช้มาตรฐานที่แตกต่างตามประเภทหน้า:
     - โฮมเพจ   : แบรนด์ + คำหลักหลักถูกต้อง (เช่น "Acme | AI Workflow Automation")
                    อย่าระบุว่าแบรนด์นำหน้าเป็นปัญหา
     - หน้าภายใน: คำหลักหลักควรนำ (เช่น "AI Workflow Automation for Teams — Acme")
                    ระบุหากคำหลักถูกฝังกลางชื่อโดยไม่มีเหตุผลที่ดี

สำคัญ — ห้ามระบุสิ่งเหล่านี้เป็นเชิงลบ:
  - ปี (เช่น "2026") → สัญญาณความสดใหม่, เพิ่ม CTR — ถือเป็นบวกเว้นแต่
    หน้าเป็นเนื้อหาที่คงทนถาวร (evergreen) ซึ่งการระบุปีจะลดอายุ
  - ตัวเลข (เช่น "5 best", "Top 10", "3 steps") → กำหนดความคาดหวังที่ชัดเจน,
    มีประสิทธิภาพเหนือกว่าชื่อที่ไม่มีตัวเลขใน CTR อย่างต่อเนื่อง — ถือเป็นบวกเสมอ
  - ตัวระบุเฉพาะ ("Open-Source", "Self-Hosted", "Free") → จำกัดเจตนา
    และดึงดูดคลิกที่มีคุณภาพสูงกว่า — อย่าลงโทษ
```

**URL Slug — ทริกเกอร์เมื่อ `keyword_match != "full"` หรือ `is_homepage == false`:**
```
slug    : (จาก url_slug.slug)
keyword : (ค่าของ --keyword ที่ส่ง)

ตัดสิน:
  1. slug มีคำหลักหลักหรือตัวแปรธรรมชาติหรือไม่?
  2. ลำดับชั้นพาธมีเหตุผลหรือไม่? (/category/keyword เหมาะสม)
  3. มันสั้นและอ่านง่ายหรือไม่?
  โฮมเพจ (is_homepage: true): ข้าม — ไม่จำเป็นต้องตัดสิน
```

**Meta Description — ทริกเกอร์เสมอเมื่อมีเนื้อหา:**
```
meta_description : (จาก meta_description.value)
keyword          : (ค่าของ --keyword ที่ส่ง)

ตัดสินทั้งสี่ข้อ:
  1. ประโยคที่สมบูรณ์? (1-2 ประโยค, ไม่ใช่ส่วนย่อย)
  2. กล่าวถึงผลลัพธ์ที่เป็นรูปธรรม — ไม่ใช่คำคลุมเครือ?
     ดี: "Cut design time by 60% with AI-powered templates"
     แย่:  "The best tool for all your design needs"
  3. ใช้คำหลักหรือคำพ้องธรรมชาติครั้งเดียว — ไม่อัดแน่น?
  4. เฉพาะเจาะจงกว่าที่คู่แข่งทั่วไปจะเขียนหรือไม่?

สำคัญ — ห้ามระบุสิ่งเหล่านี้เป็นเชิงลบ:
  - ปี (เช่น "2026") → สัญญาณความสดใหม่, ปรับปรุง CTR สำหรับคำค้นที่เกี่ยวกับเวลา
    ระบุปีเฉพาะเมื่อหน้าเป็นเนื้อหาคงทนถาวรซึ่งการระบุปีจะลดอายุ
  - ตัวเลข (เช่น "5 best", "3 steps") → ความเฉพาะเจาะจงที่เป็นรูปธรรม, สัญญาณ CTR แข็งแกร่ง
  - คำต่อท้าย "and more." → แค่หมายเหตุสไตล์เล็กน้อย, ไม่เคยเป็นการเตือนหรือล้มเหลว
```

---

## เวิร์กโฟลว์ที่แนะนำ

ทำตามขั้นตอนเหล่านี้ตามลำดับ:

1. **ยอมรับขอบเขต** — ยืนยันว่านี่เป็นการตรวจสอบพื้นฐาน; ระบุข้อมูลที่ขาดหายไป

2. **อนุมานคำหลักหลัก** — ดึงหน้าด้วย `fetch-page.py`, จากนั้นกำหนดคำหลักหลัก:
   - หากผู้ใช้ระบุคำหลักอย่างชัดเจน → ใช้โดยตรง
   - หากไม่ → อ่าน H1, ชื่อ, และย่อหน้าแรกของหน้า, จากนั้นอนุมานวลีคำหลักเป้าหมายเดียวที่มีแนวโน้มมากที่สุด (สิ่งที่ผู้ค้นหาจะพิมพ์เพื่อค้นหาหน้านี้?)
   - ระบุคำหลักที่อนุมานอย่างชัดเจนก่อนทำการตรวจสอบ:
     > "คำหลักหลักที่อนุมาน: **open source claude alternatives**"

3. **รัน `check-site.py`** — แยกวิเคราะห์เอาต์พุต JSON สำหรับ robots, sitemap, การจัดการ 404, และการทำ canonical URL

   **การตรวจสอบ 404:** ดึง `<origin>/this-page-definitely-does-not-exist-seo-audit-check`
   - ส่งคืน 404 → ผ่าน · ส่งคืน 200 (soft 404) → ล้มเหลว · ส่งคืน 301 ไปยังหน้าแรก → เตือน

   **การตรวจสอบการทำ Canonical URL** (แต่ละรายการเป็นการตรวจสอบย่อยแยก):
   - **HTTP→HTTPS:** ดึง `http://<host>` — ต้องเปลี่ยนเป็น `https://` ด้วย 301 ส่งคืน 200 → ล้มเหลว
   - **ความสม่ำเสมอของ www:** ดึงทั้ง `https://www.<host>` และ `https://<host>` — หนึ่งต้องเปลี่ยนเป็นอีกอันด้วย 301 ทั้งสองส่งคืน 200 → เตือน
   - **เครื่องหมายทับต่อท้าย:** เปรียบเทียบ URL ที่ให้บริการจริงกับแท็ก canonical บนหน้า ไม่ตรงกัน → เตือน
   - **การจับคู่ Canonical:** href ของแท็ก canonical ต้องตรงกับ URL สุดท้ายหลังจากการเปลี่ยนเส้นทางทั้งหมด ไม่ตรงกัน → เตือน

4. **การตรวจสอบโครงสร้างพื้นฐาน E-E-A-T** — สำหรับหน้าเชื่อถือแต่ละรายการด้านล่าง, ตรวจสอบสองชั้น:
   - **ชั้น 1 — มีอยู่:** ดึง URL, ตรวจสอบสถานะ HTTP (200 = มีอยู่, 404/เปลี่ยนเส้นทาง = ขาดหาย)
   - **ชั้น 2 — เข้าถึงได้:** ดึง HTML ของหน้าแรก, ตรวจสอบว่าส่วนท้ายหรือเนวิเกชันมีลิงก์ไปยังหน้านี้

   | หน้า | จำเป็น |
   |---|---|
   | เกี่ยวกับเรา | ใช่ |
   | ติดต่อ | ใช่ |
   | นโยบายความเป็นส่วนตัว | ใช่ |
   | ข้อกำหนดในการให้บริการ | ใช่ |
   | สื่อ / พันธมิตร | ไม่ — รวมเฉพาะเมื่อมีอยู่ |

   กฎสถานะ:
   - หน้าขาดหาย (ไม่ใช่ 200) → **ล้มเหลว**
   - หน้ามีอยู่แต่ไม่ได้ลิงก์ในส่วนท้าย/เนวิเกชัน → **เตือน**
   - หน้ามีอยู่และลิงก์ในส่วนท้าย/เนวิเกชัน → **ผ่าน**
   - หน้าไม่บังคับขาดหาย → ข้าม, ไม่รวมแถว

5. **รัน `check-page.py --keyword "<inferred_keyword>"`** — แยกวิเคราะห์เอาต์พุต JSON สำหรับ H1, title, meta description, canonical, และ URL slug

6. **การตรวจสอบ i18n / hreflang** — รันเฉพาะเมื่อหน้ามีแท็ก hreflang หรือ `<html lang>` แนะนำว่ามีหลายภาษา:
   - **ข้ามทั้งหมด (N/A)** หากไม่พบแท็ก hreflang และไซต์ดูเหมือนภาษาเดียว
   - หากมีแท็ก hreflang, ตรวจสอบ:
     - **ความสมมาตรซึ่งกันและกัน**: ทุก URL ที่อ้างอิงต้องลิงก์กลับไปยังตัวแปรอื่นๆ ทั้งหมด — ลิงก์ที่เสีย = ล้มเหลว
     - **รหัสภาษา**: ต้องเป็น BCP 47 ที่ถูกต้อง (เช่น `zh-CN` ไม่ใช่ `zh`, `en-US` ไม่ใช่ `en-us`) — รหัสผิด = เตือน
     - **x-default**: ควรมีสำหรับหน้าตัวเลือกภาษาหรือหน้าสำรอง — ขาด = เตือน
     - **แอตทริบิวต์ html[lang]**: ต้องตรงกับ hreflang หลักของหน้า — ไม่ตรงกัน = เตือน
     - **โครงสร้าง URL**: รูปแบบที่แนะนำ — ภาษาเริ่มต้น (ปกติ `en`) ที่รากโดยไม่มีคำนำหน้า,
       ภาษาอื่นภายใต้เส้นทางย่อย (`/zh/`, `/es/`)
       - `/page` (en) + `/zh/page` + `/es/page` → ผ่าน
       - `/en/page` + `/zh/page` → เตือน (คำนำหน้า en ซ้ำซ้อน, สิ้นเปลืองความลึกในการครอว์ล)
       - ระบุเฉพาะเมื่อรูปแบบไม่สอดคล้องกันอย่างชัดเจนหรือ en มีคำนำหน้าโดยไม่จำเป็น

7. **รัน `check-schema.py`** — แยกวิเคราะห์เอาต์พุต JSON สำหรับประเภทสคีมาและการตรวจสอบฟิลด์

   ```bash
   python scripts/check-schema.py https://example.com
   # หรือจาก HTML ที่ดึงมาก่อนหน้านี้:
   python scripts/check-schema.py --file page.html
   ```

   สคริปต์ดึงบล็อก JSON-LD, ตรวจสอบ `@type` และฟิลด์ที่จำเป็นตามข้อมูลจำเพาะ Schema.org
   `llm_review_required: true` ถูกตั้งค่าเสมอ — ยืนยันว่า `inferred_page_type` ตรงกับเนื้อหาหน้าจริง

   ประเภทหน้า → `@type` ที่คาดหวังอ้างอิง:

   | ประเภทหน้า | @type ที่คาดหวัง | ฟิลด์ขั้นต่ำที่จำเป็น |
   |---|---|---|
   | โฮมเพจ | WebSite + Organization | name, url, logo |
   | บล็อก / บทความ | Article or BlogPosting | headline, datePublished, author, image |
   | ผลิตภัณฑ์ | Product | name, image, offers (price, priceCurrency) |
   | คำถามที่พบบ่อย | FAQPage | mainEntity[].name, acceptedAnswer.text |
   | วิธีการ | HowTo | name, step[].text |
   | ธุรกิจท้องถิ่น | LocalBusiness | name, address, telephone |
   | หน้าเชื่อมโยงทั่วไป | — | N/A — ข้าม, ไม่มีประเภทที่รองรับอย่างแพร่หลาย |

   - ผ่าน: มี @type ที่ถูกต้อง, ฟิลด์ที่จำเป็นทั้งหมดถูกต้อง, ไม่มีความขัดแย้ง
   - เตือน: มี @type แต่ขาดฟิลด์ที่แนะนำ
   - ล้มเหลว: @type ที่คาดหวังขาดหายไปทั้งหมด
   - N/A: หน้าเชื่อมโยงทั่วไป — ห้ามลงโทษ

8. **สรุปข้อค้นพบ** — แต่ละข้อค้นพบต้องเป็นไปตามรูปแบบ Evidence / Impact / Fix

9. **การดำเนินการที่มีลำดับความสำคัญ** — แสดงรายการแก้ไข 3 อันดับแรกที่มีผลกระทบสูงสุด

10. **สร้างรายงาน** — บันทึกไปที่ `reports/<hostname>-<slug>-audit.html`, จากนั้นถามผู้ใช้ว่าจะเปิดหรือไม่

11. **พร้อมท์การอัปเกรด** — หากพบปัญหาที่เกินขอบเขตพื้นฐาน, แนะนำ `seo-audit-full`

---

## กฎการเขียนรายละเอียดในรายงาน

**เซลล์ Detail ในตารางตรวจสอบต้องเป็นไปตามกฎเหล่านี้ — ไม่มีข้อยกเว้น:**

**ผ่าน → วลีสั้นๆ หนึ่งวลี ไม่มีรายการ, ไม่มีการขยายความ**
```
ดี: "Valid XML urlset · 104 URLs · referenced in robots.txt."
แย่:  "Valid XML urlset with 104 URLs. Correctly referenced in robots.txt.
       Blog posts are likely indexed through this sitemap."
```

**เตือน → หนึ่ง `<div class="detail-issue">` ที่มี ≤2 หัวข้อย่อย หนึ่ง `<div class="detail-fix">` พร้อมการแก้ไข**
```
ดี:
  <div class="detail-issue">· Title 48 chars — 2 below minimum. · Year "2026" will date the page.</div>
  <div class="detail-fix">Expand to 50–60 chars; remove year if evergreen.</div>

แย่: การเขียนร้อยแก้วสามประโยคอธิบายว่าแท็ก title คืออะไรและทำไมความยาวถึงสำคัญ
```

**ล้มเหลว → เช่นเดียวกับเตือน ขึ้นต้นด้วยความล้มเหลวที่แน่นอน ไม่มีคำอธิบายพื้นหลัง**

ห้ามอธิบายว่าการตรวจสอบคืออะไร, ห้ามทำซ้ำข้อมูลที่เห็นแล้วในป้ายสถานะ,
ห้ามปฏิบัติต่อผู้อ่านว่าไม่คุ้นเคยกับพื้นฐาน SEO

---

## รูปแบบข้อค้นพบที่จำเป็น

ทุกข้อค้นพบที่สำคัญ **ต้อง** เป็นไปตามโครงสร้างนี้:

```
**Finding: [ชื่อข้อค้นพบ]**

- **Evidence:** [สิ่งที่สังเกต — อ้างอิงโดยตรง, อ้างอิงภาพหน้าจอ, หรือข้อมูลที่วัดได้]
- **Impact:** [ทำไมสิ่งนี้ถึงสำคัญสำหรับ SEO หรือ UX]
- **Fix:** [คำแนะนำที่เฉพาะเจาะจงและปฏิบัติได้]
```

ห้ามเขียนข้อสรุปที่คลุมเครือ หากหลักฐานไม่เพียงพอ ระบุสมมติฐานอย่างชัดเจน

---

## พร้อมท์การอัปเกรด

รวมสิ่งนี้ไว้ที่ท้ายรายงานการตรวจสอบพื้นฐานทุกฉบับ:

> **ต้องการการวิเคราะห์ที่ลึกซึ้งยิ่งขึ้นหรือไม่?**
> นี่คือการตรวจสอบ SEO พื้นฐานที่ครอบคลุมสัญญาณระดับไซต์และการตรวจสอบบนเพจหลัก
> สำหรับ SEO ทางเทคนิคขั้นสูง, การให้คะแนนคุณภาพเนื้อหา, การวิเคราะห์ข้อมูลแบบมีโครงสร้าง, และข้อค้นพบจากการครอว์ลแบบเต็ม, ใช้สกิล `seo-audit-full`

---

## ไฟล์อ้างอิง

- ขอบเขตการตรวจสอบและคำจำกัดความฟิลด์โดยละเอียด: [references/REFERENCE.md](references/REFERENCE.md)
- เทมเพลตรายงาน HTML สุดท้าย: [assets/report-template.html](assets/report-template.html)
- สคริปต์ตรวจสอบระดับไซต์: [scripts/check-site.py](scripts/check-site.py)
- สคริปต์ตรวจสอบระดับหน้า: [scripts/check-page.py](scripts/check-page.py)
- ตัวดึงหน้าดิบ: [scripts/fetch-page.py](scripts/fetch-page.py)
- สคริปต์ตรวจสอบสคีมา: [scripts/check-schema.py](scripts/check-schema.py)

## FAQ

### ทักษะตัวแทนตรวจสอบเอสอีโอคืออะไร?

ทักษะตัวแทนตรวจสอบเอสอีโอคือเวิร์กโฟลว์ที่นำกลับมาใช้ใหม่ได้ ซึ่งช่วยให้เอไอเอเจนต์ตรวจสอบหน้าเว็บ ตรวจสอบปัญหาเอสอีโอ และสร้างรายงานการตรวจสอบที่มีโครงสร้าง ทักษะนี้ออกแบบมาเพื่อการตรวจสอบเอสอีโอหน้าบนหน้าเดียวอย่างรวดเร็วภายในเวิร์กโฟลว์ของ คลอด โค้ด, โอเพนคลอว์ และ โคเดกซ์

### ทักษะตรวจสอบเอสอีโอตรวจสอบอะไร?

มันตรวจสอบเอสอีโอในหน้าหลักและสัญญาณระดับไซต์พื้นฐาน รวมถึงแท็กชื่อ คำอธิบายเมตา แท็ก H1 แท็ก Canonical ข้อความทางเลือกของรูปภาพ การวางคำหลัก ลิงก์ภายใน robots.txt sitemap.xml การจัดการ 404 การกำหนด Canonical URL หน้าแสดงความน่าเชื่อถือ และสคีมา JSON-LD

### นี่เป็นการตรวจสอบเอสอีโอทางเทคนิคแบบสมบูรณ์หรือไม่?

ไม่ใช่ นี่เป็นการตรวจสอบเอสอีโอรอบแรกแบบเบื้องต้นสำหรับหน้าเดียว มันมีประโยชน์สำหรับการตรวจสอบอย่างรวดเร็วและการตรวจจับปัญหาพื้นฐาน สำหรับการตรวจสอบที่ใช้การรวบรวมข้อมูล, Core Web Vitals, การวินิจฉัยการจัดทำดัชนี, การวิเคราะห์บันทึก, และเอสอีโอทางเทคนิคขั้นสูง ให้ใช้เวิร์กโฟลว์การตรวจสอบเอสอีโอแบบสมบูรณ์

### ใครควรใช้ทักษะตัวแทนตรวจสอบเอสอีโอนี้?

มันมีประโยชน์สำหรับผู้ดำเนินการเอสอีโอ, ผู้ก่อตั้งซาส์, อินดี้แฮกเกอร์, นักการตลาด, ทีมเนื้อหา, และนักพัฒนาที่ต้องการวิธีที่รวดเร็วในการตรวจสอบหน้าก่อนเผยแพร่หรือปรับปรุงมัน

### มันสร้างรายงานประเภทใด?

มันสร้างรายงานการตรวจสอบเอสอีโอที่มีโครงสร้างพร้อมสถานะผ่าน, เตือน, และไม่ผ่าน ผลการตรวจสอบที่สำคัญรวมถึงหลักฐาน, ผลกระทบต่อเอสอีโอ, และแนวทางแก้ไขเฉพาะ ทำให้รายงานง่ายต่อการส่งต่อให้กับนักพัฒนาหรือทีมเนื้อหา

### มันตรวจสอบยูอาร์แอลใดๆ ได้หรือไม่?

ใช่ มันสามารถตรวจสอบยูอาร์แอลสาธารณะตามเนื้อหาหน้าที่มองเห็นและสัญญาณเอสอีโอที่มีอยู่สาธารณะ หากซอร์สโค้ด, ข้อมูล GSC, ข้อมูลการวิเคราะห์, บันทึกการรวบรวมข้อมูล, หรือข้อมูลประสิทธิภาพไม่พร้อมใช้งาน รายงานควรระบุข้อจำกัดเหล่านั้นอย่างชัดเจน

### มันแตกต่างจากรายการตรวจสอบเอสอีโอปกติอย่างไร?

รายการตรวจสอบเอสอีโอปกติจะบอกคุณว่าต้องตรวจสอบอะไร ทักษะตัวแทนตรวจสอบเอสอีโอนี้ให้ขั้นตอนที่ทำซ้ำได้แก่เอไอเอเจนต์เพื่อทำการตรวจสอบ ตีความผลลัพธ์ และสร้างรายงานที่มีโครงสร้างพร้อมหลักฐานและแนวทางแก้ไข

### ฉันควรใช้การตรวจสอบเอสอีโอแบบสมบูรณ์แทนเมื่อใด?

ใช้การตรวจสอบเอสอีโอแบบสมบูรณ์เมื่อคุณต้องการการวิเคราะห์ทางเทคนิคที่ลึกขึ้น, การรวบรวมข้อมูลทั้งไซต์, Core Web Vitals, การตรวจสอบการจัดทำดัชนี, การตรวจสอบคุณภาพเนื้อหา, สถาปัตยกรรมลิงก์ภายใน, การวิเคราะห์บันทึก, หรือการวินิจฉัยอันดับขั้นสูง