เว็บควรเช็ก Technical SEO ตรงไหนก่อน

เว็บเปิดได้ไม่ได้แปลว่า Google อ่านเว็บได้ครบ หน้าอาจตอบ 200 แต่ไม่ถูกนำไปแสดงผล

การปรับแต่งเว็บไซต์คือชั้นวิศวกรรมที่รองรับทุกอันดับ คลิก และ conversion จาก SEO ต่อให้เนื้อหาดีที่สุดในตลาด แต่ถ้า Googlebot crawl ไม่ถึง index ไม่ได้ หรือผู้ใช้มือถือโหลดช้า เนื้อหานั้นก็ไม่สามารถทำงานได้เต็มที่ นี่คือเช็กลิสต์ Technical SEO จากการตรวจจริง ครอบคลุมสิ่งที่ควรตรวจเมื่อเริ่มดูแลเว็บไซต์ใน SoarTask โดยเน้นหลักฐานและลำดับความสำคัญ ไม่ใช่การไล่แก้คะแนนให้สวยอย่างเดียว

บทนี้ครอบคลุม 8 ด้านของการตรวจ website SEO: crawlability, indexability, Core Web Vitals, structured data, internal links, mobile, security และความปลอดภัยของการย้ายระบบ แต่ละส่วนมีรายการที่ลงมือทำได้ทันที พร้อมเครื่องมือของ SoarTask ที่ใช้ตรวจซ้ำได้เป็นรอบๆ

1. Crawlability Googlebot เข้าถึงหน้าได้หรือไม่

Crawlability คือพื้นฐานที่สุดของ search optimization ถ้า crawler เข้า URL ไม่ได้ เนื้อหา ลิงก์ และ schema ที่อยู่ในหน้านั้นก็ไม่มีโอกาสช่วยอันดับ ก่อนปรับแต่งส่วนอื่น ให้ยืนยันก่อนว่าหน้าที่ต้องการให้ติดอันดับสามารถเข้าถึงได้จริง

1.1 ตรวจ robots.txt และเส้นทางที่ถูกบล็อก

ไฟล์ robots.txt บอก crawler ว่าอนุญาตให้ดึง path ใดได้บ้าง ข้อผิดพลาดที่พบบ่อยไม่ใช่ไม่มีไฟล์ แต่เป็น Disallow ที่กว้างเกินไป ซึ่งมักถูกคัดลอกจาก staging มายัง production ให้อ่านทุกบรรทัดเทียบกับ URL ที่ควร index จริง

ตรวจให้แน่ใจว่าไฟล์ตอบ HTTP 200 และเป็น text/plain, ไม่มี Disallow ครอบคลุมหน้าสำคัญ, ประกาศ sitemap ด้วย Sitemap: และไม่มี crawl-delay ที่สูงเกินเหตุ สำหรับ URL สำคัญให้ทดสอบด้วย URL Inspection ใน Search Console

1.2 จัดการ crawl budget เมื่อเว็บไซต์ใหญ่

เว็บไซต์ขนาดเล็กที่มีไม่ถึงประมาณ 10,000 URL มักไม่ต้องเสียเวลาปรับ crawl budget มากนัก แต่เว็บ e-commerce ที่มี filter, directory ขนาดใหญ่ หรือหน้า programmatic จำนวนมากอาจต้องลดพื้นที่ที่ crawler เสียเวลาไปกับ URL คุณค่าต่ำ

• ลด URL จาก filter, sort parameter, session ID และ print view ที่ไม่มีคุณค่าค้นหา
• ให้ XML sitemap มีเฉพาะ URL ที่ canonical และ indexable
• ทำให้หน้าสำคัญเข้าถึงได้ภายใน 3–4 คลิกจากหน้าแรก
• ลด duplicate URL ด้วย canonical และการจัดการ parameter ที่สอดคล้องกัน

2. Indexability เมื่อ crawl แล้วจะถูกนำเข้า index หรือไม่

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

2.1 ตรวจ noindex และ nofollow

