جداسازی AMP یک فرآیند فنی دقیق است که فراتر از غیرفعال کردن یک افزونه است. این کار نیازمند مدیریت صحیح ریدایرکت‌ها برای جلوگیری از خطاهای ۴۰۴ و حفظ کامل ترافیک موبایل است. برای اجرای موفقیت‌آمیز این کار، ابتدا باید الگوهای URL خود را به خوبی بشناسید و آن‌ها را دسته‌بندی کنید. درک الگوهای عملی رجکس برای تحلیل صفحات (Pages) در ابزارهایی مانند سرچ کنسول یا تنظیمات سرور، به شما کمک می‌کند تا این مهاجرت را به شکل دقیق و کنترل‌شده مدیریت کنید. در این راهنما، ما گام‌های فنی و استراتژیک این فرآیند را برای یک انتقال امن بررسی می‌کنیم.
جدول مقایسه‌ای: تصمیم‌گیری برای حذف AMP
| معیار | حفظ AMP | حذف AMP (تمرکز بر Core Web Vitals) |
| هزینه نگهداری | بالا (نیاز به مدیریت دو نسخه از سایت) | بهینه (تمرکز تمام منابع روی یک نسخه Canonical) |
| سرعت و عملکرد | سرعت بالا از طریق کش گوگل | سرعت بالا در صورت بهینه‌سازی (کنترل کامل روی عملکرد) |
| تجربه کاربری (UX) | محدود (تجربه کاربری ساده و یکسان) | کامل (تجربه برندینگ و UX کامل سایت) |
| اهداف تجاری (CRO) | محدودیت شدید در جاوا اسکریپت، فرم‌ها و ابزارهای CRO | آزادی کامل در پیاده‌سازی ویژگی‌های تعاملی و تجاری |
| اولویت سئو (امروز) | دیگر مزیت انحصاری در رتبه‌بندی ندارد | دریافت مستقیم مزایای رتبه‌بندی با پاس کردن CWV |
AMP چیست و چرا جداسازی آن (یا حذف کامل) یک استراتژی کلیدی است؟
AMP یا (Accelerated Mobile Pages) یک فریم‌ورک متن-باز بود که توسط گوگل با هدف افزایش چشمگیر سرعت بارگذاری صفحات وب در موبایل معرفی شد. این پروژه اساساً یک نسخه سبک و محدود شده از صفحات وب شما ایجاد می‌کرد که از طریق کش (Cache) گوگل بارگذاری می‌شد و تجربه‌ای آنی (Instant) را برای کاربر رقم می‌زد.
در گذشته، استفاده از AMP برای حضور در بخش‌هایی مانند “Top Stories” (اخبار داغ) گوگل تقریباً الزامی بود. اما امروزه، این رویکرد در حال تغییر است.
بحث جداسازی یا حذف کامل AMP به یک استراتژی کلیدی تبدیل شده، زیرا گوگل دیگر AMP را به عنوان یک فاکتور انحصاری برای سرعت یا رتبه‌بندی در نظر نمی‌گیرد. با معرفی Core Web Vitals (CWV)، تمرکز گوگل از «استفاده از یک تکنولوژی خاص (AMP)» به «ارائه تجربه کاربری سریع و باکیفیت (CWV) در هر صفحه‌ای» تغییر کرده است.
این تغییر به این معناست که اگر صفحه اصلی (Canonical) شما بتواند استانداردهای Core Web Vitals را برآورده کند، دیگر نیازی به نگهداری یک نسخه مجزای AMP، با تمام محدودیت‌ها و هزینه‌های نگهداری مضاعف آن، ندارید.
تعریف فنی AMP: تفاوت با صفحات عادی (Canonical) چیست؟
از نظر فنی، AMP یک استاندارد مجزا با سه جزء اصلی است:
- AMP HTML: این نسخه، HTML استاندارد با محدودیت‌های مشخص است. بسیاری از تگ‌های HTML معمولی یا جایگزین شده‌اند (مانند <img> به <amp-img>) یا استفاده از آن‌ها ممنوع است.
- AMP JS: استفاده از جاوا اسکریپت سفارشی (Custom JS) در AMP به شدت محدود یا ممنوع است. این فریم‌ورک کتابخانه جاوا اسکریپت مخصوص به خود را دارد که مدیریت منابع و بارگذاری را به صورت بهینه انجام می‌دهد. این بزرگترین دلیل سرعت بالای AMP (و همچنین بزرگترین محدودیت آن) است.
- AMP Cache: گوگل (و پلتفرم‌های دیگر مانند بینگ) این صفحات را در حافظه پنهان (Cache) خود ذخیره می‌کنند تا مستقیماً و با سرعت بسیار بالا به کاربران نمایش دهند.
تفاوت اصلی با صفحه Canonical (عادی):
- صفحه Canonical: این صفحه اصلی و کامل وب‌سایت شماست. شامل تمام کدهای جاوا اسکریپت (مانند ابزارهای تحلیلی پیچیده، پاپ‌آپ‌ها، چت آنلاین)، کدهای CSS کامل و تمام ویژگی‌های تعاملی و برندینگ شماست.
- صفحه AMP: نسخه‌ای «رژیمی» و سبک‌سازی شده از صفحه Canonical است. بسیاری از عناصر تعاملی، اسکریپت‌های ثالث (Third-party) و کدهای CSS سنگین در آن حذف یا محدود شده‌اند تا بارگذاری آنی تضمین شود.
نقش تگ‌های rel=”amphtml” و rel=”canonical” در اتصال این دو صفحه
این دو تگ برای جلوگیری از ایجاد محتوای تکراری (Duplicate Content) و معرفی این دو نسخه به موتورهای جستجو حیاتی هستند. آن‌ها یک رابطه دوطرفه ایجاد می‌کنند:
- در صفحه Canonical (صفحه اصلی):
- باید یک تگ link در بخش <head> قرار گیرد که به نسخه AMP اشاره می‌کند:
- <link rel=”amphtml” href=”httpsC://example.com/page-amp.html”>
- معنی: “سلام گوگل، این صفحه اصلی من است و یک نسخه AMP از آن در این آدرس موجود است.”
- در صفحه AMP:
- باید یک تگ link در بخش <head> قرار گیرد که به نسخه اصلی (Canonical) اشاره می‌کند:
- <link rel=”canonical” href=”https://example.com/page.html”>
- معنی: “سلام گوگل، من نسخه AMP هستم. صفحه اصلی و مرجع من، آدرسی است که در تگ Canonical مشخص شده.”
این اتصال دوطرفه به گوگل کمک می‌کند تا بفهمد این دو صفحه، نسخه‌های متفاوتی از یک محتوای واحد هستند و باید اعتبار و رتبه‌بندی را به صفحه اصلی (Canonical) منتقل کند.
AMP در برابر Core Web Vitals: آیا دوران AMP به پایان رسیده است؟
این دقیقاً مرکز بحث استراتژیک امروز است.
- گذشته: AMP مسیر اصلی برای کسب “سرعت” در موبایل و نماد صاعقه (Lightning Bolt) بود.
- امروز: Core Web Vitals (CWV) معیارهای واقعی گوگل برای سنجش تجربه کاربری هستند (شامل سرعت بارگذاری LCP، تعامل‌پذیری INP و ثبات بصری CLS).
گوگل رسماً اعلام کرده است که هر صفحه‌ای، چه AMP باشد و چه نباشد، اگر بتواند معیارهای CWV را با موفقیت پشت سر بگذارد، واجد شرایط دریافت مزایای رتبه‌بندی مرتبط با سرعت خواهد بود.
بنابراین، “دوران” AMP به عنوان یک ضرورت فنی برای سئو به پایان رسیده است. AMP دیگر یک «میان‌بر» برای سرعت نیست؛ بلکه تنها «یکی از راه‌ها» برای رسیدن به آن است. اگر تیم فنی شما می‌تواند سایت اصلی را بهینه‌سازی کند تا مستقیماً از سد CWV عبور کند، AMP به یک هزینه اضافی تبدیل می‌شود.
مزایا و معایب حفظ یا حذف AMP (تصمیم‌گیری آگاهانه)
تصمیم برای حذف AMP باید بر اساس تحلیل هزینه و فایده برای کسب‌وکار شما باشد.
مزایای حفظ AMP
- سرعت تضمین شده (در صورت ضعف سایت اصلی): اگر سایت اصلی شما بسیار سنگین است و بهینه‌سازی آن برای CWV دشوار، پرهزینه یا زمان‌بر است، AMP همچنان یک راه‌حل سریع (هرچند موقت) برای ارائه یک نسخه پرسرعت به کاربران موبایلی است.
- استفاده از Google Cache: بارگذاری از کش گوگل، فشار روی سرورهای شما را به شدت کاهش می‌دهد، که می‌تواند برای سایت‌های خبری با ترافیک ناگهانی و بالا، مفید باشد.
- سادگی (برای برخی پلتفرم‌ها): اگر از CMSهایی مانند وردپرس استفاده می‌کنید و افزونه AMP شما به خوبی کار می‌کند و محدودیتی برای شما ایجاد نکرده، حفظ آن شاید کم‌دردسرتر از حذف آن باشد.
معایب حفظ AMP (و دلایل اصلی حذف آن)
- هزینه نگهداری مضاعف: این بزرگترین دلیل برای حذف است. شما باید دو نسخه از سایت را مدیریت کنید. هر تغییر در طراحی، افزودن هر ویژگی جدید، یا رفع هر باگ، باید در دو پایگاه کد (Codebase) مجزا (Canonical و AMP) اعمال شود. این کار منابع تیم فنی را دو برابر مصرف می‌کند.
- محدودیت‌های شدید عملکردی: AMP ذاتاً محدودکننده است. پیاده‌سازی فرم‌های پیچیده، ابزارهای CRO (بهینه‌سازی نرخ تبدیل)، ردیابی تحلیلی دقیق (Analytics) و عناصر برندینگ سفارشی در AMP بسیار دشوار یا غیرممکن است. این مستقیماً به اهداف تجاری سایت لطمه می‌زند.
- پیچیدگی آنالیتیکس: ردیابی صحیح کاربران بین نسخه کش‌شده AMP و سایت اصلی شما پیچیده است. اغلب باعث ایجاد خطاهای آماری، افزایش نادرست Bounce Rate یا شمارش چندباره کاربران می‌شود.
- AMP دیگر مزیت انحصاری ندارد: همانطور که گفته شد، اگر سایت اصلی شما بهینه باشد و CWV را پاس کند، AMP هیچ مزیت اضافه‌ای در رتبه‌بندی برای شما نخواهد داشت.
اگر AMP برای شما محدودیت‌های تجاری (CRO، برندینگ) و فنی (نگهداری مضاعف) ایجاد کرده است، استراتژی صحیح، تمرکز تمام منابع بر بهینه‌سازی سایت اصلی (Canonical) برای گذراندن Core Web Vitals و سپس حذف کامل AMP است.
پیش‌نیازها و چک‌لیست حیاتی قبل از جداسازی صفحات AMP
جداسازی AMP یک فرآیند فنی حساس است. این کار صرفاً «خاموش کردن» یک ویژگی نیست، بلکه یک «مهاجرت» (Migration) کامل از صفحات AMP به صفحات اصلی (Canonical) در موبایل است. اگر پیش‌نیازها رعایت نشوند، ریسک از دست دادن ترافیک موبایل و افت رتبه‌های حیاتی بسیار بالاست.
این چک‌لیست، گام‌های ضروری قبل از شروع فرآیند است تا از یک انتقال امن و کنترل‌شده اطمینان حاصل کنیم.
تهیه بک‌آپ کامل از وب‌سایت (اولین و مهم‌ترین گام)
قبل از هرگونه تغییر ساختاری در سایت، به‌خصوص تغییری که شامل ریدایرکت‌های گسترده می‌شود، تهیه یک نسخه پشتیبان کامل (Full Backup) الزامی است.
این بک‌آپ باید شامل موارد زیر باشد:
- پایگاه داده (Database): تمام اطلاعات و تنظیمات شما در دیتابیس ذخیره شده‌اند.
- فایل‌های سایت (Files): شامل تمام فایل‌های هسته CMS، پلاگین‌ها، قالب‌ها و رسانه‌ها.
این بک‌آپ «بیمه‌نامه» شماست. اگر در طول فرآیند جداسازی، ریدایرکت‌ها به درستی اعمال نشوند یا مشکلی حیاتی رخ دهد، باید بتوانید به سرعت سایت را به وضعیت پایدار قبلی بازگردانید.
اطمینان از بهینه‌سازی سرعت صفحات عادی (Non-AMP) برای موبایل
دلیل اصلی حذف AMP این است که معتقدیم نسخه اصلی (Canonical) ما به اندازه کافی سریع و بهینه است. قبل از هر اقدامی، این ادعا باید در عمل ثابت شود.
صفحات اصلی شما باید به طور کامل استانداردهای Core Web Vitals (CWV) را در موبایل برآورده کنند. اگر صفحات Canonical شما کندتر از نسخه‌های AMP باشند، پس از حذف، گوگل متوجه این افت کیفیت تجربه کاربری (UX) شده و احتمالاً با افت رتبه مواجه خواهید شد.
موارد زیر را به دقت بررسی کنید:
- LCP (Largest Contentful Paint): آیا زمان بارگذاری محتوای اصلی در موبایل سریع و قابل قبول است (زیر ۲.۵ ثانیه)؟
- INP (Interaction to Next Paint): آیا صفحات در موبایل به سرعت به تعاملات کاربر (مانند کلیک‌ها یا اسکرول) پاسخ می‌دهند؟ (این معیار جایگزین FID شده است)
- CLS (Cumulative Layout Shift): آیا چیدمان صفحه در موبایل ثبات دارد و عناصر صفحه دچار پرش‌های ناگهانی نمی‌شوند؟
استفاده از ابزارهایی مانند Google PageSpeed Insights برای تست واقعی صفحات Canonical در موبایل و شناسایی نقاط ضعف آن‌ها قبل از حذف AMP ضروری است.
بررسی کامل Google Search Console (گزارش‌های AMP و Core Web Vitals)
گوگل سرچ کنسول، مرکز داده شما برای درک وضعیت فعلی سایت در نگاه گوگل است. قبل از مهاجرت، باید این دو گزارش را به دقت تحلیل کنید:
- گزارش AMP:
- بررسی کنید چه تعداد از صفحات شما به عنوان AMP معتبر (Valid) شناخته شده‌اند.
- آیا خطاهای (Errors) مهمی در این بخش وجود دارد؟
- این گزارش به شما یک دید کلی از حجم صفحاتی می‌دهد که قرار است ریدایرکت و از ایندکس گوگل (به عنوان AMP) حذف شوند.
- گزارش Core Web Vitals (بخش Mobile):
- این گزارش حیاتی‌تر است. وضعیت URLهای اصلی (Non-AMP) شما در موبایل چگونه است؟
- آیا گوگل آن‌ها را “Good” (خوب)، “Need Improvement” (نیاز به بهبود) یا “Poor” (ضعیف) دسته‌بندی کرده است؟
نکته کلیدی: اگر اکثر صفحات اصلی شما در سرچ کنسول وضعیت ‘Poor’ یا ‘Need Improvement’ دارند، شما هنوز برای حذف AMP آماده نیستید. ابتدا باید مشکلات CWV را در صفحات اصلی حل کنید و منتظر بمانید تا گزارش سرچ کنسول وضعیت ‘Good’ را نشان دهد.
انتخاب استراتژی: حذف کامل یا جداسازی موقت؟
دو رویکرد اصلی برای جداسازی وجود دارد که باید بر اساس اندازه و حساسیت سایت خود یکی را انتخاب کنید:
- حذف کامل و یکباره (Full Removal):
- روش: شما AMP را به طور کامل در کل سایت غیرفعال می‌کنید. سپس بلافاصله تمام URLهای AMP را (از طریق فایل .htaccess یا افزونه‌های مدیریت ریدایرکت) به URLهای Canonical معادل، با ریدایرکت ۳۰۱ (Permanent Redirect) منتقل می‌کنید.
- ریسک: بالا. اگر صفحات Canonical بهینه نباشند یا ریدایرکت‌ها به درستی تنظیم نشوند، کل ترافیک موبایل سایت در خطر قرار می‌گیرد.
- کاربرد: مناسب برای سایت‌های کوچک که از بهینه بودن کامل صفحات اصلی خود اطمینان دارند.
- جداسازی موقت یا مرحله‌ای (Phased Rollout):
- روش: این رویکرد محتاطانه‌تر است. شما AMP را فقط برای یک بخش یا دسته‌بندی خاص از سایت (مثلاً یک کتگوری مشخص از بلاگ) غیرفعال می‌کنید.
- سپس تگ rel=amphtml را از صفحات Canonical همان بخش حذف کرده و ریدایرکت ۳۰۱ را فقط برای URLهای AMP همان بخش اجرا می‌کنید.
- مزیت: به شما اجازه می‌دهد تا تأثیر حذف AMP را در یک محیط کنترل‌شده تست کنید. شما عملکرد CWV، رتبه‌ها و ترافیک صفحات اصلی آن بخش را زیر نظر می‌گیرید. اگر نتایج پس از چند هفته مثبت بود، فرآیند را برای سایر بخش‌های سایت تکرار می‌کنید.
- کاربرد: این روش برای سایت‌های بزرگ، فروشگاه‌های اینترنتی و تمام کسب‌وکارهایی که به ترافیک ارگانیک خود به شدت وابسته هستند، به شدت توصیه می‌شود.
راهنمای گام به گام فنی برای حذف کامل AMP و جداسازی دائمی
حذف AMP یک فرآیند صرفاً «غیرفعال کردن یک افزونه» نیست؛ این یک مهاجرت (Migration) فنی کامل است. هدف اصلی این است که تمام اعتبار سئو (مانند بک‌لینک‌ها) و ترافیکی که صفحات AMP شما در طول زمان جمع‌آوری کرده‌اند، به طور کامل و بدون خطا به صفحات اصلی (Canonical) شما منتقل شود.
هرگونه اشتباه در این فرآیند، به ویژه در تنظیم ریدایرکت‌ها، می‌تواند منجر به ایجاد هزاران خطای ۴۰۴ در سرچ کنسول و افت شدید ترافیک موبایل شما شود. این گام‌ها باید با دقت و به ترتیب انجام شوند.
مرحله ۱: غیرفعال‌سازی افزونه AMP (در وردپرس و سایر CMSها)
اولین گام اجرایی، متوقف کردن تولید صفحات AMP جدید است.
- در وردپرس: این کار معمولاً به معنای رفتن به بخش «افزونه‌ها» و «غیرفعال کردن» (Deactivate) افزونه AMP (مانند افزونه رسمی AMP یا AMP for WP) است.
- در سایر CMSها: باید ماژول یا تنظیماتی که AMP را فعال می‌کند، پیدا و غیرفعال کنید.
نکته بسیار مهم: به محض غیرفعال کردن افزونه، تمام URLهای AMP شما (که گوگل قبلاً ایندکس کرده) از کار می‌افتند و به خطای ۴۰۴ (صفحه یافت نشد) تبدیل می‌شوند. به همین دلیل، این مرحله باید بلافاصله با مرحله ۲ (تنظیم ریدایرکت‌ها) همراه شود. هرگز افزونه را بدون آماده‌سازی ریدایرکت‌ها غیرفعال نکنید.
مرحله ۲: تنظیم ریدایرکت‌های ۳۰۱ (مهم‌ترین گام برای حفظ سئو)
این مرحله، قلب فرآیند مهاجرت و حفظ سئوی شماست. ما باید به موتورهای جستجو به طور واضح اعلام کنیم که تمام صفحات AMP برای همیشه به صفحات معادل اصلی خود منتقل شده‌اند.
گوگل هزاران (یا شاید میلیون‌ها) URL از سایت شما را با پسوند AMP ایندکس کرده است. اگر کاربری روی آن نتایج کلیک کند یا لینکی به آن صفحات داده شده باشد، باید به صورت خودکار به نسخه اصلی هدایت شود.
- چرا ۳۰۱؟ ریدایرکت ۳۰۱ (Permanent Redirect) تنها راهی است که به گوگل می‌گوید این انتقال دائمی است و باید تمام اعتبار و رتبه صفحه قبلی (AMP) را به صفحه جدید (Canonical) منتقل کند.
نحوه ریدایرکت خودکار صفحات /?amp=1 به نسخه‌ی اصلی
قبل از تنظیم ریدایرکت، باید بدانید افزونه شما از کدام ساختار URL استفاده می‌کرده است. دو حالت متداول وجود دارد:
- ساختار Query Parameter (پارامتر پرس‌وجو):
- example.com/my-page/?amp=1
- ساختار Path (مسیر):
- example.com/my-page/amp/
استراتژی ریدایرکت شما باید دقیقاً بر اساس ساختاری که داشته‌اید تنظیم شود تا تمام URLهای AMP را شناسایی کرده و آن‌ها را به نسخه بدون پسوند (یعنی example.com/my-page/) هدایت کند.
مدیریت ریدایرکت‌ها در سطح سرور (فایل .htaccess یا Nginx)
استفاده از افزونه‌ها برای این حجم از ریدایرکت توصیه نمی‌شود. این کار باید در سطح سرور (Server-level) انجام شود تا سریع، بهینه و بدون فشار اضافه بر CMS شما باشد.
۱. برای سرورهای Apache (فایل .htaccess):
کد زیر را در فایل .htaccess خود (در ریشه اصلی سایت)، قبل از قوانین وردپرس، اضافه کنید.
- اگر ساختار شما /?amp=1 بود:
Apache
RewriteEngine On
RewriteCond %{QUERY_STRING} ^amp=1$ [NC]
RewriteRule ^(.*)$ /$1? [R=301,L]
-
- توضیح: این کد بررسی می‌کند اگر رشته amp=1 در URL وجود داشت، آن را حذف کرده و کاربر را با ریدایرکت ۳۰۱ به همان URL بدون پارامتر هدایت می‌کند.
- اگر ساختار شما /amp/ بود:
Apache
RewriteEngine On
RewriteRule ^(.*)/amp/?$ $1 [R=301,L]
-
- توضیح: این کد هر URL که به /amp/ ختم می‌شود را شناسایی کرده، آن بخش را حذف و به نسخه اصلی ۳۰۱ می‌کند.
۲. برای سرورهای Nginx (فایل nginx.conf):
باید کد مشابهی را در فایل پیکربندی Nginx خود اضافه کنید.
- اگر ساختار شما /?amp=1 بود:
Nginx
if ( $query_string = “amp=1” ) {
return 301 $uri?;
}
- اگر ساختار شما /amp/ بود:
Nginx
rewrite ^/(.*)/amp/?$ /$1 permanent;
مرحله ۳: حذف دستی تگ‌های rel=”amphtml” از هدر صفحات
پس از غیرفعال‌سازی افزونه، باید مطمئن شوید که تگ link rel=”amphtml” از بخش <head> صفحات اصلی (Canonical) شما حذف شده است.
این تگ به گوگل اطلاع می‌داد که “این صفحه یک نسخه AMP دارد”. ادامه حضور این تگ در حالی که نسخه AMP دیگر وجود ندارد (و در حال ریدایرکت است)، گوگل را دچار سردرگمی می‌کند.
- اقدام: ابتدا کش (Cache) سایت خود را به طور کامل پاک کنید. در بسیاری از موارد، با غیرفعال شدن افزونه و پاک‌سازی کش، این تگ‌ها نیز حذف می‌شوند.
- بررسی دستی: اگر پس از پاک‌سازی کش، تگ همچنان وجود داشت، باید سورس (Source) صفحه را بررسی کنید. ممکن است نیاز باشد کدها را به صورت دستی از فایل‌های قالب (مانند header.php) یا از طریق فایل functions.php (اگر به صورت دستی اضافه شده بود) حذف کنید.
مدیریت پس از حذف AMP: نظارت و اقدامات ضروری
پس از انجام مراحل فنی حذف AMP و تنظیم ریدایرکت‌های ۳۰۱، فرآیند اصلی وارد فاز نظارت و اعتبارسنجی می‌شود. در این مرحله، ما به طور فعال رصد می‌کنیم که گوگل چگونه به این تغییر ساختاری واکنش نشان می‌دهد. هدف، اطمینان از یک انتقال روان، حفظ کامل ترافیک موبایل و جلوگیری از بروز خطاهای فنی است.
استفاده از Google Search Console برای مانیتورینگ روند حذف
گوگل سرچ کنسول (GSC) ابزار اصلی و خط مقدم شما برای نظارت بر این مهاجرت است. تمام داده‌هایی که برای درک رفتار گوگل نیاز دارید، در این پنل وجود دارد.
ما از GSC استفاده می‌کنیم تا ببینیم:
- آیا گوگل ریدایرکت‌های ۳۰۱ ما را شناسایی کرده و در حال پردازش آن‌ها است؟
- آیا URLهای AMP در حال خروج از ایندکس و جایگزینی با URLهای اصلی هستند؟
- آیا این فرآیند منجر به ایجاد خطاهای جدید (مانند ۴۰۴ یا خطاهای خزش) شده است؟
بررسی گزارش “صفحات” و ناپدید شدن خطاهای AMP
پس از حذف AMP، گزارش اختصاصی «AMP» در منوی سرچ کنسول به مرور زمان ناپدید خواهد شد. تمرکز شما باید به گزارش «Pages» (در بخش Indexing) معطوف شود.
در این گزارش، باید به دقت روند زیر را مشاهده کنید:
- کاهش صفحات AMP: تعداد URLهایی که قبلاً به عنوان «صفحه AMP معتبر» (Valid AMP page) شناسایی شده بودند، باید به صورت روزانه کاهش یابد.
- صفر شدن: هدف نهایی این است که این عدد به صفر برسد. این به آن معناست که گوگل تمام صفحات AMP شما را از ایندکس خود حذف کرده (چون اکنون به نسخه‌های اصلی ریدایرکت می‌شوند).
- بررسی خطاهای قدیمی: اگر قبلاً خطاهای AMP (مثلاً Invalid AMP pages) داشتید، آن‌ها نیز باید همزمان با خروج این صفحات از ایندکس، ناپدید شوند.
نظارت بر ترافیک موبایل و رتبه‌بندی کلمات کلیدی
این مهم‌ترین بخش نظارت استراتژیک است. ما AMP را حذف کردیم با این فرض که صفحات اصلی (Canonical) ما به اندازه کافی سریع و بهینه (از نظر Core Web Vitals) هستند.
- بررسی ترافیک (Performance Report):
- به بخش Performance (عملکرد) در سرچ کنسول بروید.
- فیلتر Device را روی Mobile (موبایل) تنظیم کنید.
- نمودارهای کلیک (Clicks) و ایمپرشن (Impressions) را به دقت زیر نظر بگیرید.
- تحلیل: یک نوسان جزئی در روزهای اول انتقال طبیعی است. اما شما نباید شاهد افت شدید و ادامه‌دار در ترافیک موبایل باشید. اگر افت شدید رخ داد، به احتمال زیاد صفحات اصلی شما از نظر سرعت (CWV) یا تجربه کاربری (UX) به خوبی نسخه‌های AMP عمل نکرده‌اند.
- بررسی رتبه‌بندی (Rank Tracking):
- رتبه کلمات کلیدی مهم خود را، به ویژه در جستجوی موبایل، رصد کنید. اگر صفحات اصلی شما بهینه باشند، رتبه‌ها باید ثابت بمانند یا حتی در بلندمدت بهبود یابند (چون اکنون نسخه کامل و غنی‌تری از سایت را ارائه می‌دهید).
پیگیری خطاهای 404 احتمالی (صفحات AMP یتیم)
گاهی اوقات، قوانین ریدایرکتی که در سرور (مانند .htaccess) تنظیم کرده‌اید، ممکن است برخی الگوهای خاص URLهای AMP را پوشش ندهند. به این صفحات که اکنون وجود خارجی ندارند و ریدایرکت هم نمی‌شوند، «AMP یتیم» (Orphaned AMP) می‌گوییم.
- نحوه شناسایی:
- در سرچ کنسول، به گزارش Pages (صفحات) و بخش Not found (404) بروید.
- لیست URLهای ۴۰۴ را بررسی کنید.
- به دنبال URLهایی بگردید که همچنان ساختار AMP را دارند (مثلاً حاوی /amp/ یا ?amp=1 هستند).
- اقدام فوری:
- اگر چنین URLهایی پیدا کردید، به این معناست که قانون ریدایرکت شما جامع نبوده است.
- باید فوراً به فایل .htaccess یا تنظیمات سرور Nginx خود برگردید و قانون ریدایرکت را طوری اصلاح کنید که این الگوهای جا مانده را نیز شناسایی و به نسخه اصلی ۳۰۱ کند.
اشتباهات رایج در هنگام جداسازی AMP (تجربیات عملی)
حذف AMP فرآیندی حساس است و کوچکترین اشتباه در آن می‌تواند منجر به افت شدید ترافیک موبایل شود. بر اساس تجربیات عملی، بیشتر شکست‌ها در این فرآیند، ناشی از نادیده گرفتن پیش‌نیازهای فنی یا نداشتن صبر کافی برای مشاهده نتایج است.
اشتباه ۱: فراموش کردن ریدایرکت‌های ۳۰۱
این فاجعه‌بارترین و رایج‌ترین اشتباه فنی است. برخی مدیران سایت صرفاً افزونه AMP را غیرفعال می‌کنند، با این تصور که گوگل به صورت خودکار به صفحات اصلی برمی‌گردد.
- اتفاقی که می‌افتد: به محض غیرفعال‌سازی، تمام URLهای AMP که گوگل در طول سال‌ها ایندکس کرده (مانند page/amp/ یا page/?amp=1)، به خطای ۴۰۴ (Not Found) تبدیل می‌شوند.
- نتیجه عملی: ربات‌های گوگل با هزاران خطای ۴۰۴ در سایت شما مواجه می‌شوند. تمام ترافیک موبایلی که از نتایج جستجو به این صفحات هدایت می‌شد، از بین می‌رود و تمام اعتبار و بک‌لینک‌هایی که به آن URLهای AMP داده شده بود، از دست می‌رود.
- راه درست: هر URL مربوط به AMP باید به صورت جداگانه یا با یک قانون کلی (Rule) در سطح سرور، با ریدایرکت ۳۰۱ (Permanent Redirect) به نسخه اصلی (Canonical) خود هدایت شود.
اشتباه ۲: حذف AMP بدون بهینه‌سازی سرعت صفحه اصلی
این یک اشتباه بنیادی استراتژیک است. دلیل اصلی حذف AMP این است که ادعا می‌کنیم صفحه اصلی (Canonical) ما به همان اندازه سریع و بهینه است.
- اتفاقی که می‌افتد: شما یک نسخه AMP بسیار سریع (که از کش گوگل بارگذاری می‌شد) را حذف می‌کنید و کاربر موبایل را به صفحه اصلی خود می‌فرستید که استانداردهای Core Web Vitals (CWV) را پاس نمی‌کند.
- نتیجه عملی: گوگل بلافاصله متوجه این افت کیفیت تجربه کاربری (UX) می‌شود. اگر LCP، INP و CLS صفحه اصلی شما در موبایل ضعیف باشد، گوگل سیگنال منفی دریافت می‌کند. در این حالت، حتی با وجود ریدایرکت‌های صحیح، ممکن است با افت رتبه مواجه شوید، زیرا تجربه کاربری بدتری را نسبت به قبل ارائه می‌دهISید.
اشتباه ۳: عدم بررسی و اعتبارسنجی (Validate) در Google Search Console
بسیاری از افراد فرآیند را «تنظیم می‌کنند و فراموش می‌کنند» (Set it and forget it). آن‌ها ریدایرکت‌ها را اجرا می‌کنند اما هرگز نتایج را در گوگل سرچ کنسول (GSC) بررسی نمی‌کنند.
- اتفاقی که می‌افتد: ممکن است قانون ریدایرکت شما جامع نباشد و بخشی از URLهای AMP (مثلاً با ساختاری متفاوت) از قلم افتاده باشند (که به آن‌ها «AMP یتیم» می‌گوییم).
- نتیجه عملی: این URLهای جا مانده به خطای ۴۰۴ تبدیل می‌شوند و شما متوجه آن‌ها نخواهید شد مگر اینکه گزارش Pages (بخش Indexing) و زیرمجموعه Not found (404) را به دقت بررسی کنید. شما باید به صورت فعال در سرچ کنسول نظارت کنید که تعداد صفحات AMP معتبر در حال کاهش و در نهایت صفر شدن باشد و همزمان، خطای ۴۰۴ جدیدی ایجاد نشود.
اشتباه ۴: انتظار حذف فوری از نتایج جستجو (صبر کلید اصلی است)
این اشتباه ناشی از نداشتن درک درست از نحوه خزش (Crawl) و ایندکس گوگل است.
- اتفاقی که می‌افتد: مدیر سایت، یک روز پس از اعمال ریدایرکت‌ها، در گوگل جستجو می‌کند و می‌بیند که نتایج AMP (با علامت صاعقه) همچنان نمایش داده می‌شوند. او دچار وحشت شده و تصور می‌کند فرآیند شکست خورده است.
- نتیجه عملی: این فرآیند زمان‌بر است. گوگل باید تک‌تک URLهای AMP شما را مجدداً بخزد (Re-crawl)، ریدایرکت ۳۰۱ را شناسایی کند، آن را پردازش کرده و سپس تصمیم بگیرد که آن صفحه را از ایندکس حذف و با نسخه Canonical جایگزین کند.
- راه درست: برای یک سایت متوسط، این فرآیند می‌تواند از چند هفته تا چند ماه طول بکشد. تا زمانی که ریدایرکت‌های شما فعال هستند و در سرچ کنسول روند کاهشی صفحات AMP را مشاهده می‌کنید، باید صبور باشید.
آینده موبایل پس از AMP و تمرکز بر Core Web Vitals
آینده‌ای که از آن صحبت می‌کنیم، در واقع همین امروز است. با تغییر استراتژی گوگل و اولویت‌بندی معیارهای Core Web Vitals (CWV)، دوران اتکا به یک فریم‌ورک خاص مانند AMP برای دستیابی به سرعت در موبایل به پایان رسیده است.
تمرکز از «استفاده از یک تکنولوژی خاص» به «ارائه یک تجربه کاربری با کیفیت» تغییر کرده است.
گوگل دیگر نمی‌پرسد: “آیا شما از AMP استفاده می‌کنید؟”
بلکه می‌پرسد: “آیا صفحه شما، (صرف نظر از تکنولوژی آن)، برای کاربر سریع، تعاملی و پایدار است؟”
این تغییر، یک بازگشت به اصول اساسی بهینه‌سازی وب (Technical SEO) است. Core Web Vitals به سه معیار اصلی تقسیم می‌شود که تجربه واقعی کاربر را می‌سنجد:
- LCP (Largest Contentful Paint): سرعت بارگذاری (سرعت درک شده کاربر از بارگذاری محتوای اصلی).
- INP (Interaction to Next Paint): سرعت تعامل‌پذیری (اینکه صفحه چقدر سریع به کلیک‌ها، لمس‌ها و ورودی‌های کاربر پاسخ می‌دهد).
- CLS (Cumulative Layout Shift): ثبات بصری (اینکه آیا عناصر صفحه در حین بارگذاری جابجا می‌شوند و باعث کلیک‌های اشتباه می‌شوند یا خیر).
چرا این آینده بهتری است؟
- پایان محدودیت‌ها: AMP ذاتاً محدودکننده بود. حذف آن به معنای آزادی کامل در استفاده از جاوا اسکریپت سفارشی، ابزارهای CRO (بهینه‌سازی نرخ تبدیل)، ردیابی‌های تحلیلی پیچیده و پیاده‌سازی کامل هویت برند در صفحات موبایل است.
- پایان کار مضاعف: به جای مدیریت دو نسخه از سایت (Canonical و AMP)، تمام منابع فنی و مالی اکنون می‌توانند روی بهینه‌سازی همان یک نسخه اصلی و واحد متمرکز شوند.
- رقابت عادلانه: اکنون هر سایتی، چه کوچک و چه بزرگ، فرصت دارد تا با بهینه‌سازی فنی صفحات اصلی خود و پاس کردن معیارهای CWV، در نتایج موبایل جایگاه خوبی کسب کند. موفقیت دیگر در گرو نصب یک افزونه نیست، بلکه نیازمند بهینه‌سازی واقعی است.
در نهایت، آینده موبایل پس از AMP، یک وب “Canonical-First” است. وب‌سایتی که در آن، نسخه اصلی و کامل شما، قلب تپنده تجربه کاربری در تمام دستگاه‌ها، به ویژه موبایل، خواهد بود.
نتیجه‌گیری
در نهایت، تصمیم برای حذف AMP یک انتخاب استراتژیک برای بازپس‌گیری کنترل کامل بر تجربه کاربری موبایل است. با اولویت قرار گرفتن Core Web Vitals، دیگر دلیلی برای پذیرش محدودیت‌های فنی و تجاری AMP وجود ندارد. اگر صفحات اصلی (Canonical) شما بهینه، سریع و پاسخگو باشند، حذف AMP نه تنها ریسکی ندارد، بلکه یک گام ضروری برای بهبود اهداف تجاری (CRO) و کاهش هزینه‌های فنی نگهداری است. فرآیند را با دقت، بر اساس ریدایرکت‌های ۳۰۱ صحیح و نظارت کامل در سرچ کنسول انجام دهید تا از انتقال روان ترافیک و اعتبار سئو اطمینان حاصل کنید.
