اگر امروز سایت موبایل شما کند است، نصب AMP لزوماً درمان نیست. شاید یک نسخه دوم سریع بسازید، اما Checkout، Consent، Analytics یا تبلیغ در آن با نسخه اصلی فرق کند؛ شاید هم مشکل واقعی Hero سنگین، JavaScript ثالث یا سرور کند در همان سایت اصلی باقی بماند. از طرف دیگر، برای بعضی ناشران با Templateهای محدود و تیمی که AMP را خوب میشناسد، این چارچوب هنوز میتواند یک Constraint مفید برای حفظ Performance باشد.
AMP نه امتیاز ویژه سئو است، نه فناوری مرده و نه نسخه اضطراری هر سایت کند. یک Web component framework با قواعد Validation و Performance است. تصمیم درست باید میان چهار گزینه مقایسه شود: AMP بهعنوان نسخه Canonical، AMP جفتشده با نسخه عادی، AMP فقط برای بعضی Templateها، یا وب استاندارد Performance-first بدون AMP.
این راهنما با Snapshot ۹ اوت ۲۰۲۶ نوشته شده است؛ چون Google در ژوئیه ۲۰۲۶ نحوه اتصال Search به صفحه AMP را تغییر داد. در ادامه، وضعیت جاری، معماری Canonical، CSS/JavaScript، WordPress، Analytics، Consent، TCO، Pilot و روش خروج امن را بررسی میکنیم.
خلاصه اجرایی
- AMP مزیت رتبهبندی مستقل ندارد: Google صفحات AMP را مانند سایر صفحات و با استاندارد یکسان Index/Rank میکند.
- AMP فقط برای موبایل نیست: نام تاریخی آن Accelerated Mobile Pages بود، اما چارچوب کنونی Responsive است و میتواند روی Desktop نیز سرو شود.
- تغییر مهم ۲۰۲۶: Google Search از ژوئیه کاربران را مستقیم به AMP روی Host ناشر میفرستد و ارجاعات قدیمی AMP Viewer، AMP Cache و Signed Exchange را از راهنمای خود کنار گذاشته است.
- دو URL هزینه دارد: نسخه Paired به Canonical/amphtml، Parity محتوا/قابلیت، Analytics identity، Consent، تست و Redirect lifecycle نیاز دارد.
- AMP سرعت را تضمین نمیکند: تصویر، تبلیغ، Consent UI، Font، Server و Third-party هنوز میتوانند LCP، INP و CLS را خراب کنند.
- سایت کند را با Root cause اصلاح کنید: AMP ممکن است گزینه Pilot باشد؛ راه فرار از Performance debt در نسخه اصلی نیست.
- خروج باید طراحی شود: حذف ناگهانی Plugin یا خالیکردن AMP URL میتواند Error و نسخه قدیمی در Search بسازد؛ Redirect و Monitor لازم است.
AMP چیست؟
AMP یک پروژه متنباز و Framework مبتنی بر Web components است که با مجموعهای از قواعد، Runtime، Componentها، Validator و ابزارهای Optimizer ساخت صفحه سریع و پایدار را تسهیل میکند. عبارت «Accelerated Mobile Pages» نام تاریخی و هنوز Query رایج کاربران است؛ اما AMP امروز به موبایل محدود نیست.
راهنمای رسمی AMP در Google Search در نسخه بهروزشده ژوئیه ۲۰۲۶ صریح میگوید AMP روی همه Deviceها قابل مشاهده است و Google آن را مانند هر فناوری وب دیگری Index میکند. پس «نسخه سبک موبایل Google» تعریف دقیقی نیست.
AMP چه چیزی نیست؟
- Mobile-first indexing یا Responsive design نیست؛
- CDN، Cache plugin یا Image optimizer بهتنهایی نیست؛
- PWA نیست و Offline/Install/Push را خودکار فراهم نمیکند؛
- Schema یا Rich result نیست؛
- رتبه، Top Stories، Conversion یا Core Web Vitals خوب را تضمین نمیکند؛
- الزام Google برای انتشار خبر یا مقاله نیست.
چه چیزی در ژوئیه ۲۰۲۶ تغییر کرد؟
Changelog رسمی Google Search در ۱ ژوئیه ۲۰۲۶ اعلام کرد Search کاربران را مستقیم به صفحه AMP روی Host ناشر میفرستد. Google به همین دلیل ارجاعات منقضی به AMP Viewer، AMP Cache و Signed Exchange را از مستندات AMP خود حذف کرد. محتوای AMP همچنان مانند سایر صفحات رتبه میگیرد.
این تغییر سه نتیجه عملی دارد:
- Origin شما دوباره مرکز Delivery از Search است: Hosting، CDN، Cache، TLS، WAF و Availability ناشر اهمیت عملی مستقیم دارند.
- Business case قدیمی مبتنی بر Google AMP Cache باید بازنویسی شود: Cache عمومی Google را بهعنوان صرفهجویی تضمینی Server یا Pre-render رایگان فرض نکنید.
- تحلیل قدیمی URL Viewer/SXG منقضی است: تصمیم جاری را با معماری امروز بگیرید، نه Screenshot یا راهنمای چند سال قبل.
قاعده Freshness: هر Recommendation درباره AMP باید تاریخ، Surface و منبع داشته باشد. Google Search، Publisher origin، Cacheهای دیگر و مصرف مستقیم URL یک Context واحد نیستند.
AMP چگونه Performance را محدود و هدایت میکند؟
AMP با «کمکردن خودکار همه چیز» کار نمیکند؛ مجموعهای از Constraintها و Primitiveها میدهد تا Layout قابل پیشبینی و اجرای Script کنترلشدهتر باشد.
| لایه | نقش | نکته تصمیم |
|---|---|---|
| AMP HTML | Markup معتبر همراه Boilerplate و Componentهای AMP | Template و خروجی CMS باید Validation را حفظ کنند |
| AMP Runtime | مدیریت Component، Layout و بارگذاری Resource | خود Runtime نیز Dependency خارجی/نسخهدار است |
| AMP components | Image، Carousel، Form، Consent، Analytics و تعامل | Fit هر Component با Requirement واقعی تست شود |
| CSS constraint | Author CSS محدود و قابل Validation | Design system باید در Budget جا شود |
amp-script | Custom JavaScript در Web Worker با DOM/API محدود | معادل اجرای آزاد همه Libraryها نیست |
| Validator/Optimizer | تشخیص عدم انطباق و بهینهسازی خروجی | Validation سبز با UX/Business parity برابر نیست |
CSS و JavaScript امروز چه محدودیتهایی دارند؟
Specification رسمی AMP HTML مجموع Author stylesheet و Inline style را به ۷۵٬۰۰۰ Byte محدود میکند. این عدد یک Performance budget فنی است؛ نه تضمین Design ساده یا Accessible.
ادعای قدیمی «AMP هیچ JavaScript سفارشی ندارد» نیز مطلق نیست. مستند رسمی amp-script اجرای Custom JavaScript در Web Worker را با API و Mutation محدود توضیح میدهد؛ هر Inline script تا ۱۰٬۰۰۰ Byte و مجموع Scriptهای غیر Sandbox صفحه تا ۱۵۰٬۰۰۰ Byte سقف دارد. محدودیتها و Hash requirement باید در Build/CI تست شوند.
اگر Product برای کارکرد اصلی به DOM API یا Library ناسازگار نیاز دارد، دورزدن Constraintها معمولاً TCO و ریسک را بالا میبرد. «میتوان با amp-script ساخت» با «بهترین معماری برای ساخت» یکسان نیست.
چهار معماری ممکن
| معماری | URL/Template | مزیت | هزینه/ریسک |
|---|---|---|---|
| Canonical AMP | یک URL و همان نسخه AMP Canonical | یک Content/URL lifecycle و Parity ذاتیتر | کل Requirement باید در AMP Fit شود |
| Paired AMP | Canonical عادی + AMP URL | Pilot یا حفظ قابلیت کامل در نسخه اصلی | دو خروجی، Parity، Analytics و Migration debt |
| Partial/Template scope | AMP فقط برای Article یا Surface مشخص | Scope کوچک و قابل مقایسه | Journey بین Templateها و Rule پیچیدهتر |
| Non-AMP performance-first | یک نسخه استاندارد Responsive | آزادی Platform و یک Code path | Performance discipline را تیم باید بسازد و حفظ کند |
AMP و Responsive مقابل هم نیستند؛ AMP باید Responsive هم باشد. AMP و PWA نیز Alternative کامل یکدیگر نیستند: PWA درباره قابلیتها و Progressive enhancement مانند Install/Offline/Push است. برای تصمیم PWA، راهنمای معماری Progressive Web App را جدا ببینید.
Decision brief: پیش از نصب چه بنویسیم؟
| فیلد | پرسش |
|---|---|
| Problem | کدام Template/Segment/Metric ضعیف است و Root cause چیست؟ |
| Outcome | Read completion، Subscription، Ad revenue، Lead یا Purchase؟ |
| Baseline | LCP/INP/CLS، Error، Conversion و Cost فعلی در Field چیست؟ |
| Alternative | اصلاح همان Template استاندارد، Rebuild یا حذف Third-party چقدر هزینه دارد؟ |
| Parity | کدام Content، Navigation، Consent، Ad و Analytics باید دقیقاً حفظ شود؟ |
| Operations | چه کسی Validator، Dependency، Incident، Redirect و QA را مالک است؟ |
| Exit | AMP URLها در صورت توقف چگونه به Canonical منتقل میشوند؟ |
اگر مسئله فقط «امتیاز Lighthouse پایین است»، هنوز Problem درست تعریف نشده است. ابتدا Journey، Field data و Resource waterfall را بررسی کنید. چارچوب Baseline، Performance budget و ROI در راهنمای سرعت سایت، UX، سئو و تبدیل آمده است.
چه زمانی AMP میتواند Fit باشد؟
- Templateهای محتوایی نسبتاً پایدار و تکرارشونده دارید؛
- بخش عمده نیاز با Componentهای AMP و Budgetها سازگار است؛
- تیم از Constraint برای جلوگیری از Performance regression سود میبرد؛
- Publisher workflow، Ads، Paywall، Consent و Analytics در Pilot Parity دارند؛
- یک نسخه AMP یا Paired را بدون دو برابرکردن هزینه تحریریه تولید میکنید؛
- Field test نشان میدهد نسبت به Alternative استاندارد، Outcome بهتری با TCO قابل قبول دارد؛
- Owner، Validation gate، Monitoring و Exit plan دارید.
چه زمانی AMP احتمالاً Anti-fit است؟
- وباپ یا Checkout با State و Integration سفارشی زیاد دارید؛
- نسخه عادی قابل اصلاح است اما AMP برای پنهانکردن بدهی فنی پیشنهاد شده؛
- Theme/Plugin/Widgetهای اصلی WordPress در AMP حذف یا Degrade میشوند؛
- تیم نمیتواند Content/Feature/Analytics parity را مستمر QA کند؛
- دو URL باعث Duplicate event، Session break یا Governance مبهم میشود؛
- مزیت ادعایی فقط Top Stories، Lightning icon، Google Cache یا Rank boost قدیمی است؛
- Business case هزینه Build، Migration و Exit را نادیده میگیرد.
برای فروشگاه، AMP ممکن است روی Guide یا Product discovery Fit و روی Cart/Checkout Anti-fit باشد؛ اما این یک فرضیه است. Journey گسسته بین نسخهها میتواند Cart، Login، Coupon و Attribution را خراب کند. Task-to-task تست کنید، نه Page-to-page.
AMP و SEO: چه چیزی واقعاً درست است؟
Google میگوید معیار Index و Ranking برای AMP و سایر فناوریها یکسان است. بنابراین:
- AMP بهخودیخود Ranking boost ندارد؛
- AMP برای Top Stories شرط انحصاری نیست؛
- Lightning badge یا Viewer قدیمی را مزیت جاری فرض نکنید؛
- AMP معتبر هم بدون محتوای مفید، Canonical درست و Eligibility لازم موفق نمیشود؛
- Core Web Vitals خوب میتواند Page experience را بهتر کند، اما رتبه برتر را تضمین نمیکند؛
- نسخه AMP ناقص یا متفاوت میتواند به UX، Conversion و اعتماد آسیب بزند.
Core Web Vitals جاری LCP، INP و CLS هستند؛ FID از مجموعه جایگزین شده است. برای تعریف Threshold، Field/RUM، Lab diagnosis و Regression، راهنمای Core Web Vitals را بهکار ببرید.
Canonical و کشف نسخه Paired
اگر نسخه غیر AMP و AMP جدا دارید، ارتباط آنها بخشی از قرارداد انتشار است:
- صفحه Canonical غیر AMP به AMP معادل با
rel="amphtml"اشاره میکند؛ - صفحه AMP با
rel="canonical"به نسخه Canonical اصلی برمیگردد؛ - اگر AMP تنها نسخه و Canonical است، Canonical به همان URL اشاره میکند؛
- Status، Robots، Hreflang، Structured data و Sitemap باید با معماری هماهنگ باشند؛
- Redirect chain، Canonical loop و AMP URL یتیم در هر Release تست شوند.
Canonical ابزار ترجیح Index است، نه مجوز اختلاف اساسی. اگر AMP خلاصه ناقص، Navigation متفاوت یا CTA خراب دارد، رابطه Tag مشکل محصول را حل نمیکند. در ممیزی سراسری، URL pairها، Status/Canonical/amphtml و Sitemap را با چکلیست SEO Audit کنترل کنید.
Content و Feature parity
برای هر Template یک Parity matrix بسازید. «AMP معتبر است» فقط میگوید قواعد AMP را پاس کرده؛ نمیگوید تجربه معادل و درست است.
| لایه | کنترل Parity |
|---|---|
| Content | Title، Body، Author، Date، Citation، Image، Caption و Update note |
| SEO | Canonical، Metadata، Hreflang، Structured data و Internal link |
| Navigation | Header، Search، Category، Related و Footer ضروری |
| Business | CTA، Subscription، Ad، Paywall، Product/Lead transition |
| Privacy | Consent purpose، Preference، Revocation و Vendor behavior |
| Analytics | Event، Identity، Source، Conversion و Deduplication |
| Accessibility | Semantics، Keyboard، Focus، Alt، Label، Error و Zoom |
| Failure | Offline/Timeout، Ad fail، API fail، Consent fail و Recovery |
Differenceهای عمدی را در Decision log ثبت کنید. اگر AMP بخشی از Content را بهدلیل Validator حذف میکند، این باید Release blocker یا تصمیم آگاهانه باشد، نه رفتار خاموش Plugin.
Validation و QA
Validator لازم است اما کافی نیست. Pipeline پیشنهادی:
- Template را با داده واقعی، متن بلند فارسی، تصویر، Embed و Edge case بسازید؛
- AMP validation را در CI و پس از Render CMS اجرا کنید؛
- Canonical/amphtml، Status، Robots و Structured data را تست کنید؛
- Visual regression را روی Mobile/Desktop و RTL انجام دهید؛
- Keyboard، Screen reader، Zoom و Focus را بررسی کنید؛
- Event/Consent/Ad/Paywall و CTA را End-to-end تست کنید؛
- Lighthouse/Lab را چند Run و Field data را پس از حجم کافی تحلیل کنید؛
- Monitoring برای Invalid AMP، 4xx/5xx، JS error و Conversion anomaly بسازید.
برای Componentهای دسترسپذیر و مشارکت کاربران دارای معلولیت، راهنمای طراحی فراگیر و WCAG را در Definition of Done وارد کنید.
AMP و Performance: قبل/بعد را درست بسنجید
مقایسه یک AMP URL روی Cache با نسخه Origin روی شبکه دیگر عادلانه نیست. از ژوئیه ۲۰۲۶، Search مستقیم به Host ناشر میرود؛ بنابراین Origin delivery را در همان شرایط مقایسه کنید.
| لایه | معیار | تفکیک لازم |
|---|---|---|
| Field UX | LCP، INP، CLS و Navigation type | Template، Device، Country/Network، New/returning |
| Lab | Waterfall، Main thread، bytes، request و render | Throttle و Run ثابت؛ Median چند Run |
| Reliability | 5xx، Timeout، Resource failure و JS error | Origin/CDN/Third party |
| Journey | Task completion، next-page و Login/Cart continuity | AMP→non-AMP transition |
| Business | Qualified conversion، Revenue/Ad viewability و Retention | Attribution، Consent و Segment |
AMP ممکن است LCP را بهتر و Revenue را بدتر کند؛ یا نسخه استاندارد با حذف یک Vendor ارزانتر و سریعتر شود. Result را با Confidence interval و Guardrail گزارش کنید، نه فقط PSI score.
Analytics، Attribution و Identity
در معماری Paired، یک نفر ممکن است AMP و Canonical را در یک Journey ببیند. بدون قرارداد داده، دو User/Session، Self-referral، Event duplicate یا Conversion گمشده میسازید.
- Event taxonomy و Parameter parity بین نسخهها تعریف کنید؛
- Page type، AMP/non-AMP و Version را بدون PII ثبت کنید؛
- Identity و Consent را در تغییر Host/URL/Context تست کنید؛
- Purchase/Lead را در Back-end Deduplicate و با Transaction/Lead ID آشتی دهید؛
- Ad impression، Paywall، Subscribe و Scroll را با Definition یکسان بسنجید؛
- Release و Validation failure را در Dashboard Annotation کنید؛
- Fallback هنگام Block شدن Analytics/Consent vendor داشته باشید.
برای طراحی Warehouse، Source of truth و Reconciliation از راهنمای تحلیل داده بازاریابی و GA4 استفاده کنید. Attributed conversion بهتنهایی اثر افزایشی AMP را ثابت نمیکند.
Consent، تبلیغ و حریم خصوصی
AMP Component داشتن به معنی مجازبودن جمعآوری یا پردازش نیست. Purpose، Vendor، Retention، Revocation و سیاست جاری هر بازار باید مشخص باشند.
- Content اصلی پیش از تصمیم Consent قابل دسترسی و UI انتخاب متقارن باشد؛
- Ad/Analytics فقط طبق State و Purpose مجاز اجرا شوند؛
- Consent بین AMP و Canonical ناسازگار یا Reset نشود؛
- پیام Consent در RTL، Keyboard، Focus، Zoom و Small viewport تست شود؛
- PII در URL، Analytics parameter، Cache key یا Log ناخواسته وارد نشود؛
- مسدودشدن Vendor نباید Content یا Navigation را نابود کند.
AMP در WordPress
صفحه رسمی Plugin AMP در WordPress.org سه Template mode را توضیح میدهد:
| Mode | ساختار | ریسک اصلی |
|---|---|---|
| Standard | یک Theme و یک نسخه AMP | همه Theme/Pluginهای حیاتی باید سازگار یا اصلاح شوند |
| Transitional | یک Theme، نسخه AMP و non-AMP | Graceful degradation و Parity باید کنترل شود |
| Reader | دو Theme و دو نسخه | بیشترین Drift بصری/محتوا و هزینه نگهداری |
Plugin میتواند Markup ناسازگار را حذف یا Plugin ناسازگار را در AMP Suppress کند. این رفتار شاید Validation را سبز کند، اما اگر فرم، منو، Consent، Paywall یا Tracking حذف شود، Release موفق نیست.
چکلیست Pilot وردپرس
- نسخه جاری WordPress/PHP، تاریخ Update و Tested up to Plugin را همان روز بررسی کنید؛
- Backup قابل Restore و Staging همنسخه بسازید؛
- Theme، Page builder، SEO، Cache، Security، Ad، Form و Analytics را Inventory کنید؛
- یک یا دو Post type را Pilot و کل Site را همزمان فعال نکنید؛
- Validation error را به Component/Plugin مالک نسبت دهید؛
- Canonical/amphtml، Sitemap و Cache purge را خودکار تست کنید؛
- WooCommerce Cart/Checkout/My account را بدون Proof وارد Scope نکنید؛
- Disable/uninstall و Redirect AMP URLها را پیش از Launch تمرین کنید.
تعداد Install یا برچسب «Official» جای Compatibility test، Security review و Exit plan را نمیگیرد. نسخه، حداقل نیازمندی و Changelog Plugin متغیرند؛ آنها را در Decision record تاریخگذاری کنید.
Origin، CDN و Cache پس از تغییر ۲۰۲۶
وقتی Search کاربر را مستقیم به Host ناشر میفرستد، AMP Runtime جای معماری Delivery شما را نمیگیرد. HTML، Media، Font، API و Third-party باید روی Origin/CDN پایدار باشند.
- Cache key برای AMP/non-AMP، Cookie، Device و Consent را مستند کنید؛
- Canonical/amphtml و HTML تازه پس از انتشار Purge شوند؛
- Stale content، Signed URL و Personalized response ناخواسته Cache نشوند؛
- Origin bypass، TLS، WAF و Rate limit تست شوند؛
- Cache hit ratio، TTFB و 5xx بر Template/PoP مانیتور شوند؛
- Runtime/Component خارجی و Fail mode آنها دیده شوند.
برای طراحی Cache-Control، CDN، Purge و Personalization boundary، راهنمای معماری Cache سایت را ببینید.
ملاحظات AMP برای سایت ایرانی
شبکه و سرویس ثالث
روی اینترنت همراه، ISPها، شهرهای مختلف و گوشی اقتصادی تست کنید. دسترسی یا Latency Runtime، Font، Video، Ad، Analytics و Consent vendor ممکن است یکسان نباشد. Critical content باید Failure مستقل یک Third party را تحمل کند.
فونت فارسی و RTL
Budget CSS و Font را با Glyphهای فارسی/عربی، اعداد، تومان/ریال، نیمفاصله و Fallback واقعی تست کنید. Reader mode یا Sanitization Plugin نباید dir="rtl"، Language، Heading، Caption و Table را خراب کند.
درگاه، OTP و Journey فروش
اگر مقاله AMP به Product/Checkout عادی میرود، Cart state، Login، UTM، Consent و Back behavior را End-to-end بررسی کنید. قطع Session یا دو بار ثبت Event در مرز AMP→non-AMP میتواند تصمیم Performance را از نظر فروش بیارزش کند.
تحریم، Vendor و عملیات
Dependency، حساب، Billing، Support و دسترسی تیم را در شرایط واقعی بسنجید. برای هر سرویس ثالث Fallback و Owner داشته باشید. AMP بهخودیخود ریسک دسترسی CDN/Analytics/Ad خارجی را حل نمیکند.
مقایسه AMP با وب استاندارد Performance-first
| معیار | AMP | وب استاندارد Performance-first |
|---|---|---|
| Performance governance | Constraint و Validator آماده | Budget/CI/Architecture را تیم تعریف میکند |
| قابلیت سفارشی | در محدوده Component و amp-script | آزادتر، با ریسک JS/Third-party بیشتر |
| URL lifecycle | یک یا دو نسخه؛ Paired پیچیدهتر | معمولاً یک URL |
| CMS ecosystem | نیازمند Compatibility و Validation | سازگاری وسیعتر اما Discipline متغیر |
| SEO | استاندارد یکسان؛ بدون Boost مستقل | استاندارد یکسان |
| Migration/exit | amphtml/Redirect/Index monitor | وابسته به Rebuild عادی |
| Fit | Template پایدار و Constraintپذیر | تعامل پیچیده یا تیم Performance بالغ |
برای تجربه موبایل استاندارد، Responsive، Mobile-first indexing، Touch و تست دستگاه، راهنمای موبایلفرندلی و سئو موبایل را مبنا قرار دهید. AMP جای این اصول را نمیگیرد.
TCO و Business case
Plugin رایگان به معنی اجرای رایگان نیست. دفتر هزینه باید شامل این موارد باشد:
- Discovery، Prototype و سازگارکردن Theme/Plugin؛
- Design/Content/Analytics/Consent parity؛
- Validation CI، QA چند Device و Monitoring؛
- دو نسخه Template، Bug triage و Training؛
- Ad/Paywall/Revenue impact و Opportunity cost؛
- Dependency update، Incident و Security maintenance؛
- Migration، Redirect و پاکسازی در زمان Exit.
منفعت را از Revenue خام جدا کنید: تغییر Qualified conversion، Ad contribution یا Cost-to-serve نسبت به Alternative. اگر AMP و بهینهسازی نسخه استاندارد هر دو Candidate هستند، Pilot یا Staged rollout را با یک Outcome و Guardrail مشترک مقایسه کنید.
Pilot هشتهفتهای پیشنهادی
| مرحله | خروجی | Gate |
|---|---|---|
| هفته ۱ | Decision brief، Baseline و Alternative | Root cause و Outcome روشن است |
| هفته ۲ | Template/Plugin inventory و معماری URL | Parity/Exit map پذیرفته شده است |
| هفته ۳ | Prototype روی Staging | Validation + Critical task پاس میشوند |
| هفته ۴ | Analytics/Consent/Ad/Accessibility QA | Event و State mismatch صفر یا پذیرفتهشده است |
| هفته ۵ | انتشار محدود Template/Segment | Rollback و Alert آمادهاند |
| هفته ۶–۷ | Field data و Outcome | حجم و Window از پیش تعیینشده |
| هفته ۸ | TCO/Result/Decision | Scale، Iterate یا Exit مستند |
معیار اصلی را PSI score نگذارید. یک نمونه ناشر میتواند Read/Subscribe/Ad contribution و یک فروشگاه Product-to-purchase continuity را بسنجد. Guardrailها: Error، Accessibility، Consent loss، Duplicate event، Bounce transition، Support و Editorial time.
خروج امن از AMP
اگر Paired AMP را متوقف میکنید، راهنمای رسمی حذف AMP از Google Search این ترتیب را پیشنهاد میکند:
rel="amphtml"را از صفحه Canonical غیر AMP حذف کنید؛- AMP URL حذفشده را با ۳۰۱ یا ۳۰۲ به Canonical غیر AMP Redirect کنید؛
- Status، Redirect destination و Content equivalence را Test کنید؛
- کاهش Indexed AMP و Errorها را در Search Console پایش کنید؛
- Internal link، Sitemap، Cache و External campaign URLها را پاکسازی کنید؛
- Analytics annotation و مقایسه پس از مهاجرت را ثبت کنید.
هشدار: AMP URL را به سند خالی و Invalid تبدیل نکنید. Google توضیح میدهد ممکن است هنگام تشخیص Invalid بودن، آخرین نسخه معتبر قدیمی را همچنان سرو کند. Redirect روشن و قابل تست بسازید.
اگر AMP همان Canonical و تنها URL است، میتوانید در همان URL خروجی استاندارد غیر AMP را جایگزین کنید و URL/Metadata را حفظ کنید؛ اگر URL عوض میشود، قواعد کامل Site migration، Redirect map و Monitor لازماند. Disable Plugin بدون بررسی Mode و Redirect کافی نیست.
چکلیست تصمیم نهایی
- راهنمای جاری Google و AMP با تاریخ Snapshot خوانده شده است.
- Business case روی Rank boost، Top Stories، Viewer یا Google Cache قدیمی بنا نشده است.
- Problem، Root cause، Baseline، Outcome و Alternative روشناند.
- Canonical AMP، Paired، Partial یا non-AMP آگاهانه انتخاب شده است.
- Canonical/amphtml/Status/Robots/Sitemap/Hreflang تست خودکار دارند.
- Content، Feature، SEO، Analytics، Consent و Accessibility parity ثبت شده است.
- LCP، INP، CLS و Journey روی Field data سنجیده میشوند.
- WordPress Theme/Plugin/Mode روی Staging و Edge case تست شدهاند.
- Origin/CDN/Cache و Failure سرویس ثالث پس از تغییر ۲۰۲۶ پوشش داده شدهاند.
- RTL، فونت فارسی، تومان/ریال، درگاه/OTP و شبکه ایران QA شدهاند.
- TCO شامل Build، نگهداری، Parity، Incident و Exit است.
- Pilot محدود، Guardrail، Rollback و Decision rule دارد.
- در صورت خروج، Redirect AMP→Canonical و Monitor Search Console آماده است.
پرسشهای متداول
آیا AMP در سال ۲۰۲۶ هنوز برای سئو لازم است؟
خیر. AMP شرط رتبه یا Top Stories و دارای Boost مستقل نیست. Google صفحات AMP را مانند سایر فناوریها Index/Rank میکند. اگر Constraintهای AMP به Performance و Outcome شما با TCO بهتر کمک میکنند میتواند انتخاب شود؛ نه صرفاً برای SEO.
آیا Google هنوز AMP را از Cache یا Viewer خودش نمایش میدهد؟
طبق بهروزرسانی ۱ ژوئیه ۲۰۲۶ Google Search، کاربر مستقیماً به AMP روی Host ناشر میرود و ارجاعات قدیمی Viewer، AMP Cache و Signed Exchange از مستند Search حذف شدهاند. درباره Surface یا Cache دیگری جداگانه و با منبع همان Provider تصمیم بگیرید.
AMP بهتر است یا Core Web Vitals را مستقیم بهینه کنیم؟
Core Web Vitals هدف تجربهاند و AMP یکی از معماریهای ممکن. Root cause، LCP/INP/CLS Field، قابلیت، تیم و TCO را بسنجید. اغلب اصلاح Image، JavaScript، Font، Server و Third-party در نسخه استاندارد ارزش پایدار دارد؛ گاهی AMP Constraint ارزانتر است. Pilot مقایسهای پاسخ میدهد.
آیا نصب افزونه AMP در وردپرس کافی است؟
خیر. باید Mode، سازگاری Theme/Plugin، Validation، Canonical، Parity محتوا و قابلیت، Analytics، Consent، Accessibility، Cache و خروج را تست کنید. Plugin ممکن است Markup یا افزونه ناسازگار را Suppress کند و ظاهراً Validation را حل کند اما Task را بشکند.
چطور AMP را بدون آسیب SEO حذف کنیم؟
در معماری Paired، ابتدا rel="amphtml" را از Canonical بردارید، سپس AMP URL را به Canonical Redirect و Index/Error را پایش کنید. صفحه AMP را خالی/Invalid نگذارید. در Canonical AMP، نسخه استاندارد را روی همان URL جایگزین یا مهاجرت URL کامل اجرا کنید.
جمعبندی
AMP در ۲۰۲۶ یک Framework اختیاری برای Performance governance است، نه میانبُر رتبه. تغییر ژوئیه Google Search نیز تصمیمهای مبتنی بر Viewer، Cache و Signed Exchange قدیمی را بیاعتبار کرده است. امروز باید Origin، URL architecture، Parity، Measurement و TCO را از نو ببینید.
اگر یک Template پایدار دارید، Constraintهای AMP با قابلیتها سازگارند و Pilot در Field هم Performance و هم Outcome را بهتر میکند، استفاده از آن میتواند منطقی باشد. اگر نسخه دوم فقط بدهی فنی، داده دوگانه و تجربه ناقص میسازد، یک Web استاندارد سریع با Performance budget و عملیات قوی انتخاب بهتری است. در هر دو حالت، Exit plan را پیش از Launch بنویسید.