รวบรวมทุก URL ที่ส่ง noindex ไม่ว่าจะมาจาก <meta name="robots"> หรือ header X-Robots-Tag แล้วเทียบกับรายการหน้าที่ต้องการให้ index ความไม่ตรงกันคือ defect ที่ต้องแก้ สาเหตุที่พบประจำคือ staging flag ติดมาจากช่วงพัฒนา หรือ CMS เปิด “discourage search engines” ค้างไว้

2.2 Canonical และ duplicate content

Canonical เป็นสัญญาณบอก URL หลักเมื่อหลาย URL มีเนื้อหาเหมือนกัน แต่เป็น hint ไม่ใช่คำสั่ง Google อาจไม่ทำตามหากขัดกับสัญญาณอื่น

• ทุกหน้า indexable มี self-referencing canonical เป็น absolute URL
• protocol และ host ของ canonical ตรงกับเว็บไซต์จริง
• URL ที่มี parameter ชี้กลับไปยัง clean base URL
• ไม่ canonical หน้าทุกหน้าของ pagination กลับไป page 1
• canonical ใน HTML สอดคล้องกับ URL ใน sitemap

3. Core Web Vitals วัดประสบการณ์จริง ไม่ใช่ไล่คะแนน

Core Web Vitals เป็นเมตริกประสบการณ์ผู้ใช้มาตรฐานของ Google และเป็นสัญญาณอันดับที่ยืนยันแล้ว แต่เป็นปัจจัยรองหรือตัวตัดสินเมื่อหน้าที่เกี่ยวข้องและคุณภาพใกล้เคียงกัน ให้มองเป็น quality floor ที่ต้องผ่าน ไม่ใช่ ranking lever ที่ต้องหมกมุ่น

เกณฑ์นี้ใช้ field data ที่ percentile 75% ในช่วง 28 วัน ข้อมูลจาก PageSpeed run เดียวเป็น lab data สำหรับหาสาเหตุ ไม่ใช่ตัวตัดสินสถานะจริง ให้ใช้ข้อมูลภาคสนามจากผู้ใช้เพื่อยืนยัน

3.1 Fix ที่มักขยับเมตริกได้จริง

• LCP: preload รูปหลัก ใช้ fetchpriority="high", WebP/AVIF, srcset ที่ขนาดพอดี และลด TTFB ให้ต่ำกว่า 600ms
• INP: แบ่ง long task ที่เกิน 50ms และ defer สคริปต์ analytics, chat และ third-party ที่ไม่จำเป็น
• CLS: ระบุ width/height หรือ aspect-ratio ให้สื่อทุกชิ้น จองพื้นที่ให้เนื้อหาที่โหลดช้า และใช้ font-display: swap

ตรวจ URL ด้วย PageSpeed Checker และติดตามซ้ำในรอบ SEO audit เพื่อดูว่าการแก้ส่งผลต่อประสบการณ์จริงหรือไม่

4. Structured data ช่วยให้ Google เข้าใจเนื้อหา

Structured data คือ JSON-LD ที่อธิบายเนื้อหาด้วย vocabulary ของ schema.org โดยทั่วไปไม่ได้เพิ่มอันดับโดยตรง แต่ช่วยให้เกิด rich results, ช่วยเรื่อง entity understanding และอาจทำให้ CTR ดีขึ้น ใช้เฉพาะ type ที่ตรงกับเนื้อหาที่แสดงจริงบนหน้า และตรวจด้วย Rich Results Test ก่อน deploy

4.1 Type ที่ควรพิจารณา

• Organization / WebSite: identity ของเว็บไซต์และ sitelinks
• Article / BlogPosting: บทความและข้อมูลผู้เขียน
• Product: ราคา availability และรีวิวสำหรับ e-commerce
• FAQ: ใช้เมื่อ Q&A แสดงอยู่ใน HTML จริง
• BreadcrumbList: สะท้อนลำดับชั้นของเว็บไซต์
• LocalBusiness: สำหรับธุรกิจที่มีสถานที่จริง

