موبایل فرندلی چیست؟ راهنمای سئو موبایل، UX و تست

موبایل فرندلی بودن یعنی کاربر بتواند در صفحه کوچک و با لمس، همان کار اصلی نسخه دسکتاپ را بدون زوم اجباری، اسکرول افقی، انتظار آزاردهنده یا خطای ناوبری انجام دهد. فقط کوچک شدن ستون‌ها کافی نیست: محتوا، لینک‌ها، فرم، خرید، پرداخت، دسترس‌پذیری و سرعت باید روی موبایل واقعاً کار کنند.

برای یک فروشگاه ایرانی، آزمون واقعی ساده است: آیا کاربر با یک گوشی میان‌رده، اینترنت ناپایدار و صفحه‌کلید فارسی می‌تواند محصول را پیدا کند، قیمت و هزینه ارسال را بفهمد، آدرس و کدپستی را وارد کند، از درگاه برگردد و نتیجه سفارش را ببیند؟ اگر پاسخ منفی است، سایت شاید «ریسپانسیو» باشد اما هنوز تجربه موبایل قابل اتکایی ندارد.

پاسخ کوتاه برای مدیر: نسخه موبایل منبع اصلی خزش و ایندکس گوگل است؛ بااین‌حال Mobile-first indexing به‌تنهایی امتیاز رتبه‌بندی نیست. کیفیت محتوا، قابلیت استفاده، Core Web Vitals و تجربه کلی صفحه را جداگانه بسنجید. ابتدا برابری محتوا و قابلیت تکمیل کار را تضمین کنید، سپس گلوگاه‌های واقعی را با داده میدانی رفع کنید.

موبایل فرندلی، Responsive و Mobile-first چه تفاوتی دارند؟

این اصطلاح‌ها به یک موضوع اشاره نمی‌کنند. اشتباه گرفتن آن‌ها باعث می‌شود تیم، قالبی واکنش‌گرا تحویل دهد و تصور کند سئو و تجربه کاربر هم حل شده است.

یک صفحه می‌تواند Responsive باشد اما دکمه‌های ریز، فرم خراب یا JavaScript سنگین داشته باشد. برعکس، یک صفحه ساده ممکن است بدون الگوی بصری پیچیده روی موبایل کاملاً قابل استفاده باشد. همچنین PWA بودن، خودبه‌خود به معنی سریع، قابل ایندکس یا خوش‌تجربه بودن نیست؛ جزئیات آن را در راهنمای سئو PWA و رندر JavaScript ببینید.

Mobile-first indexing در وضعیت فعلی گوگل

گوگل در ۳۱ اکتبر ۲۰۲۳ اعلام کرد انتقال به Mobile-first indexing کامل شده است. در عمل، Googlebot Smartphone نسخه موبایل را برای ایندکس و رتبه‌بندی می‌بیند. این یک روش خزش و جمع‌آوری محتواست، نه یک «شاخص جداگانه موبایل» و نه تضمین افزایش رتبه.

طبق راهنمای رسمی Mobile-first indexing گوگل، اگر نسخه موبایل محتوای اصلی کمتری از دسکتاپ داشته باشد، گوگل اطلاعات کمتری برای فهم صفحه خواهد داشت و احتمال افت ترافیک وجود دارد. می‌توانید محتوا را در Accordion یا Tab قرار دهید، اما نباید آن را فقط برای کوچک شدن صفحه حذف کنید.

چک‌لیست برابری نسخه موبایل و دسکتاپ

• عنوان صفحه، توضیح متا و Robots در هر دو نسخه هم‌ارز باشد.
• متن اصلی، Headingها، محصولات، قیمت، موجودی و شرایط خرید حذف نشوند.
• لینک‌های داخلی مهم در DOM موبایل و با عنصر واقعی <a href> حاضر باشند.
• Schemaهای مهم مانند Product، Breadcrumb، Article و VideoObject هم‌ارز بمانند.
• تصویر و ویدئو کیفیت، متن جایگزین و نشانی پایدار داشته باشند.
• فایل‌های CSS، JavaScript و تصویر برای Googlebot مسدود نشده باشند.
• محتوای اصلی برای بارگذاری به Swipe، Click یا تایپ کاربر وابسته نباشد.

