رفع خطاهای Mobile Usability

سلام! من نگینم.

فهرست محتوا پنهان

1 چرا خطاهای کاربری موبایل، رتبه سئوی شما را نابود می‌کنند؟ (فراتر از گزارش سرچ کنسول)

2 کالبدشکافی خطای ۱: “Text too small to read” (متن برای خواندن خیلی کوچک است)

3 کالبدشکافی خطای ۲: “Clickable elements too close together” (عناصر قابل کلیک خیلی نزدیک به هم)

4 کالبدشکافی خطای ۳: “Content wider than screen” (محتوای عریض‌تر از صفحه)

5 کالبدشکافی خطای ۴: “Viewport not set” (ویوپورت تنظیم نشده است)

6 جعبه ابزار شما: از شناسایی تا تایید رفع خطا

7 جمع‌بندی

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

خیلی از ماها تا چشممون به گزارش Experience (تجربه کاربری) می‌خوره، استرس می‌گیریم و فکر می‌کنیم با یه غول فنی طرفیم.

اما بذار یه چیزی بهت بگم: این خطاها (مثل متن ریز، دکمه‌های نزدیک به هم یا محتوای عریض‌تر از صفحه) غول فنی نیستن؛ اینا صدای کاربرای ما هستن که دارن میگن «دارم اذیت میشم!». اینا دقیقاً همون چیزایی‌ان که اعتماد کاربر رو می‌کُشن و گوگل رو قانع می‌کنن که سایت ما اون «تجربه رضایت‌بخش» رو نداره.

تو این گپ‌وگفت، می‌خوایم این خطاها رو نه مثل یه برنامه‌نویس، بلکه مثل یه متخصص تجربه کاربری «کالبدشکافی» کنیم و ببینیم چطور با چند تا راه حل ساده، می‌تونیم دوباره دل کاربر (و گوگل) رو به دست بیاریم. آماده‌ای؟

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

خطای Mobile Usability	ترجمه‌ی فنی	حسی که به کاربر می‌ده (تجربه‌ی بد)
Text too small	فونت ریز است	«انگار براشون مهم نبودم که بخونمش!» (حس بی‌احترامی)
Clickable elements too close	دکمه‌ها به‌هم چسبیده‌اند	«اه! باز اشتباهی کلیک کردم!» (حس کلافگی و عصبانیت)
Content wider than screen	اسکرول افقی ایجاد شده	«این سایت چقدر شلخته و داغونه!» (حس عدم اعتماد) ³
Viewport not set	صفحه زوم اوت شده	«من الان باید اینو زوم کنم؟» (حس گیج شدن و کلافگی)

چرا خطاهای کاربری موبایل، رتبه سئوی شما را نابود می‌کنند؟ (فراتر از گزارش سرچ کنسول)

خیلی از ماها وقتی گزارش «Mobile Usability» رو می‌بینیم، باهاش مثل یه چک‌لیست فنی رفتار می‌کنیم. «آها، فونت ریزه، درستش کن.» یا «دکمه‌ها نزدیکن، فاصله‌شون بده.» اما واقعیت اینه که این گزارش، اصلاً یه موضوع فنی نیست؛ یه موضوع کاملاً انسانی و تجربی هست.

گوگل داره به ما میگه: «ببین، کاربرت داره اذیت می‌شه!» و اگه ما فقط برای رفع تیک سبز سرچ کنسول کار کنیم، نه برای اون کاربر واقعی، باختیم. ما باید محتوایی «مردم-محور» (People-First) بسازیم، نه «موتور جستجو-محور». اون خطای فنی، در واقع یه «خطای تجربی» برای کاربره. کاربری که تو اولویت اصلی کسب‌وکار ماست.

درک عمیق Mobile-First Indexing: گوگل ابتدا نسخه موبایل شما را می‌بیند

اینو دیگه فکر کنم همه‌مون می‌دونیم: گوگل اول با یه «عینک موبایلی» میاد سراغ سایت ما. یعنی اون ربات خزنده‌ای که قراره به سایت ما رتبه بده، خودش رو جای یه کاربر موبایلی می‌ذاره.