4.2 ข้อผิดพลาดที่พบบ่อย

• ทำ markup เนื้อหาที่ผู้ใช้มองไม่เห็น
• ใช้ FAQPage แต่ไม่มีคำถามบนหน้า
• ขาด required field หรือมี JSON-LD ซ้ำและขัดแย้งกัน

5. Internal links โครงสร้างที่กระจาย authority

Internal link ช่วยส่ง PageRank และ topical relevance ผ่านเว็บไซต์ หน้าสำคัญควรเข้าถึงได้ภายใน 3–4 คลิก ใช้โครงสร้าง hub-and-spoke ให้บทความเชื่อมกลับ hub และเชื่อมไปยังเนื้อหาที่เกี่ยวข้อง

5.1 Anchor diversity และ guardrails

การใช้ exact-match anchor เดิมซ้ำไปยัง URL เดิมหลายสิบครั้งดูเป็นการปรับแต่งเกินธรรมชาติ SoarTask จึงตรวจ guardrail เหล่านี้แบบ warning mode:

• anchor เดิมต่อ target ไม่เกิน 5 ครั้ง
• inbound link ต่อ URL ไม่เกิน 100
• outbound link ต่อหน้าไม่เกิน 30
• exact-match anchor ratio ต่ำกว่า 50%
• ลิงก์ใหม่ไป URL เดิมไม่เกิน 3 ครั้งต่อเดือน
• anchor diversity score สูงกว่า 0.5 (0 = เหมือนกันทั้งหมด, 1 = หลากหลายเต็มที่)

ตรวจ graph ด้วย Internal Link Checker อ่านแนวทางต่อใน SEO best practices และวัดผลการเปลี่ยนลิงก์จาก SEO analytics and measurement

6. Mobile และ security สิ่งที่ต้องมี ไม่ใช่จุดสร้างความต่าง

Google ใช้ mobile-first indexing กับเว็บไซต์ส่วนใหญ่ จึง crawl และ index เวอร์ชันมือถือเป็นหลัก เนื้อหา ลิงก์ และ structured data บนมือถือควรเทียบเท่า desktop, มี viewport, tap target อย่างน้อย 48×48 CSS pixels และตัวอักษรอ่านได้อย่างน้อย 16px หลีกเลี่ยง interstitial ที่บังเนื้อหา

เว็บไซต์ควรใช้ HTTPS ทุกหน้า, redirect HTTP ไป HTTPS ด้วย 301, ตั้ง Strict-Transport-Security และไม่มี mixed content จาก image, script, stylesheet หรือ iframe ที่ยังเป็น HTTP

7. Migration safety จุดที่ทำให้ SEO เสียหายหนักที่สุด

การเปลี่ยนโดเมน ย้าย platform redesign หรือย้าย HTTP เป็น HTTPS เป็นเหตุการณ์ความเสี่ยงสูงสุดของ Technical SEO ก่อนย้ายให้ crawl เว็บเดิมและเก็บ URL inventory, ทำ redirect map แบบ 1:1, เตรียม 301, คง title/meta/H1/schema ที่ดีไว้ และอัปเดต sitemap กับ internal link ให้ชี้ URL ใหม่โดยตรง

7.1 ตรวจหลัง launch ตามเวลา

• 48 ชั่วโมง: crawl เว็บใหม่และเช็กว่าไม่มี noindex จาก staging
• 48 ชั่วโมง: ทดสอบ URL เดิมให้ 301 ไปหน้าที่ถูกต้อง ไม่ใช่ homepage
• 1 สัปดาห์: ยืนยัน sitemap ใหม่ถูกส่งและถูกค้นพบ
• 2 สัปดาห์: เทียบ GSC impressions/clicks กับ baseline ก่อนย้าย
• 4 สัปดาห์: ตรวจ Core Web Vitals และ soft 404 ใน Page Indexing report

8. เช็กลิสต์ Technical SEO แบบรวม