برای مشاهده چیزی که گوگل دریافت و رندر می‌کند، URL Inspection در Search Console را به‌کار ببرید و HTML رندرشده، Screenshot، منابع مسدودشده و Canonical انتخابی را بررسی کنید. گزارش Crawl Stats نیز نوع Googlebot را نشان می‌دهد. اعلان قدیمی «انتقال سایت به Mobile-first» دیگر نقطه تصمیم عملیاتی روزمره نیست؛ گوگل پایان این انتقال را اعلام کرده است.

انتخاب معماری موبایل: Responsive، Dynamic یا URL جدا؟

گوگل هر سه پیکربندی را پشتیبانی می‌کند، اما Responsive Web Design را به‌دلیل پیاده‌سازی و نگهداری ساده‌تر توصیه می‌کند. تصمیم معماری را با هزینه چرخه عمر، ریسک اختلاف محتوا و توان تیم بگیرید.

اگر Dynamic serving دارید، پاسخ HTTP باید متناسب با معماری و Cache تنظیم شود؛ معمولاً Vary: User-Agent لازم است. در URL جدا نیز جفت‌سازی Canonical و Alternate، Redirect دوطرفه درست، Status و Sitemap را آزمایش کنید. مهاجرت اجباری سامانه پایدار به Responsive بدون تحلیل هزینه و ریسک، همیشه تصمیم بهتری نیست.

طراحی چیدمان بدون اسکرول افقی و شکست محتوا

صفحه را بر اساس «عرض‌های محتوایی» بسازید، نه فهرستی از مدل گوشی‌ها. Breakpoint زمانی لازم است که محتوا می‌شکند، نه فقط چون عرض دستگاه معروفی رسیده است.

Viewport و Reflow

<meta name="viewport" content="width=device-width, initial-scale=1">

نبودن Viewport صحیح باعث می‌شود مرورگر صفحه را با بوم دسکتاپ رندر و سپس کوچک کند. عرض ثابت را از Container، جدول، Embed، تصویر و کد حذف کنید. برای عناصر رسانه‌ای معمولاً max-width: 100% و برای Grid/Flex استفاده از اندازه‌های منعطف لازم است. در بزرگ‌نمایی ۲۰۰٪ و عرض باریک نیز متن و کنترل‌ها باید Reflow شوند؛ پنهان کردن Overflow درمان محتوای بریده نیست.

جدول، کد و محتوای عریض

برای جدول مقایسه‌ای، ستون‌های کم‌اهمیت را حذف نکنید. یکی از این الگوها را آگاهانه انتخاب کنید: اسکرول افقی داخل Container با نشانه بصری، تبدیل هر ردیف به Card در عرض کوچک، یا ارائه خلاصه و امکان مشاهده جزئیات. هدر ستون باید برای فناوری کمکی قابل تشخیص بماند.

تصویر واکنش‌گرا

با srcset و sizes فایل مناسب Viewport را بفرستید؛ صرفاً کوچک کردن تصویر ۲۰۰۰ پیکسلی با CSS، بایت دانلود را کم نمی‌کند. برای تصویر LCP، آدرس باید در HTML زود قابل کشف باشد و Lazy-load کردن آن معمولاً انتخاب خوبی نیست. برای تصاویر پایین صفحه، Lazy loading بومی را با Placeholder ابعادی و متن Alt مفید به‌کار ببرید.

ناوبری و اولویت محتوا در صفحه کوچک