حالا اگه اون کاربر (یعنی گوگل) بیاد و سایت شما رو مثل همون سایت بلیط اتوبوسِ داغون ببینه، چی فکر می‌کنه؟ فکر می‌کنه کل سایت شما همینه! دیگه براش مهم نیست که نسخه‌ی دسکتاپ شما چقدر شیک و فوق‌العاده‌ست.

گوگل دنبال یه «توضیح کامل و جامع» از موضوعه و اگه دسترسی به این توضیح تو موبایل سخت باشه، یعنی شما نتونستید اون پوشش کامل رو ارائه بدید.

تجربه کاربری (UX) به عنوان فاکتور E-E-A-T (چگونه خطای موبایل، اعتماد را می‌کشد)

اینجا بخش مورد علاقه‌ی منه! ما خیلی در مورد E-E-A-T (تجربه، تخصص، اعتبار، اعتماد) حرف می‌زنیم. اما معمولاً یادمون میره که «اعتماد» (Trust) فقط با محتوای متنی خوب ساخته نمی‌شه.

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

یه خطای موبایلی ساده، مستقیماً به «اعتبار» و «اعتماد» سایت شما شلیک می‌کنه. نشون می‌ده که شما اون «تخصص» یا «تجربه» واقعی رو برای ارائه یه سرویس بی‌نقص نداشتید.

ارتباط مستقیم خطاهای موبایل با افزایش Bounce Rate و کاهش Dwell Time

برگردیم به داستان اول من. من دقیقاً در چند ثانیه «Bounce» کردم (سایت رو ترک کردم). چرا؟ چون اون سایت نتونست به هدف من (خرید بلیط) کمکی کنه.

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

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

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

کالبدشکافی خطای ۱: “Text too small to read” (متن برای خواندن خیلی کوچک است)

این خطا یعنی کاربر شما داره برای خوندن محتوا، زجر می‌کشه. داره با دو تا انگشتش صفحه رو زوم می‌کنه (Pinch to Zoom) تا بتونه بفهمه چی به چیه. این دقیقاً نقطه‌ی مقابل یه «تجربه‌ی رضایت‌بخش» هست. کاربر تو این حالت نه تنها احساس رضایت نمی‌کنه، بلکه احساس کلافگی می‌کنه و احتمالاً قبل از اینکه به هدفش برسه، صفحه رو می‌بنده و می‌ره.

علت اصلی: چرا متن در موبایل کوچک نمایش داده می‌شود؟ (مشکل Viewport و فونت ثابت)

خب، مشکل از کجا آب می‌خوره؟ معمولاً دو تا متهم اصلی داریم:

۱. متهم ردیف اول: Viewport تنظیم نشده. بذار ساده بگم. Viewport همون «پنجره‌ی دید» مرورگره. وقتی تو به مرورگر موبایل نگی «هِی، من دارم یه سایت موبایلی بهت می‌دم، خودتو با این صفحه کوچیک وفق بده»، اونم فرض می‌کنه داره یه صفحه‌ی دسکتاپ بزرگ رو باز می‌کنه. در نتیجه، کل سایت دسکتاپ رو می‌چپونه تو اون صفحه‌ی ۶ اینچی! نتیجه‌اش هم می‌شه یه مشت متن مورچه‌ای که قابل خوندن نیست.

۲. متهم ردیف دوم: فونت‌های پیکسلی (px) لجوج! وقتی تو اندازه‌ی فونت رو مثلاً روی 14px قفل می‌کنی، به مرورگر می‌گی «کاری ندارم رو چه دستگاهی هستی، این متن باید دقیقاً ۱۴ پیکسل باشه.» خب، ۱۴ پیکسل روی یه مانیتور ۲۴ اینچی دسکتاپ یه اندازه‌ست، روی یه موبایل ۶ اینچی یه چیز دیگه. این «لجاجت» پیکسلی باعث می‌شه متن شما انعطاف‌پذیر نباشه و رو بعضی صفحه‌ها زیادی کوچیک دیده بشه.

