ลองนึกภาพว่า คุณกำลังรัน Screaming Frog crawl ตามปกติสำหรับการตรวจสอบไซต์ของลูกค้า ทุกอย่างดูปกติจนกระทั่งคุณสังเกตเห็นรูปแบบที่ทำให้คุณต้องหยุดคิด URL หลายร้อยรายการเช่น /categories/=59487a4cd1758e7669102174 ปรากฏขึ้นในข้อมูล Crawl Data ของคุณ ซึ่ง URL เหล่านี้ถูกบล็อกโดย robots.txt แต่ก็ยังมี inlinks ที่ยังทำงานอยู่ชี้มาจากทั่วทั้งไซต์
หลายๆ คนอาจคิดว่านี่เป็นการรั่วไหลของ Link Equity แล้ว Crawl Budget กำลังถูกใช้ไปกับหน้าที่ไม่มีประโยชน์ หรือมองว่ามีสิ่งผิดปกติใน Internal Linking Structure ของเว็บไซต์หรือไม่? ในความเป็นจริง สิ่งนี้มักเกิดขึ้นเพราะวิธีการทำงานของระบบจัดการเนื้อหา (CMS) ภายใน ไม่ใช่เพราะมีอะไรเสียหายบนเว็บไซต์
URL ที่สร้างขึ้นโดยอัตโนมัติ เหล่านี้เป็นผลพลอยได้ตามปกติจากวิธีที่แพลตฟอร์ม CMS สมัยใหม่จัดการบันทึกในฐานข้อมูลที่อยู่หลัง Slug ที่แก้ไขได้ ทุกหน้าที่คุณแก้ไข ทุกหมวดหมู่ที่คุณเปลี่ยนชื่อ และทุกผลิตภัณฑ์ที่คุณอัปเดต มีตัวระบุภายในที่ไม่เปลี่ยนแปลง แม้ว่า URL ที่มองเห็นจะเปลี่ยนไปก็ตาม
ข่าวดีคือ Google ยืนยันแล้วว่า Link เหล่านี้ไม่มีผลกระทบต่อการจัดอันดับ Ranking แต่นั่นไม่ได้หมายความว่าเราควรเมินเฉยต่อสิ่งเหล่านี้ในรายงาน SEO แต่เราก็ควรกรองสิ่งเหล่านี้ออกไป เพื่อไม่ให้ปัญหาที่แท้จริงถูกฝังอยู่ใต้สิ่งประดิษฐ์ของระบบที่ไม่เป็นอันตรายนับพันรายการ
โพสต์นี้จะอธิบายว่าทำไม URL เหล่านี้จึงมีอยู่ แพลตฟอร์ม CMS ต่างๆ จัดการกับมันอย่างไร และวิธีทำความสะอาดการตรวจสอบของคุณ เพื่อให้คุณรายงานในสิ่งที่สำคัญจริงๆ
- ทำไมแพลตฟอร์ม CMS จึงแทรก Database ID เข้าไปใน URL ของคุณ
- แพลตฟอร์ม CMS ต่างๆ จัดการกับตัวระบุฐานข้อมูลภายในอย่างไร
- การทำความสะอาดรายงานการตรวจสอบและปกป้อง SEO ระหว่างการโยกย้าย CMS
ทำไม CMS จึงแทรก Database ID เข้ามาใน URL ของเรา
เพื่อเข้าใจว่าทำไม URL แปลกๆ เหล่านี้จึงปรากฏขึ้น เราต้องดูว่า CMS จัดเก็บและจัดระเบียบเนื้อหาเบื้องหลังอย่างไร
การค้นพบจาก Screaming Frog ที่จุดประกายคำถาม
สถานการณ์นี้เกิดขึ้นจริงบน Reddit ที่ผู้เชี่ยวชาญ Technical SEO คนหนึ่งแบ่งปันผลการตรวจสอบหลังจากสังเกตเห็นรูปแบบ URL แปลกๆ บนไซต์ Squarespace URL มีรูปแบบเช่น /categories/=[hash ตัวอักษรและตัวเลขยาว] และปรากฏว่าถูกบล็อกโดย robots.txt ในรายงาน crawl
สิ่งที่ทำให้เรื่องนี้โดดเด่นคือ URL เหล่านี้ยังคงมี Inlinks ที่ทำงานอยู่ใน Raw HTML สำหรับคนที่กำลังตรวจสอบ Link Equity นั่นดูเหมือนสัญญาณเตือน หากหน้าหนึ่งได้รับลิงก์ภายในแต่ถูกบล็อกจากการ Crawl นั่นไม่ใช่การเสียพลังการจัดอันดับที่มีศักยภาพหรือ? ลิงก์เหล่านั้นไม่ควรชี้ไปที่ที่ Crawl ได้แทนหรือ?
กระทู้นี้ได้รับความสนใจอย่างรวดเร็ว โดยมี SEO คนอื่นๆ เข้ามาแสดงความคิดเห็นพร้อมผลการค้นพบที่คล้ายกันในแพลตฟอร์มต่างๆ บางคนเคยเห็นรูปแบบเดียวกันบนไซต์ WordPress บางคนพบเหตุการณ์นี้บน Shopify Stores แต่คำถามที่สำคัญที่สุดคือ สิ่งนี้ส่งผลเสียต่อประสิทธิภาพของเว็บไซต์ในผลการค้นหาหรือไม่
คำตอบของ John Mueller: ไม่มีผลกระทบต่อ Ranking หรือ Crawl Budget
เมื่อคำถามแบบนี้ได้รับความสนใจอย่างล้นหลามในโลกออนไลน์ สุดท้ายก็ไปถึงหูของ Google โดยในกรณีนี้ John Mueller ได้ให้คำตอบเอาไว้ว่า URL เหล่านี้ไม่มีผลต่อ Crawl Budget และไม่ทำให้ Link Equity สูญเปล่าแต่อย่างใด
เหตุผลทางเทคนิคนั้นค่อนข้างเรียบง่าย Google ไม่ Crawl หน้าที่ถูกบล็อกโดย robots.txt หาก Googlebot ไม่สามารถ Crawl URL ได้ ก็ไม่สามารถส่งต่อ PageRank หรือ Link Authority ในลักษณะที่ส่งผลต่อสัญญาณการจัดอันดับของหน้า Landing Page ปลายทางได้ แม้ลิงก์อาจอยู่ในรูปแบบ Raw HTML แต่เนื่องจาก URL เป้าหมายถูกกั้นด้วย robots.txt จึงทำหน้าที่เหมือน "ทางตัน" ใน Crawl Graph มากกว่าการรั่วไหล
นั่นหมายความว่าโครงสร้างของเว็บไซต์คุณยังคงเป็นเหมือนเดิม ผู้ใช้งานเห็นหน้า Landing Page ที่ควรจะเห็น ส่วนลิงก์ภายในที่ชี้ไปยัง URL ที่มี Hash เหล่านี้เป็นเพียงผลลัพธ์จากการที่ CMS สร้าง Navigation และโครงสร้างภายในของแพลตฟอร์ม ซึ่งไม่ได้ส่งผลต่อการจัดอันดับเนื้อหาจริงของคุณ
สำหรับ Auditor คุณไม่ต้องเสียเวลาหลายชั่วโมงเพื่อพยายาม "แก้ไข" ลิงก์เหล่านี้หรือกังวลว่ามันกำลังทำร้ายการจัดอันดับของเว็บไซต์ลูกค้า เนื่องจากเป็นเพียงเสียงรบกวนทางความสวยงามในรายงาน Crawl ไม่มีอะไรมากกว่านั้น
การทำ Database Normalization: Slug ยังคงแก้ไขได้โดยไม่ทำให้ลิงก์เสีย
แล้วทำไม CMS จึงสร้างตัวระบุที่มี Hash เหล่านี้ตั้งแต่แรก? เหตุมาจากหลักการออกแบบฐานข้อมูลที่เรียกว่า Normalization
เนื้อหาทุกชิ้นบนเว็บไซต์ ไม่ว่าจะเป็นบทความ หน้าสินค้า หรือหน้าหมวดหมู่ จะถูกจัดเก็บเป็น Record ในฐานข้อมูล แล้ว Record นั้นๆ ต้องถูกระบุตัวตน เพื่อให้ระบบสามารถค้นหา อัปเดต และเชื่อมโยงกับ Record อื่นๆ เช่น Tag หมวดหมู่ หรือผลิตภัณฑ์อื่นที่เกี่ยวข้อง
หาก CMS ใช้เฉพาะ Slug ที่มนุษย์อ่านได้ (ส่วนที่แก้ไขได้ของ URL เช่น /blog/best-running-shoes) เพื่อระบุ Record นั้น คุณจะพบปัญหาอย่างรวดเร็ว ในขณะที่มีคนเปลี่ยนชื่อ slug เป็น /blog/top-running-shoes-2026 การอ้างอิงภายในทั้งหมดไปยัง Slug เดิมจะเสียหาย เว้นแต่ระบบจะอัปเดตทุกลิงก์ทั่วทั้งไซต์ด้วยตนเอง
ดังนั้น แพลตฟอร์ม CMS จึงกำหนด Database ID ที่คงที่ ซึ่งมักจะเป็น Hash ยาวหรือสตริงตัวเลข ที่ไม่เปลี่ยนแปลงไม่ว่าคุณจะแก้ไขชื่อเรื่องหรือ Slug กี่ครั้งก็ตาม ระบบภายใน เช่น เครื่องมือกรองหมวดหมู่หรือ Widget โพสต์ที่เกี่ยวข้อง จะอ้างอิง ID ที่คงที่นี้เบื้องหลัง Slug ที่มนุษย์อ่านได้เป็นเพียงตัวห่อที่เป็นมิตรซึ่งแสดงให้ผู้เข้าชมและเครื่องมือค้นหาเห็น
นี่คือเหตุผลที่ ID ดิบเหล่านี้บางครั้งปรากฏขึ้นในเมนู Navigation ระบบกรอง หรือการจัดกลุ่มหมวดหมู่ โดยเฉพาะเมื่อแพลตฟอร์มยังไม่ได้ซ่อนมันจาก HTML ที่แสดงผลอย่างสมบูรณ์ ซึ่งสิ่งนี้ไม่ใช่บัค แต่เป็นฐานข้อมูลที่ทำหน้าที่รักษาความสัมพันธ์ภายในให้คงที่ ในขณะที่ให้อิสระแก่ผู้ที่ต้องการแก้ไข URL โดยไม่ทำให้อะไรเสียหาย
แพลตฟอร์ม CMS ต่างๆ จัดการกับตัวระบุฐานข้อมูลภายในอย่างไร
ทั้งนี้ แม้กระทู้ Reddit ข้างต้นจะมุ่งเน้นไปที่ Squarespace แต่นี่ไม่ใช่ลักษณะพิเศษของแพลตฟอร์มใดแพลตฟอร์มหนึ่ง เนื่องจากแพลตฟอร์ม CMS และ e-Commerce เกือบทั้งหมดใช้ระบบตัวระบุแบบนี้ในรูปแบบใดรูปแบบหนึ่ง
เปรียบเทียบ Squarespace, WordPress, Shopify และ Wix
แต่ละแพลตฟอร์มจัดการกับ ID ภายในต่างกันเล็กน้อย แต่มีตรรกะพื้นฐานนั้นเหมือนกัน ดังนี้
WordPress
WordPress เปิดเผยตัวระบุภายในในหลายที่ที่มองเห็นได้ ทุกโพสต์และหน้ามี post_id และทุกหมวดหมู่หรือ tag มี term_id คุณสามารถเห็นค่าเหล่านี้ได้บ่อยครั้งในแผงข้อมูล Metadata ของ Block Editor ใน REST API Endpoints (เช่น /wp-json/wp/v2/posts/123) และแม้แต่ใน Body Class Attribute ของ HTML ที่แสดงผล ซึ่งอาจมีอะไรอย่าง postid-123 หรือ category-45 ไม่มีอะไรในนี้ที่ถูกซ่อนหรือเป็นอุบัติเหตุ นักพัฒนา WordPress พึ่งพาสิ่งนี้อย่างต่อเนื่องสำหรับงาน Theme และ Plugin
Shopify
Shopify ใช้ระบบ Routing แบบ Hash-Based ที่คล้ายกันสำหรับผลิตภัณฑ์และคอลเลกชัน เบื้องหลังทุก URL ผลิตภัณฑ์มี Product ID และ Variant ID ที่ไม่เหมือนใครซึ่งระบบของ Shopify ใช้จัดการสินค้าคงคลัง การตั้งราคา และตรรกะการชำระเงิน ID เหล่านี้บางครั้งปรากฏใน Liquid Template Code หรือใน Tracking Parameters ที่ถูกเพิ่มเข้ามาระหว่างขั้นตอนการช้อปปิ้ง
Wix1
สำหรับแพลตฟอร์ม Wix จะมีรูปแบบที่คล้ายกับ Shopify โดยเฉพาะหน้าแบบไดนามิกและเนื้อหาที่อิงคอลเลกชัน สตริงตัวอักษรและตัวเลขยาวมักปรากฏในโครงสร้างข้อมูล Backend สำหรับ Repeater Items และหน้ารายการแบบไดนามิก แม้ว่า URL ที่มองเห็นจะดูสะอาดก็ตาม
Squarespace
ดังที่กล่าวไว้ในตัวอย่าง Reddit Squarespace ใช้ ID ที่มี Hash เหล่านี้ในระบบการกรองหมวดหมู่และ Tag ของตัวแพลตฟอร์ม เมื่อเราสร้างหมวดหมู่ใหม่ แพลตฟอร์มจะสร้าง ID ถาวร ซึ่งระบบการกรองสามารถใช้อ้างอิงได้ ในขณะที่เราสามารถแก้ไขชื่อที่แสดงและ Slug ได้อย่างอิสระ
หากคุณกำลังตรวจสอบไซต์ในหลายแพลตฟอร์ม คาดว่าจะพบรูปแบบนี้อีกครั้งแล้วครั้งเล่า ซึ่งเป็นลักษณะพื้นฐานของวิธีที่ฐานข้อมูล CMS สมัยใหม่ถูกสร้างขึ้น ไม่ใช่ความผิดพลาดที่เกี่ยวข้องกับผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่ง
การใช้ "?format=json-pretty" เพื่อตรวจสอบข้อมูลระบบดิบ
หากคุณต้องการเห็นข้อมูลระดับระบบนี้ในการทำงานบนไซต์ Squarespace มีเทคนิคง่ายๆ อย่างหนึ่ง เพียงแค่เพิ่ม ?format=json-pretty ที่ท้าย URL ของ Squarespace และคุณจะได้โครงสร้าง Raw JSON ที่ขับเคลื่อนหน้าที่แสดงผล
JSON Output นั้นแสดงให้เห็นถึงข้อมูลจริงที่ CMS ทำงานด้วย รวมถึง ID ที่คงที่ที่กำหนดให้กับหมวดหมู่ tag และบล็อกเนื้อหา มันเป็นวิธีที่ดีในการยืนยันว่าสตริงที่มี Hash เหล่านี้เป็นสิ่งที่มันดูเหมือนจริงๆ: ค่าเชิงโครงสร้างที่ใช้สำหรับการจัดระเบียบภายใน ไม่ใช่หน้าลับที่ตั้งใจให้ทำ Index
การตรวจสอบแบบนี้มีประโยชน์มากในระหว่างการตรวจสอบเมื่อลูกค้าถามว่าทำไม URL แปลกๆ เหล่านี้ถึงมีอยู่ แทนที่จะให้คำตอบที่คลุมเครือ คุณสามารถแสดงข้อมูลระบบดิบให้พวกเขาเห็นว่าแพลตฟอร์มจัดระเบียบเนื้อหาเบื้องหลังอย่างไร
แพลตฟอร์มอื่นๆ ก็มี View ที่คล้ายกัน WordPress มี REST API ของมันเอง ซึ่งคุณสามารถ Query ได้ตรงในเบราว์เซอร์ Shopify มีเครื่องมือ Debug Theme ต่างๆ การทำความคุ้นเคยกับการสำรวจข้อมูลดิบนี้ช่วยให้คุณวินิจฉัยปัญหาได้เร็วขึ้นและพูดด้วยความมั่นใจมากขึ้นเมื่ออธิบายลักษณะพิเศษทางเทคนิคให้กับลูกค้า
Googlebot's Rendering Service ประมวลผลลิงก์เหล่านี้อย่างไร
นี่คือส่วนที่ควรทำให้ความกังวลที่เหลือหมดไป Web Rendering Service ของ Google แสดงผลหน้าเหมือนกับเบราว์เซอร์ และในการทำเช่นนั้นมันทำให้เสียงรบกวนเชิงโครงสร้างจำนวนมากที่ไม่สำคัญต่อการทำ Index หายไป
เมื่อ Googlebot พบ URL ที่อิงจาก ID ภายในเหล่านี้ สิ่งสองสามอย่างเกิดขึ้น อย่างแรก หาก URL ถูกบล็อกโดย robots.txt Google จะเคารพสิ่งนั้นและไม่ Crawl หรือแสดงผลหน้านั้นเลย อย่างที่สอง แม้ว่า URL แบบนี้จะไม่ถูกบล็อก ระบบของ Google มักจะรู้จัก URL ที่สร้างโดยระบบที่มีค่าต่ำ และดันมันลงไปในลำดับ Crawl Queue เพื่อเลือกเนื้อหาที่มีคุณภาพมากกว่า
คุณสามารถตรวจสอบได้อย่างชัดเจนว่า Google จัดการกับ URL ที่เจาะจงอย่างไรโดยใช้ URL Inspection Tool ใน Google Search Console รัน URL ที่มี Hash เหล่านี้ผ่านมัน และคุณจะเห็นว่ามันมักจะถูกยกเว้นจากการทำ Index บ่อยครั้งพร้อมหมายเหตุอธิบายว่ามันถูกบล็อกโดย robots.txt หรือถูกทำเครื่องหมายว่าเป็นเนื้อหาซ้ำหรือมีค่าต่ำ
นั่นให้คุณวิธีที่เป็นรูปธรรมในการตรวจสอบคำกล่าวของ Mueller แทนที่จะเชื่อโดยไม่มีการพิสูจน์ หากลูกค้าต้องการหลักฐาน การรัน URL เหล่านี้จำนวนหนึ่งผ่าน Inspection Tool และชี้ให้เห็นสถานะ "Excluded" เป็นวิธีที่รวดเร็วในการปิดการสนทนา
การทำความสะอาดรายงานการตรวจสอบและปกป้อง SEO ระหว่างการโยกย้าย CMS
การรู้ว่า URL เหล่านี้ไม่เป็นอันตรายเป็นเรื่องหนึ่ง การป้องกันไม่ให้มันทำให้รายงานการตรวจสอบของคุณรกเป็นอีกเรื่องหนึ่ง มาดูวิธีตั้งค่าเครื่องมือของคุณอย่างเหมาะสม แล้วมาเปลี่ยนไปดูว่าความเสี่ยง SEO ที่เกี่ยวข้องกับ CMS นั้นอยู่ที่ไหนจริงๆ: การโยกย้าย, จำนวน Plugin ที่มากเกินไป, และความผิดพลาดระดับ template ที่ทำลายการจัดอันดับของคุณอย่างเงียบๆ ในขณะที่ทุกคนกำลังกังวลกับ Query Strings
การยกเว้นด้วย Regex ใน Screaming Frog สำหรับ URL ที่ถูกแทรกเข้ามา
หากคุณกำลังรัน Screaming Frog และพารามิเตอร์แบบ WordPress หรือ Elementor เหล่านี้ยังคงปรากฏขึ้นใน Crawl ของคุณ วิธีแก้ไขคือการยกเว้นด้วย Regex ที่ง่าย ไปที่ Configuration > Exclude และเพิ่มรูปแบบที่ตรงกับสิ่งที่ไม่มีประโยชน์โดยไม่กระทบ URL จริง
รูปแบบบางอย่างที่ควรเพิ่ม:
.*\?p=[0-9]+.*
.*\?elementor.*
.*\?fbclid=.*
.*\?ver=[0-9.]+.*
ทดสอบแต่ละรูปแบบกับ URL ที่ใช้งานจริงจำนวนหนึ่งก่อนที่คุณจะรัน crawl แบบเต็ม การยกเว้นด้วย Regex นั้นทำพลาดได้ง่าย และรูปแบบที่กว้างเกินไปอาจยกเว้นหน้าที่คุณต้องการตรวจสอบจริงๆ โดยไม่ได้ตั้งใจ Screaming Frog มีฟีเจอร์ทดสอบในตัวในหน้าตั้งค่าการยกเว้น ใช้มันทุกครั้ง
หากคุณจัดการไซต์ลูกค้าหลายแห่งที่มีการตั้งค่า CMS ต่างกัน ให้บันทึกรายการการยกเว้นเหล่านี้เป็นไฟล์ Preset Configuration วิธีนี้คุณจะไม่ต้องสร้าง Regex ใหม่ตั้งแต่ต้นทุกครั้งที่เริ่ม Crawl ใหม่
การจัดการ Query Parameter เพื่อรายงานที่สะอาดขึ้นสำหรับลูกค้า
การยกเว้นการ Crawl แก้ปัญหาในส่วนของคุณ แต่ Query Parameters ยังสามารถรั่วไหลเข้าไปใน Google Search Console, Google Analytics และรายงาน Log File ซึ่งหมายความว่ามันยังสามารถรั่วไหลเข้าไปในสิ่งที่ลูกค้าของคุณเห็น
ขั้นตอนที่ใช้ได้จริงบางอย่าง:
- ใน GSC: ใช้ URL Parameter Tool (ในที่ที่มีให้ใช้) หรือกรอง Query Strings ออกจากรายงาน Coverage และ Performance ของคุณก่อนที่จะ Export
- ใน GA4: ตั้งค่าตัวกรองหรือใช้ Path-based Regex ในรายงาน Exploration ของคุณเพื่อลบ Query Strings ออก ดังนั้น
/blog-post/และ/blog-post/?ver=123จะไม่ถูกรายงานเป็นสองหน้าที่แตกต่างกัน - ในเทมเพลตรายงานของคุณ: เพิ่มหมายเหตุสั้นๆ อธิบายว่า Parameterized URLs เป็นพฤติกรรม CMS ที่คาดหวัง ไม่ใช่ข้อผิดพลาดในการทำ Index สิ่งนี้ป้องกันคำถาม "ทำไมมี URL ซ้ำ 200 รายการ" ก่อนที่จะถูกถามด้วยซ้ำ
เป้าหมายไม่ใช่การซ่อนข้อมูล แต่คือการนำเสนอในลักษณะที่สะท้อนถึงสิ่งที่เกิดขึ้นจริงบนไซต์ มากกว่าที่จะเป็นสิ่งที่การ Export ดิบทำให้ดูเป็น
ความเสี่ยง SEO ที่แท้จริงระหว่างการโยกย้าย CMS
นี่คือส่วนที่ควรได้รับความสนใจมากกว่า Query Strings ที่จะได้รับ: ความเสียหายทาง SEO ส่วนใหญ่จาก CMS ไม่ได้มาจากพารามิเตอร์ที่ถูกแทรกเข้ามา มันมาจากสิ่งที่เกิดขึ้นระหว่างและหลังการโยกย้าย
ผู้กระทำผิดที่พบบ่อยบางอย่าง:
- การ redirect ที่เสียหายหรือขาดหายไป - การย้ายจาก CMS หนึ่งไปอีกหนึ่ง (หรือแม้แต่จาก Theme หนึ่งไปอีก Theme หนึ่ง) มักเปลี่ยนโครงสร้าง URL หากไม่มีแผนที่ Redirect ที่สมบูรณ์ คุณจะสูญเสีย Link equity และการจัดอันดับบนทุก URL ที่ไม่ได้ถูกจับคู่
- Plugin ที่มากเกินไป - ทุก Plugin ใหม่เพิ่ม Scripts, Styles และบางครั้งพารามิเตอร์ Query หรือ endpoints ที่ Crawl ได้ของตัวเอง หากไม่ได้รับการตรวจสอบ สิ่งนี้จะทำให้ความเร็วของหน้าช้าลงและเพิ่ม Crawl Bloat ที่ไม่มีอะไรเกี่ยวข้องกับเนื้อหาจริง
- ความผิดพลาดในระดับ template ของ Canonical - Canonical Tag ที่ผิดพลาดเพียงหนึ่งอันที่ฝังอยู่ใน theme template สามารถแพร่กระจายไปยังหน้านับพันก่อนที่ใครจะสังเกตเห็น บ่อยครั้งมองไม่เห็นจนกว่าการจัดอันดับที่ลดลงจะบังคับให้ทำการตรวจสอบทางเทคนิค
- Structured Data ที่สูญหาย - การโยกย้ายบ่อยครั้งลบ Schema Markup ที่ไม่ได้เป็นส่วนหนึ่งของ Template เริ่มต้นของ Theme ใหม่ ทำให้ Rich Results ที่ใช้เวลาหลายเดือนในการได้มาตายไปอย่างเงียบๆ
ไม่มีสิ่งใดในนี้ปรากฏเป็น Query String ที่น่ากลัวในรายงาน Crawl ของคุณ มันปรากฏขึ้นหลายสัปดาห์ต่อมาเป็นกราฟ Traffic ที่ลาดลงอย่างเงียบๆ หากคุณกำลังผ่านการโยกย้าย CMS หรือแพลตฟอร์ม จัดสรรเวลาจริงสำหรับการตรวจสอบทางเทคนิคก่อนเปิดตัวและหลังเปิดตัว นั่นคือที่ที่ความเสี่ยงจริงอยู่ ไม่ใช่ใน URL ?p=123 ที่นั่งอย่างไม่เป็นอันตรายในข้อมูล Crawl ของคุณ