موبایل فضای کم دارد، اما فضای کم مجوز حذف مسیرهای ضروری نیست. وظیفه اصلی هر Template را مشخص کنید: خواندن مقاله، یافتن محصول، مقایسه، تماس یا پرداخت. سپس محتوای بالای صفحه را به همان کار اختصاص دهید.

• لوگو، عنوان صفحه و مسیر بازگشت قابل فهم باشد.
• منوی همبرگری Label قابل دسترس، Focus و وضعیت باز/بسته روشن داشته باشد.
• جست‌وجو و فیلتر فروشگاه در یک Drawer بن‌بست ایجاد نکند.
• فیلترهای فعال و راه پاک‌کردن همه فیلترها دیده شوند.
• CTA چسبان، محتوا، دکمه سیستم و صفحه‌کلید را نپوشاند.
• Back مرورگر وضعیت صفحه یا سبد را ناخواسته از بین نبرد.

برای دیدن فرایند کامل تحقیق، معماری اطلاعات و سنجش، راهنمای طراحی تجربه کاربری را بخوانید.

طراحی لمسی، فونت و RTL فارسی

کاربر با انگشت و گاهی یک‌دست کار می‌کند. در WCAG ۲.۲ معیار سطح AA برای Target Size حداقل ۲۴×۲۴ پیکسل CSS یا فاصله کافی و استثناهای مشخص دارد؛ معیار ۴۴×۴۴ سطح AAA هدف راحت‌تری است. عدد ۴۸×۴۸ نیز یک الگوی رایج پلتفرمی است، نه قانون واحد همه سایت‌ها. اندازه را با داده خطا و سناریوی واقعی تنظیم کنید.

قواعد اجرایی رابط فارسی

• متن اصلی در عرض کوچک خوانا و Line-height کافی داشته باشد؛ یک عدد ثابت برای همه فونت‌های فارسی تجویز نکنید.
• Link فقط با رنگ متمایز نشود و Focus قابل مشاهده داشته باشد.
• آیکون بی‌متن برای عمل حساس مثل حذف، پرداخت یا برگشت کافی نیست.
• عدد، واحد، قیمت و ترکیب فارسی/لاتین را در دستگاه واقعی تست کنید؛ dir خودکار همیشه نتیجه مطلوب نمی‌دهد.
• جهت فلش‌ها را بر اساس معنا تعیین کنید: «بعدی» در رابط RTL با حرکت مکانی یکسان نیست.
• Zoom کاربر را با user-scalable=no یا maximum-scale=1 مسدود نکنید.
• صفحه را در حالت Landscape، افزایش اندازه متن و Dark mode سیستم نیز ببینید.

W3C توضیح می‌دهد که دسترس‌پذیری موبایل در استانداردهای موجود WCAG پوشش داده می‌شود و استاندارد جداگانه‌ای لازم نیست. لمس، صفحه کوچک و حالت‌های ورودی متفاوت را در همان برنامه Accessibility لحاظ کنید.

فرم موبایل: از صفحه‌کلید تا خطای قابل بازیابی

بخش بزرگی از شکست موبایل در فرم رخ می‌دهد، نه در صفحه اصلی. فرم خوب تعداد فیلد کمتر ندارد؛ فقط اطلاعات لازم را در زمان درست و با تعامل قابل پیش‌بینی می‌گیرد.

• برای هر Input یک Label پایدار و قابل برنامه‌خواندن قرار دهید؛ Placeholder جای Label نیست.
• autocomplete را برای نام، تلفن، ایمیل و آدرس درست تنظیم کنید.
• با inputmode صفحه‌کلید مناسب را پیشنهاد دهید، اما اعتبارسنجی را به نوع Keyboard نسپارید.
• شماره موبایل، کدملی و کدپستی را با رقم فارسی و لاتین بپذیرید و در Backend نرمال کنید.
• خطا را کنار همان فیلد، با متن قابل اقدام و Summary بالای فرم نشان دهید.
• پس از خطا، داده‌های درست را پاک نکنید و Focus را به محل مناسب ببرید.
• Paste در OTP و Password را نبندید؛ Timeout و درخواست مجدد باید روشن باشد.
• هنگام باز شدن Keyboard، CTA و خطا پشت آن پنهان نشوند.