راه حل ۱ (ضروری): تنظیم صحیح تگ Meta Viewport

این اولین و حیاتی‌ترین قدمه. این کد یه خطی، یه جور «فرمان» به مرورگر موبایله. باید این تگ رو تو قسمت <head> سایتت بذاری:

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

ترجمه‌اش برای مرورگر:

width=device-width: ببین مرورگر، عرض سایت من رو دقیقاً به اندازه‌ی عرض همین دستگاهی که دست کاربره در نظر بگیر (نه بیشتر، نه کمتر).
initial-scale=1.0: زوم اولیه رو هم بذار روی ۱ (یعنی نرمال، نه زوم شده، نه زوم اوت).

همین یه خط کد، جلوی اون فاجعه‌ی «چپوندن سایت دسکتاپ تو موبایل» رو می‌گیره.

راه حل ۲ (تخصصی): استفاده از واحدهای نسبی (rem یا em) به جای پیکسل (px) برای فونت

خب، حالا که جلوی فاجعه رو گرفتیم، بیایم کار رو «حرفه‌ای» کنیم. گفتیم که پیکسل (px) یه واحد مطلق و لجوجه. به جاش، طراح‌های حرفه‌ای از واحدهای «نسبی» مثل rem یا em استفاده می‌کنن.

rem (Root EM): این واحد، اندازه‌اش رو نسبت به فونت ریشه (یعنی فونت تگ <html>) تعیین می‌کنه.
em: اینم نسبیه، ولی نسبت به فونت عنصر «پدر» خودش. (rem معمولاً سرراست‌تر و قابل کنترل‌تره).

چرا این خوبه؟ چون شما می‌تونی بگی اندازه‌ی فونت پایه‌ی من مثلاً 16px باشه (که می‌شه 1rem). بعد به جای اینکه بگی تیتر H2 باشه 24px، می‌گی باشه 1.5rem (یعنی ۱.۵ برابر اون اندازه‌ی پایه).

اینطوری، اگه بعداً تصمیم بگیری کل فونت‌های سایت رو یکم بزرگ‌تر کنی، فقط کافیه اون فونت «پایه» رو تغییر بدی، و همه‌چیز به همون نسبت، هماهنگ و زیبا بزرگ می‌شه. این یعنی انعطاف‌پذیری واقعی روی همه‌ی دستگاه‌ها.

راه حل ۳ (تجربی): تعریف حداقل اندازه فونت (Min Font Size) در CSS برای خوانایی

این یه نکته‌ی تجربیه که از دل کار درمیاد. حتی اگه از rem هم استفاده کنی، گاهی وقتا لازمه یه «کفِ حداقل» برای خوانایی تعریف کنی. تجربه‌ی شخصی من میگه که برای متن اصلی (Body Text) تو موبایل، معمولاً فونت زیر 14px (یا معادل rem اون) دیگه اذیت‌کننده می‌شه (البته این به نوع فونت هم بستگی داره‌ها!).

می‌تونی تو CSS یه قانون بذاری که مثلاً: «هرچقدر هم صفحه کوچیک شد، اندازه‌ی فونت متن اصلی از 14px یا 15px کمتر نشه.» اینطوری خیالت راحته که کاربرت هیچوقت با متن مورچه‌ای روبرو نمی‌شه.

چگونه با Chrome DevTools کوچک بودن متن را شبیه‌سازی و تست کنیم؟

خب، چطوری قبل از اینکه گوگل مچمونو بگیره، خودمون مچ خودمون رو بگیریم؟ با ابزار قدرتمند Chrome DevTools:

۱. باز کردن DevTools: تو مرورگر کروم، تو صفحه‌ی سایتت راست‌کلیک کن و Inspect رو بزن (یا دکمه F12).

۲. رفتن به حالت موبایل: اون بالا یه آیکون شبیه موبایل و تبلت هست (Toggle device toolbar). روش کلیک کن.