ทำเช็กลิสต์นี้เป็น recurring quarterly audit ไม่ใช่โปรเจกต์ครั้งเดียว เพราะ CMS update อาจ reset canonical, เนื้อหาใหม่อาจติด staging flag และ plugin อาจเพิ่ม schema ซ้ำ เว็บไซต์ที่แข็งแรงคือเว็บไซต์ที่ตรวจซ้ำและแก้ drift อย่างต่อเนื่อง

สรุปก่อนลงมือทำ

• เริ่มจาก crawlability และ indexability: แก้ robots.txt, noindex และ canonical ก่อน
• Core Web Vitals คือ quality floor: ผ่าน LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 แล้วกลับไปลงทุนกับ content และ relevance
• Structured data ช่วย rich results ไม่ใช่ ranking โดยตรง: ทำเฉพาะข้อมูลที่เห็นจริงและ validate ก่อน deploy
• Internal link ต้องกระจาย authority อย่างเป็นธรรมชาติ: depth ตื้น anchor หลากหลาย และติดตาม guardrails
• Migration ต้องมี baseline และ redirect map: ตรวจต่อเนื่อง 4 สัปดาห์หลัง launch
• ตรวจเป็นรอบ: ทำ quarterly audit เพื่อจับปัญหาที่เกิดจากการเปลี่ยนแปลงของระบบ

คำถามที่พบบ่อย

ควรตรวจ Technical SEO บ่อยแค่ไหน?

เว็บส่วนใหญ่ควรตรวจเต็มรูปแบบทุกไตรมาส และตรวจเบาๆ รายเดือนใน robots.txt, sitemap, Core Web Vitals และ indexing report ถ้าเผยแพร่บ่อย ใช้ headless CMS หรือเพิ่งย้ายระบบ ควรตรวจถี่ขึ้น แต่ผลตรวจต้องเชื่อมกับงานแก้ไขในรอบเดียวกัน

Core Web Vitals มีผลโดยตรงต่ออันดับหรือไม่?

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

Crawlability กับ indexability ต่างกันอย่างไร?

Crawlability คือ crawler ดึง URL ได้หรือไม่ ส่วน indexability คือ URL ที่ดึงได้มีสิทธิ์เข้า Google index หรือไม่ หนึ่งหน้าอาจ crawl ได้แต่ถูก noindex หรือ indexable แต่ถูก crawl น้อยเพราะอยู่ลึก ทั้งสองเงื่อนไขต้องผ่านหน้าจึงมีโอกาสติดอันดับ

ควรเก็บ 301 หลังย้ายเว็บไว้นานเท่าไร?

อย่างน้อย 6 เดือน และควรเป็น 12 เดือนขึ้นไป Google ต้องใช้เวลารวมสัญญาณไป URL ใหม่ ขณะที่ backlink ภายนอกยังชี้ URL เดิมอยู่ การเก็บ redirect มีต้นทุนต่ำกว่าการเสีย link equity จากการลบเร็วเกินไป

Structured data เป็น ranking factor หรือไม่?

ไม่ใช่โดยตรง คุณค่าคือช่วยให้เกิด rich results ช่วย Google เข้าใจ entity และอาจเพิ่ม CTR จึงควรทำเพื่อ visibility และการนำเสนอใน SERP ไม่ใช่คาดหวังให้ตำแหน่งอันดับขยับทันที

ถ้าต้องการตรวจเช็กลิสต์นี้กับเว็บไซต์จริงโดยไม่ต้องประกอบเครื่องมือเอง SoarTask รวม audit, crawl, internal link guardrails และ measurement loop ไว้ใน workflow เดียว เริ่ม workspace ฟรี เพื่อเชื่อมเว็บไซต์และรับรายงาน Technical SEO ที่จัดลำดับพร้อมหลักฐาน หรือเริ่มจาก SEO Audit, PageSpeed Checker, On-Page SEO Checker และ Internal Link Checker แยกทีละเครื่องมือ