Checkout و پرداخت برای کاربر ایرانی

در موبایل، Checkout یک زنجیره است: سبد، ورود یا مهمان، آدرس، ارسال، انتخاب پرداخت، انتقال به درگاه، Callback و صفحه نتیجه. اگر فقط صفحه قبل از درگاه را تست کنید، مهم‌ترین شکست‌های واقعی را نمی‌بینید.

سناریوهای ضروری تست

1. کاربر واحد تومان را می‌بیند اما درگاه مبلغ ریالی دریافت می‌کند؛ تبدیل و متن Summary باید بدون ابهام باشد.
2. اینترنت هنگام انتقال به درگاه یا بازگشت قطع می‌شود؛ Refresh نباید سفارش تکراری بسازد.
3. پرداخت موفق است اما Callback دیر می‌رسد؛ وضعیت «در حال بررسی» و مسیر پیگیری نشان دهید.
4. کاربر با Back به فروشگاه برمی‌گردد؛ سبد و سفارش نباید در وضعیت متناقض باشند.
5. OTP بانکی و Keyboard صفحه را جابه‌جا می‌کند؛ مسیر پرداخت در Android و iOS واقعی آزمایش شود.

جزئیات Guest checkout، فرم آدرس، ارسال و سنجش ریزش در راهنمای بهینه‌سازی Checkout فروشگاه آمده است.

سرعت موبایل را با Core Web Vitals بسنجید

سرعت یک زمان واحد نیست. سه Core Web Vital فعلی بارگذاری، پاسخ‌گویی و ثبات بصری را می‌سنجند. آستانه «خوب» در صدک ۷۵ بازدیدها، جداگانه برای موبایل و دسکتاپ، چنین است:

امتیاز خوب Lighthouse تضمین نمی‌کند کاربران واقعی تجربه خوبی داشته باشند و امتیاز خوب CWV نیز تضمین رتبه بالا نیست. گوگل تصریح می‌کند تجربه صفحه چندوجهی است و ارتباط محتوا همچنان تعیین‌کننده است. برای روش تشخیص و بهینه‌سازی دقیق، به راهنمای LCP، INP، CLS و RUM مراجعه کنید.

Lab و Field را با هم استفاده کنید

برای بازار ایران، Segmentها را با داده خودتان بسازید: Android کم‌حافظه در برابر دستگاه قوی، اینترنت همراه در برابر ثابت، مرورگر درون‌برنامه‌ای در برابر Chrome/Safari، Template محصول در برابر مقاله، و کاربران داخل در برابر خارج کشور. میانگین کل می‌تواند درد یک گروه مهم را پنهان کند.

رفع LCP، INP و CLS بر اساس علت

LCP: عنصر واقعی را پیدا کنید

ابتدا مشخص کنید LCP در بازدیدهای کند تصویر Hero است، متن است یا پوستر ویدئو. سپس سهم TTFB، تأخیر کشف Resource، زمان دانلود و Render delay را جدا کنید. راه‌حل ممکن است Cache و Backend، کوچک‌سازی تصویر، حذف Lazy-load از Hero، Preload محدود فونت یا کاهش CSS مسدودکننده باشد؛ نسخه واحدی برای همه صفحات وجود ندارد.

INP: مسیر تعامل را اندازه بگیرید

روی منو، فیلتر، افزودن به سبد، جست‌وجو و تایپ فرم تمرکز کنید. Long taskهای JavaScript را خرد کنید، کار غیرضروری Third-party را عقب بیندازید، تعداد Componentهای Re-renderشونده را کم کنید و پس از به‌روزرسانی UI به مرورگر فرصت Paint بدهید. حذف کورکورانه همه Scriptها جای Attribution را نمی‌گیرد.