۳. انتخاب دستگاه: حالا می‌تونی از منوی بالا، انواع موبایل‌ها رو انتخاب کنی (مثلاً iPhone 12 Pro یا Galaxy S20).

۴. زوم ممنوع! حالا سعی کن با موس صفحه رو زوم کنی (مثل کاری که کاربر با دو انگشتش می‌کنه). اگه صفحه زوم می‌شه تا متن رو بخونی، یعنی یه جای کار می‌لنگه!

۵. بررسی فونت‌ها: با همون ابزار Inspect (آیکون فلش)، برو روی متن‌های مختلف. تو پنجره‌ی Computed می‌تونی ببینی که اندازه‌ی فونت (font-size) دقیقاً چند پیکسله و چه عواملی دارن روش تأثیر می‌ذارن.

اینطوری می‌تونی دقیقاً ببینی که کاربرت تو گوشی‌های مختلف، سایت تو رو چطوری تجربه می‌کنه.

کالبدشکافی خطای ۲: “Clickable elements too close together” (عناصر قابل کلیک خیلی نزدیک به هم)

این خطا یه پیام واضح داره: «کاربر من داره اشتباهی کلیک می‌کنه!» وقتی کاربر نتونه به راحتی تو سایت شما بچرخه و مدام کلیک‌های اشتباهی بکنه، چه اتفاقی می‌افته؟ عصبانی می‌شه، احساس می‌کنه سایت شما «ناپخته» و «شتاب‌زده» طراحی شده (اینجا همون ضربه به E-E-A-T و اعتماد هست) و در نهایت، عطاش رو به لقاش می‌بخشه و می‌ره.

مشکل “انگشت چاق” (Fat Finger): چرا عناصر باید فاصله داشته باشند؟

توی دنیای طراحی موبایل، ما یه اصطلاح بامزه ولی خیلی جدی داریم به اسم «مشکل انگشت چاق» (Fat Finger Problem). واقعیت اینه که نوک انگشت ما (برخلاف نشانگر موس تو دسکتاپ) دقیق نیست و یه سطحی رو اشغال می‌کنه.

اگه شما دو تا دکمه یا لینک رو مثل دو تا برادر دوقلوی به‌هم‌چسبیده کنار هم بذارید، کاربر بیچاره با انگشتش نمی‌تونه این دو تا رو از هم تشخیص بده. نتیجه این می‌شه که به جای اینکه «پوشش جامع موضوع» شما رو بخونه، اشتباهی روی تبلیغ کنارش کلیک می‌کنه! ما باید برای انگشت کاربر، «فضای تنفس» ایجاد کنیم.

راه حل ۱ (استاندارد گوگل): درک مفهوم “Tap Target Size” (حداقل ۴۸x۴۸ پیکسل)

گوگل برای حل این مشکل یه قانون سرراست گذاشته. میگه: «ببین، من کاری ندارم اون دکمه چقدر خوشگله، ناحیه‌ی قابل کلیکش (Tap Target) باید حداقل ۴۸ در ۴۸ پیکسل باشه.»

چرا ۴۸ پیکسل؟ چون تحقیقات نشون داده این اندازه، تقریباً معادل اندازه‌ی متوسط نوک انگشت یه آدم بالغه.

نکته‌ی مهم: دقت کن! این لزوماً به این معنی نیست که خود آیکون یا متن دکمه باید ۴۸ پیکسل باشه. بلکه اون «فضای نامرئی قابل کلیک» دورش باید اینقدر باشه. اینجاست که راه حل بعدی وارد می‌شه.

راه حل ۲ (عملی): جادوی Padding و Margin در CSS برای ایجاد فاصله تنفسی

این دو تا، بهترین دوستای ما برای حل این مشکل تو CSS هستن:

padding (فاصله‌ی داخلی): این همون جادوییه که «ناحیه‌ی قابل کلیک» (Tap Target) رو بزرگ می‌کنه، بدون اینکه لزوماً خود دکمه رو زشت و گنده کنه. شما به یه دکمه padding می‌دی تا فضای داخلیش بیشتر بشه. اینطوری حتی اگه کاربر دقیقاً روی متن هم کلیک نکنه و بزنه به حاشیه‌ی داخلی دکمه، بازم کلیکش ثبت می‌شه.
margin (فاصله‌ی خارجی): این یکی دیگه کاری به داخل دکمه نداره. وظیفه‌اش اینه که عناصر دیگه رو «هُل بده» اونورتر. وقتی دو تا دکمه کنار هم هستن، با margin بهشون می‌گی: «لطفاً یه کم از هم فاصله بگیرید!»

استفاده‌ی هوشمندانه از این دو تا، هم دکمه‌ها رو بزرگ و قابل دسترس می‌کنه و هم فاصله‌ی امنی بینشون ایجاد می‌کنه.

راه حل ۳ (تجربی): بازطراحی منوها و لینک‌های کنار هم برای موبایل

این راه حل، دیگه فقط فنی نیست، بحث «طراحی» و «تجربه» است. گاهی وقتا، چسبوندن padding و margin جواب نمی‌ده، چون طراحی ما از پایه برای موبایل غلطه.

مثلاً منوی بالای سایت (Navigation) رو در نظر بگیر. تو دسکتاپ، ما ۵-۶ تا لینک رو قشنگ افقی کنار هم می‌ذاریم. اگه بخوایم همون کار رو تو موبایل بکنیم، حتی با فاصله، بازم شلوغ و ریز می‌شه.

راه حل تجربی چیه؟ بازطراحی!

منوی همبرگری (Hamburger Menu): همون آیکون سه خط که دیگه همه‌مون می‌شناسیمش. همه‌ی اون لینک‌های افقی رو می‌بریم تو دل اون. اینطوری صفحه خلوت می‌شه و کاربر هر وقت لازم داشت، بازش می‌کنه.
لینک‌های عمودی: یه مثال دیگه‌، لینک‌های فوتر. تو دسکتاپ افقی کنار همن. تو موبایل، خیلی راحت می‌تونیم اونا رو «عمودی» زیر هم بیاریم. اینطوری هر کدوم یه سطر کامل رو می‌گیرن و امکان نداره کاربر اشتباهی کلیک کنه.

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

کالبدشکافی خطای ۳: “Content wider than screen” (محتوای عریض‌تر از صفحه)

اسکرول افقی روی موبایل یه «نه» بزرگه! کاربر موبایلی فقط باید بتونه عمودی اسکرول کنه. هر وقت اسکرول افقی ایجاد می‌شه، یعنی یه جای کار به شدت می‌لنگه و ما داریم کاربر رو اذیت می‌کنیم.

مقصر اصلی: چگونه یک تصویر، جدول یا المان CSS صفحه را خراب می‌کند؟

معمولاً یه «مقصر» اصلی و لجوج وجود داره. یه المانی که از بقیه حرف‌شنوی نداره و می‌گه «من می‌خوام همین‌قدر بزرگ باشم!»

تصاویر غول‌پیکر: شایع‌ترین مقصر. یه عکسی که شما با عرض ثابت (مثلاً width: 800px) تو متن گذاشتید. این عکس تو دسکتاپ عالیه، ولی وقتی میاد تو یه صفحه موبایل که کلاً ۳۶۰ پیکسل عرض داره، از قاب می‌زنه بیرون و کل صفحه رو خراب می‌کنه.
جداول داده (Tables): دومین مقصر بزرگ. جدول‌ها ذاتاً عریض هستن. وقتی یه جدول با ۱۰ تا ستون رو می‌خوای تو موبایل نشون بدی، طبیعتاً از صفحه می‌زنه بیرون.
المان‌های CSS عجیب: گاهی هم یه <div> یا یه المانی داریم که به خاطر یه کد CSS اشتباه (مثلاً یه padding یا margin خیلی زیاد، یا یه width ثابت) باعث این مشکل می‌شه.

راه حل ۱ (برای تصاویر): استفاده از max-width: 100% در CSS

این کد، کدِ طلایی و حیاتی برای تصاویر ریسپانسیو (واکنش‌گرا) هست. این یه قانون ساده و زیبا تو CSS هست که باید برای همه‌ی تصاویر سایتت اعمال بشه:

CSS

img {
  max-width: 100%;
  height: auto;
}

ترجمه‌ی این کد برای مرورگر:

max-width: 100%: «ای عکس! تو اجازه داری حداکثر تا ۱۰۰٪ عرضِ «ظرف» یا ستونی که داخلش هستی، بزرگ بشی، ولی نه بیشتر! اگه ظرف کوچیک شد (مثل موبایل)، تو هم خودتو جمع می‌کنی و کوچیک می‌شی تا جا بشی.»
height: auto: «ارتفاعت هم خودکار متناسب با عرض جدیدت تنظیم می‌شه تا کش نیای و دفرمه نشی.»

همین دو خط کد، مشکل ۹۰٪ تصاویر غول‌پیکر رو حل می‌کنه.

راه حل ۲ (برای جداول): طراحی ریسپانسیو جداول (ایجاد اسکرول افقی فقط برای جدول)

خب، با جدول‌های عریض چی کار کنیم؟ نمی‌تونیم اطلاعات رو حذف کنیم. راه حل هوشمندانه اینه که فقط خود جدول اسکرول بخوره، نه کل صفحه.

چطوری؟ ما میایم جدول (<table>) رو می‌ذاریم تو یه <div> نگهدارنده، و به اون div این استایل رو می‌دیم:

CSS

.table-container {
  overflow-x: auto;
  width: 100%;
}

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

راه حل ۳ (پیشرفته): استفاده از Flexbox و Grid برای چیدمان‌های انعطاف‌پذیر

این دیگه مال طراحی مدرن وبه. به جای اینکه مثل قدیما با float و درصدهای ثابت چیدمان کنیم (که خیلی وقتا شکننده بود)، از سیستم‌های هوشمند چیدمان CSS مثل Flexbox و Grid استفاده می‌کنیم.

چرا اینا خوبن؟ چون ذاتاً «انعطاف‌پذیر» (Flexible) طراحی شدن.
مثلاً Flexbox: شما بهش می‌گی «این سه تا باکس رو کنار هم بذار، ولی اگه جا نبود (wrap)، خودت هوشمندانه بندازشون زیر هم.»
مثلاً Grid: شما می‌تونی یه شبکه‌ی پیچیده طراحی کنی و بگی تو موبایل ستون‌ها چطور زیر هم بیان.

این سیستم‌ها خودشون حواسشون به عرض صفحه هست و چیدمان رو جوری تنظیم می‌کنن که هیچ‌وقت چیزی از صفحه بیرون نزنه. این یعنی «تولید خوب» و با «توجه و مراقبت» که به کاربر حس «اعتماد» می‌ده.

کالبدشکافی خطای ۴: “Viewport not set” (ویوپورت تنظیم نشده است)

این خطا یعنی شما اون «فرمان» اصلی و حیاتی رو به مرورگر ندادی. این اولین و مهم‌ترین قدم برای اینه که سایت شما اصلاً «بفهمه» که داره روی یه صفحه‌ی کوچیک نمایش داده می‌شه. بدون این فرمان، تمام زحمت‌هایی که برای ریسپانسیو کردن کشیدی، تقریباً بی‌فایده‌ست و کاربر با همون تجربه‌ی فاجعه‌بار «زوم کردن با دو انگشت» (Pinch-to-Zoom) روبرو می‌شه.

معنی Viewport: دستوری که به مرورگر می‌گوید “این سایت برای موبایل است”

Viewport (ویوپورت) همون «پنجره‌ی دید» یا «قاب»ی هست که مرورگر از طریقش سایت شما رو نشون می‌ده.

وقتی شما «تگ متا ویوپورت» رو تنظیم می‌کنی، در واقع داری یه دستورالعمل خیلی واضح به مرورگر می‌دی. داری بهش می‌گی:

«سلام آقای مرورگر! می‌دونم تو دسکتاپ عادت داری خودت رو ۹۸۰ پیکسل پهن کنی. ولی الان تو یه گوشی موبایل هستی! لطفاً اون عادت رو بذار کنار و عرض خودت رو دقیقاً برابر با عرض فیزیکی این دستگاهی که دست کاربره تنظیم کن.»

این تگ، کلیدِ استارت دنیای ریسپانسیوه.

راه حل قطعی: ارائه کد استاندارد و کامل تگ Meta Viewport برای کپی کردن

این همون «کد جادویی» هست که باید تو تمام صفحات سایتت، داخل تگ <head> قرارش بدی. این کد استاندارد و کاملیه که ۹۹.۹٪ کار رو برات انجام می‌ده:

HTML

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

اینو کپی کن و مطمئن شو که تو <head> سایتت وجود داره. همین!

اشتباه رایج: تفاوت width=device-width و initial-scale=1.0

خیلی‌ها این کد رو کپی می‌کنن، ولی دقیقاً نمی‌دونن این دو تا بخش دارن چی کار می‌کنن. بذار برات بازش کنم:

width=device-width (تنظیم عرض)
این قسمت، همون دستوریه که تو بخش قبلی گفتم. به مرورگر می‌گه: «عرض پنجره‌ی دیدت (viewport) رو مساوی با عرض واقعی دستگاه (device-width) قرار بده.» این کار باعث می‌شه مرورگر دیگه سایت رو کوچیک نکنه (Zoom Out) تا همه‌چیز رو جا بده.
initial-scale=1.0 (تنظیم زوم اولیه)
این قسمت، مکمل اون دستور اوله و کارش کنترل «میزان زوم» اولیه‌ست. scale=1.0 یعنی «وقتی صفحه باز شد، با زوم ۱۰۰٪ نشونش بده. نه بیشتر، نه کمتر.» این تضمین می‌کنه که صفحه دقیقاً اندازه‌ی خودش نمایش داده می‌شه و کاربر نیازی به زوم کردن یا زوم‌بک نداره.

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

جعبه ابزار شما: از شناسایی تا تایید رفع خطا

این یه چرخه‌ی ساده‌ست: پیدا کن، تست کن، تایید بگیر. بیا با هم قدم به قدم بریم جلو.

گام اول: شناسایی دقیق صفحات دارای خطا در گزارش Mobile Usability

وقتی تو سرچ کنسول وارد گزارش «Mobile Usability» می‌شی و یه نمودار قرمز می‌بینی، لطفاً هول نشو! اولین کار این نیست که کل سایت رو زیر و رو کنی.

اول روی اون نوع خطا کلیک کن (مثلاً “Text too small to read”). سرچ کنسول بهت یه لیست خوشگل از URLهایی می‌ده که دقیقاً همین مشکل رو دارن.

اینجا کارآگاه‌بازی شروع می‌شه. به این URLها نگاه کن.

آیا همشون از یه «قالب» خاص استفاده می‌کنن؟ (مثلاً همه‌ی مقالات وبلاگت؟)
آیا همشون مربوط به یه «بخش» خاص سایتن؟ (مثلاً صفحات دسته‌بندی محصول؟)

این به تو سرنخ می‌ده که مشکل از کجاست. شاید فقط با تغییر CSS یه قالب خاص، بتونی صدها صفحه رو هم‌زمان درست کنی. این یعنی «توجه و مراقبت» به جزئیات، نه یه کار «سهل انگارانه».

گام دوم: تست زنده URL با ابزار Google Mobile-Friendly Test

خب، فکر می‌کنی مشکل رو حل کردی. (یا برنامه‌نویس‌ت قسم می‌خوره که حل کرده! 😉)

حالا چطوری مطمئن بشیم؟ منتظر گوگل نمی‌مونیم.

همین الان می‌ریم سراغ ابزار Google Mobile-Friendly Test (که البته از طریق نوار URL Inspection تو خود سرچ کنسول هم در دسترسه).

یکی از اون URLهای مشکل‌دار رو بردار و تستش کن. مهم: حتماً گزینه‌ی “Test Live URL” (تست URL زنده) رو بزن. این به گوگل میگه «کاری به اطلاعات قبلی‌ت نداشته باش، همین الان برو این صفحه رو ببین.»