CLS: فضا را پیش از رسیدن محتوا رزرو کنید

برای تصویر، ویدئو، تبلیغ، Banner رضایت و Widget ابعاد یا نسبت تصویر تعیین کنید. فونت فارسی را با Fallback دارای Metric نزدیک آزمایش کنید. پیام خطا، موجودی و هزینه ارسال را طوری درج کنید که محتوای در حال لمس ناگهان جابه‌جا نشود.

بودجه بایت و درخواست برای موبایل

Minify راهبرد کامل عملکرد نیست. مهم‌تر از حذف فاصله کد، کم کردن JavaScript اجراشونده، تصویر نامتناسب، فونت‌های زیاد و Third-partyهای کم‌ارزش است.

• هر Template بودجه جدا برای JavaScript، CSS، تصویر، فونت و درخواست Third-party داشته باشد.
• Bundle را بر اساس Route و قابلیت Split کنید؛ کد صفحه محصول را در مقاله نفرستید.
• Widget چت، Heatmap، تبلیغ و Tag marketing را بر اساس ارزش و Consent بارگذاری کنید.
• فونت فارسی فقط وزن‌ها و Glyphهای لازم را بفرستد و رفتار Swap آزموده شود.
• Cache-Control و نسخه‌گذاری Asset روشن باشد؛ HTML شخصی را در CDN عمومی Cache نکنید.
• مبدأ، CDN و TTFB را برای کاربر داخل ایران جدا بسنجید؛ راهنمای انتخاب CDN برای سایت ایرانی معیار PoC را توضیح می‌دهد.

محتوا، لینک و SEO فنی در نسخه موبایل

موبایل‌فرندلی بودن فقط CSS نیست. صفحه باید برای کاربر و Googlebot قابل دریافت، فهم و پیمایش باشد.

مواردی که در هر Template کنترل می‌شوند

• پاسخ HTTP، Canonical، Robots و Hreflang
• Title، Meta description، H1 و سلسله Heading
• محتوای اصلی و متن Anchor لینک‌های داخلی
• داده ساختاریافته و شناسه‌های محصول یا مقاله
• Pagination، Facet، Load more و URLهای قابل Crawl
• تصویر، Alt، Caption و نشانی پایدار Media
• Soft ۴۰۴، Redirect، صفحه خطا و حالت بدون نتیجه

اگر Infinite scroll دارید، هر بخش مهم باید URL قابل دسترسی و لینک استاندارد داشته باشد. اگر محتوای اصلی فقط پس از تعامل کاربر وارد DOM می‌شود، Googlebot ممکن است آن را نبیند. Accordion برای فشرده‌سازی ارائه مجاز است، به شرط آن‌که محتوای لازم واقعاً در نسخه موبایل موجود و قابل رندر باشد.

پاپ‌آپ، تبلیغ و لایه‌های مزاحم

یک Overlay روی دسکتاپ شاید کوچک به‌نظر برسد اما در موبایل کل محتوای اصلی را می‌پوشاند. گوگل در راهنمای تجربه صفحه، نمایش مناسب موبایل، نبود تبلیغ بیش‌ازحد و پرهیز از Interstitial مزاحم را بخشی از ارزیابی کلی تجربه می‌داند.

• Banner ضروری قانونی را تا حد ممکن کوچک و قابل بستن طراحی کنید.
• Modal خبرنامه را در ورود فوری نشان ندهید و Context کار را قطع نکنید.
• دکمه بستن اندازه و Label مناسب داشته و زیر Safe area پنهان نباشد.
• Keyboard، Modal روی Modal و Scroll lock را در Safari و Chrome واقعی تست کنید.
• CTA شناور با Cookie banner، چت و Navigation پایین روی هم نیفتد.

روش درست تست موبایل فرندلی بودن سایت

به‌روزرسانی مهم: Mobile-Friendly Test و گزارش Mobile Usability در Search Console از ۱ دسامبر ۲۰۲۳ بازنشسته شده‌اند. صفحه قدیمی گوگل نیز صریحاً وضعیت Retired این دو ابزار را نشان می‌دهد. بنابراین برنامه ممیزی را بر ابزارهای موجود و آزمون انسانی بنا کنید.

۱. نمونه Template و کارهای حیاتی را انتخاب کنید

فقط صفحه اصلی را تست نکنید. یک URL از مقاله، دسته، جست‌وجو، محصول، سبد، Checkout، ورود، فرم تماس و خطا انتخاب کنید. برای هرکدام یک Task روشن بنویسید؛ مانند «محصول ناموجود را تشخیص بده و جایگزین پیدا کن» یا «پرداخت ناموفق را بدون سفارش تکراری بازیابی کن».

۲. ماتریس دستگاه، مرورگر و شبکه بسازید

Device Mode مرورگر برای بازتولید سریع مفید است، اما Touch، حافظه، GPU، Keyboard، Safe area، نوار آدرس و مرورگر واقعی را کامل شبیه‌سازی نمی‌کند. خروجی آن را با گوشی واقعی تکمیل کنید.

۳. چهار لایه فنی را جدا بررسی کنید

1. دریافت: Status، Redirect، Robots، Resource و Cache.
2. رندر: HTML اولیه در برابر DOM رندرشده، Layout، Font و JavaScript error.
3. ایندکس: URL Inspection، Canonical انتخابی، داده ساختاریافته و لینک‌ها.
4. تجربه: تکمیل Task، خطا، زمان، Core Web Vitals و Accessibility.

۴. از ابزار مناسب برای پرسش مناسب استفاده کنید

• URL Inspection: آیا گوگل URL و محتوای رندرشده را می‌بیند؟
• Rich Results Test: داده ساختاریافته قابل شناسایی است؟
• PageSpeed Insights و CrUX: داده میدانی در دسترس چه می‌گوید؟
• Lighthouse و DevTools: علت فنی قابل بازتولید چیست؟
• RUM: کدام Segment، Template و Release واقعاً مشکل دارد؟
• تست کاربردپذیری: کاربر کجا مکث، خطا یا رها می‌کند؟

برای طراحی جلسه، جذب نمونه و تحلیل Severity از راهنمای تست کاربردپذیری استفاده کنید.

اولویت‌بندی خطاهای موبایل

فهرست صدتایی Lighthouse برنامه محصول نیست. هر مشکل را با چهار عامل امتیاز دهید: تعداد کاربران در معرض، شدت مانع، ارزش کار متوقف‌شده و اطمینان شواهد. سپس هزینه و ریسک اصلاح را اضافه کنید.

هر Ticket باید URL/Template، دستگاه، مرورگر، شبکه، مراحل بازتولید، نتیجه فعلی، نتیجه مورد انتظار و شواهد ویدئویی یا Trace داشته باشد. عبارت «روی موبایل خراب است» قابل تحویل و Verify نیست.

مثال عملی: ممیزی موبایل یک فروشگاه ایرانی

فرض کنید داده Analytics نشان می‌دهد ریزش موبایل در مرحله آدرس بالاست. تیم به‌جای تغییر رنگ CTA، ابتدا Sessionهای واجد رضایت و Event funnel را بررسی می‌کند و سپس پنج سناریوی واقعی اجرا می‌کند.

1. در Android میان‌رده، صفحه‌کلید عددی روی فیلد کدپستی می‌آید اما رقم فارسی رد می‌شود.
2. پیام خطا فقط بالای فرم است و پس از Scroll دیده نمی‌شود.
3. با باز شدن Keyboard، دکمه ادامه زیر نوار چسبان قرار می‌گیرد.
4. در بازگشت از درگاه با اینترنت ناپایدار، صفحه نتیجه وضعیت نامشخص نشان می‌دهد.
5. Script چت هنگام تعامل اولیه Long task می‌سازد و INP همان Template را بدتر می‌کند.