دیدن اون پیغام سبز «Page is mobile-friendly» یکی از بهترین حس‌های دنیاست! اگه سبز شد، یعنی برای گام بعدی آماده‌ای. اگه قرمز بود، یعنی هنوز یه جای کار می‌لنگه و باید برگردی عقب.

گام نهایی: چگونه از دکمه “Validate Fix” در سرچ کنسول به درستی استفاده کنیم؟

تبریک! از تست زنده سربلند بیرون اومدی.

حالا، و فقط حالا، وقتشه برگردی به همون گزارش Mobile Usability. روی اون نوع خطایی که حل کردی (مثلاً “Text too small”) کلیک کن. اون بالا یه دکمه‌ی جادویی می‌بینی: “Validate Fix” (اعتبارسنجی رفع مشکل).

این دکمه چی کار می‌کنه؟

وقتی روش کلیک می‌کنی، داری رسماً به گوگل می‌گی: «هی گوگل! اون صفحاتی که قبلاً ایراد داشتی رو یادته؟ من همه‌شون رو درست کردم. لطفاً دوباره ربات‌هات رو بفرست تا بررسی کنن.»

نکته‌ی حیاتی: تا وقتی از تست زنده (گام دوم) جواب سبز نگرفتی، این دکمه رو نزن! زدنش وقتی هنوز مشکل وجود داره، فقط اعتبار شما و زمان ربات‌های گوگل رو هدر می‌ده.

تجربه ما: چقدر طول می‌کشد تا اعتبارسنجی گوگل کامل شود؟

اینجا می‌رسیم به بخش «تجربی» ماجرا. وقتی دکمه‌ی «Validate Fix» رو می‌زنی، یه پروسه شروع می‌شه که روش نوشته “Validation started”.

این یعنی گوگل درخواست شما رو گذاشته تو «نوبت».

بر اساس تجربه‌ی من، این فرآیند اصلاً آنی نیست. گوگل باید دوباره همه‌ی اون URLهایی که خطا داشتن رو خزش (Crawl) کنه.

اگه تعداد صفحات کم باشه (مثلاً ۱۰-۲۰ تا)، ممکنه ظرف چند روز تموم بشه.
اگه یه فاجعه‌ی بزرگ داشتی و هزاران صفحه خطا داشتن، ممکنه یک هفته یا حتی بیشتر هم طول بکشه.

صبور باش. گوگل بهت ایمیل می‌زنه و خبر می‌ده که اعتبارسنجی «موفق» بوده یا (خدای نکرده) «ناموفق». این همون چرخه‌ی «تولید خوب» محتوا و سایته که به کاربر (و گوگل) نشون می‌ده تو برای «تجربه رضایت‌بخش» اون‌ها ارزش قائلی.

جمع‌بندی

دیدی؟ به همین راحتی! کالبدشکافی‌مون تموم شد. همه‌ی این خطاها یه ریشه‌ی مشترک داشتن: ما داشتیم کاربرمون رو اذیت می‌کردیم.

یادت باشه، اون گزارش Mobile Usability تو سرچ کنسول، یه چک‌لیست فنی خشک‌وخالی نیست؛ اون «صدای» کاربرای موبایلی ماست. رفع کردن این خطاها، فقط برای گرفتن تیک سبز از گوگل یا «تازه نشان دادن سایت» نیست. این یه سرمایه‌گذاری مستقیم روی «اعتماد» و «اعتبار» سایتمونه.

وقتی به کاربر نشون می‌دی که برای تجربه‌اش ارزش قائلی، اونم با اعتمادش به تو پاداش می‌ده.

حالا تو بهم بگو، بعد از خوندن این متن، اولین خطای موبایلی که می‌خوای بری سراغش و درستش کنی چیه؟

اخبار و مقالات

راهنمای عملی و قطعی: رفع خطاهای Mobile Usability (از “Text too small” تا “Clickable elements”)