راه‌حل به‌ترتیب می‌تواند نرمال‌سازی رقم در Backend، خطای Inline و Focus management، اصلاح Layout با Visual viewport، وضعیت قابل بازیابی سفارش و تأخیر کنترل‌شده Widget چت باشد. موفقیت با کاهش خطای اعتبارسنجی، افزایش نرخ تکمیل Checkout و بهتر شدن INP همان Segment سنجیده می‌شود؛ نه صرفاً یک امتیاز کلی جدید.

داشبورد و گاردریل انتشار

موبایل فرندلی بودن پروژه یک‌باره نیست. تغییر قالب، Tag manager، فونت، Checkout یا کمپین می‌تواند Regression بسازد. برای Templateهای حیاتی این گاردریل‌ها را در Release قرار دهید:

• Screenshot و Visual regression در چند عرض محتوایی
• تست Keyboard، Focus، Zoom و Reduced motion
• تست خودکار Link، Status، Canonical، Robots و Schema
• Performance budget در CI و Synthetic check پس از Deploy
• Canary یا انتشار مرحله‌ای برای Checkout و Scriptهای سراسری
• هشدار RUM بر اساس Template و نسخه، نه میانگین کل سایت
• تست دوره‌ای دستگاه واقعی و جلسه کوتاه با کاربر هدف

داشبورد مدیر بهتر است کنار CWV، نرخ موفقیت Task، خطای فرم، رهاشدگی Checkout، خطای JavaScript، وضعیت API و نرخ بازگشت موفق از پرداخت را نشان دهد. هدف «سبز کردن ابزار» نیست؛ هدف حفظ مسیر کاربر است.

برنامه ۳۰، ۶۰ و ۹۰روزه بهینه‌سازی موبایل

روز ۱ تا ۳۰: Baseline و رفع Blocker

• Templateها و کارهای حیاتی را فهرست و مالک هرکدام را تعیین کنید.
• Mobile/Desktop parity، Status، Canonical و Robots را ممیزی کنید.
• Checkout، ورود، جست‌وجو و فرم تماس را روی دستگاه واقعی تست کنید.
• خطاهای S0/S1 و مشکل‌های Accessibility مسدودکننده را رفع کنید.
• Baseline موبایل برای LCP، INP، CLS و نرخ تکمیل Task بسازید.

روز ۳۱ تا ۶۰: رفع علت و استانداردسازی

• LCP/INP/CLS را در Templateهای پرترافیک Attribution و اصلاح کنید.
• Componentهای فرم، Modal، Navigation، Table و Media را استاندارد کنید.
• بودجه JavaScript، تصویر، فونت و Third-party تصویب کنید.
• RUM را با حداقل‌سازی داده و Segmentهای مفید راه‌اندازی کنید.
• Design review و Definition of Done موبایل را وارد فرایند تیم کنید.

روز ۶۱ تا ۹۰: پیشگیری و یادگیری

• تست‌های فنی و Visual را به CI/CD متصل کنید.
• هشدار Regression بر اساس Template/Release بسازید.
• تست کاربردپذیری دوره‌ای را روی کارهای پرارزش برنامه‌ریزی کنید.
• Backlog را با فراوانی، شدت، ارزش و شواهد بازامتیازدهی کنید.
• نتیجه کسب‌وکار و تجربه را با Baseline مقایسه و تصمیم بعدی را ثبت کنید.

چک‌لیست نهایی موبایل فرندلی

• یک H1 روشن و محتوای اصلی هم‌ارز دسکتاپ وجود دارد.
• Title، Meta، Robots، Canonical، Schema و لینک‌های مهم هم‌ارزند.
• صفحه در عرض باریک، Zoom و متن بزرگ Reflow می‌شود.
• هیچ کنترل حیاتی زیر Overlay، Keyboard یا Safe area پنهان نیست.
• Tap target، Focus، Label، Contrast و ترتیب Keyboard آزموده شده‌اند.
• فرم رقم فارسی/لاتین، Paste، Autocomplete و خطای قابل بازیابی دارد.
• پرداخت ناموفق، Callback دیرهنگام و Refresh سفارش را خراب نمی‌کند.
• تصویر Responsive است و LCP Hero بی‌دلیل Lazy-load نشده است.
• LCP، INP و CLS در صدک ۷۵ موبایل با Field data پایش می‌شوند.
• HTML اولیه، DOM رندرشده و URL Inspection تناقض مهم ندارند.
• محتوای اصلی برای ظاهر شدن به تعامل اجباری وابسته نیست.
• Templateهای اصلی روی Android، iOS و شبکه ناپایدار تست شده‌اند.
• هر نقص Severity، مالک، معیار پذیرش و Release هدف دارد.
• پس از انتشار، RUM و KPI کسب‌وکار Regression را آشکار می‌کنند.

پرسش‌های متداول

آیا Mobile-first indexing یعنی نسخه موبایل رتبه بیشتری می‌گیرد؟

نه. این اصطلاح یعنی گوگل عمدتاً محتوای نسخه موبایل را برای خزش و ایندکس مبنا می‌گیرد. خودِ این روش امتیاز رتبه‌بندی جداگانه نیست. محتوای مرتبط، Core Web Vitals و تجربه کلی صفحه عوامل و ملاحظات متفاوتی‌اند.

آیا Responsive بودن برای موبایل فرندلی بودن کافی است؟

نه. Responsive فقط روش تطبیق چیدمان است. قابلیت خواندن، لمس، فرم، Navigation، پرداخت، Accessibility، سرعت و برابری محتوای نسخه موبایل باید جداگانه آزموده شوند.

اکنون به‌جای Mobile-Friendly Test از چه ابزاری استفاده کنیم؟

برای وضعیت گوگل URL Inspection، برای داده میدانی PageSpeed Insights/CrUX و Search Console Core Web Vitals، برای تشخیص Lighthouse و DevTools، و برای تجربه واقعی دستگاه و تست کاربردپذیری را ترکیب کنید. Mobile-Friendly Test و گزارش Mobile Usability بازنشسته شده‌اند.

آیا عدد ۴۸×۴۸ پیکسل برای همه دکمه‌ها اجباری است؟

نه. WCAG ۲.۲ در سطح AA معیار ۲۴×۲۴ پیکسل CSS یا فاصله و استثناهای مشخص دارد؛ ۴۴×۴۴ معیار سطح AAA است. ۴۸×۴۸ یک توصیه رایج پلتفرمی است. اندازه و فاصله را با استاندارد هدف و خطای کاربر واقعی تعیین کنید.

هر چند وقت یک‌بار سایت موبایل را تست کنیم؟

پایش فنی و RUM باید پیوسته باشد. پس از تغییر قالب، Script سراسری، فرم یا Checkout تست هدفمند انجام دهید؛ برای مسیرهای حیاتی نیز آزمون دوره‌ای دستگاه واقعی و تست با کاربر را در تقویم Release قرار دهید.

جمع‌بندی

سایت موبایل فرندلی با یک Badge یا امتیاز واحد تعریف نمی‌شود. موفقیت یعنی نسخه‌ای که Googlebot Smartphone محتوای کامل آن را می‌فهمد و کاربر ایرانی روی دستگاه و شبکه واقعی می‌تواند هدفش را بدون مانع انجام دهد. از برابری محتوا و کار حیاتی شروع کنید، Field data را به علت فنی وصل کنید، نقص‌ها را بر اساس شدت اولویت دهید و با گاردریل انتشار از بازگشت آن‌ها جلوگیری کنید.