طراحی فوتر سایت یعنی ساختن یک مسیر قابل اتکا برای کاربری که به انتهای صفحه رسیده یا عمداً برای یافتن اطلاعات تماس، پشتیبانی، سیاستها و مسیرهای ثانویه به پایین صفحه آمده است. فوتر نه انبار همه لینکهای سایت است، نه ترفند توزیع اعتبار سئو و نه آخرین فرصت برای فشار آوردن به کاربر.
فوتر حرفهای سه کار را همزمان انجام میدهد: مسیر بعدی را روشن میکند، هویت و اطلاعات قابل راستیآزمایی کسبوکار را در دسترس میگذارد و در همه دستگاهها و روشهای ورودی قابل استفاده میماند. برای یک فروشگاه ایرانی، این یعنی کاربر بتواند راه پشتیبانی، شرایط ارسال و مرجوعی، هویت فروشنده و وضعیت نماد را پیدا کند؛ اما اطلاعات ضروری خرید فقط به فوتر موکول نشود.
پاسخ کوتاه: یک فوتر خوب کمحجم، گروهبندیشده، معنایی و مبتنی بر نیاز کاربر است. لینکهای سراسری را با داده و مالک مشخص انتخاب کنید، از لینکاسپم و Badge نمایشی دوری کنید، نسخه موبایل و WCAG ۲.۲ را تست کنید و سلامت لینک و اطلاعات تماس را در برنامه نگهداری قرار دهید.
فوتر سایت چیست و چه چیزی فوتر نیست؟
فوتر سایت ناحیهای در انتهای Layout عمومی است که اطلاعات مشترک و مسیرهای ثانویه را ارائه میکند. اما چند جزء مشابه را باید از هم تفکیک کرد:
| جزء | نقش | نمونه محتوا |
|---|---|---|
| Global footer | اطلاعات مشترک کل سایت | تماس، پشتیبانی، سیاستها، شبکههای اجتماعی |
| Footer navigation | مسیرهای ثانویه و ثابت | درباره ما، راهنما، دستههای اصلی |
| Legal strip | هویت و پیوندهای حقوقی/سیاستی | نام مالک، کپیرایت، حریم خصوصی |
| Section/Article footer | اطلاعات مربوط به همان بخش | نویسنده، تاریخ، Tag، Citation |
| HTML sitemap | صفحه مستقل برای مرور ساختار | فهرست منظم بخشها و صفحات |
| Sticky bottom bar | کنترل همیشهنمایان | خرید، تماس یا Navigation اپمانند |
Footer با «نوار چسبان پایین» یکی نیست. نوار چسبان ممکن است در صفحه کوچک محتوا و Focus را بپوشاند؛ فوتر معمولی بخشی از جریان سند است و کاربر به آن میرسد. همچنین فوتر جایگزین HTML sitemap، صفحه تماس یا راهنمای خدمات نیست.
کاربر چرا به فوتر میرسد؟
رسیدن به انتهای صفحه فقط نشانه علاقه نیست. کاربر ممکن است مطلب را تمام کرده، نتیجه را پیدا نکرده، برای تماس عمداً به پایین پریده یا صفحه کوتاه بوده باشد. بنابراین «Footer view» را نباید بدون شواهد، Lead باکیفیت یا نارضایتی تفسیر کرد.
پنج کار رایج در فوتر
- بازیابی مسیر: کاربر راه بعدی را در Navigation اصلی پیدا نکرده است.
- راستیآزمایی: دنبال نام کسبوکار، آدرس، شماره، سیاست یا نماد میگردد.
- پشتیبانی: راه تماس، FAQ، پیگیری سفارش یا گزارش مشکل میخواهد.
- ادامه رابطه: خبرنامه یا کانال اجتماعی رسمی را انتخاب میکند.
- ادامه سفر: به دسته، خدمت یا محتوای مرتبط بعدی میرود.
اگر مدل ذهنی و Journey کاربر هنوز روشن نیست، ابتدا فرایند طراحی تجربه کاربری را اجرا کنید. فوتر نمیتواند معماری اطلاعات نامفهوم را با ستونهای بیشتر درمان کند.
محتوای فوتر را بر اساس نوع سایت انتخاب کنید
فهرست واحدی برای همه کسبوکارها وجود ندارد. یک رسانه، فروشگاه، شرکت B2B و SaaS وظایف و ریسکهای متفاوتی دارند.
| نوع سایت | اولویتهای فوتر | موارد مشروط |
|---|---|---|
| شرکتی/B2B | خدمات اصلی، تماس، درباره، فرصت شغلی، دفترها | درخواست دمو، مطالعه موردی، وضعیت سرویس |
| فروشگاهی | پشتیبانی، ارسال، مرجوعی، پیگیری، هویت فروشنده | نماد قابل راستیآزمایی، اپ، باشگاه مشتریان |
| SaaS | مستندات، Status، امنیت، پشتیبانی، شرایط خدمت | Developer portal، API، Partner |
| رسانه/وبلاگ | درباره تحریریه، نویسندگان، سیاست اصلاح، موضوعات | خبرنامه، RSS، ارسال پیشنهاد |
| محلی | نام/نشانی/تلفن معتبر، ساعت پاسخگویی، شعب | نقشه بهصورت لینک، رزرو یا مسیریابی |
| نهاد عمومی | دسترسیپذیری، تماس، شفافیت، خدمات پرتکرار | زبانها، داده باز، گزارشها |
هر عنصر باید یک دلیل و مالک داشته باشد. اگر تیم نمیداند چه کسی شماره تماس، لینک مرجوعی یا وضعیت نماد را بهروز میکند، فوتر بهمرور اعتماد را کاهش میدهد.
معماری اطلاعات فوتر؛ از Inventory تا اولویت
کار را با Drag-and-drop در Figma شروع نکنید. ابتدا Content inventory بسازید: عنوان، URL، گروه، هدف کاربر، اهمیت کسبوکار، تکرار در Header، کلیک/Task، مالک و تاریخ بازبینی.
قاعده انتخاب لینک سراسری
لینکی را در همه صفحات تکرار کنید که دستکم یکی از این شرایط را دارد:
- برای اعتماد، پشتیبانی یا الزامات کسبوکار در بسیاری از Journeyها لازم است.
- مسیر ثانویه پرتکرار است و Header نباید با آن شلوغ شود.
- محتوای مقصد پایدار، معتبر و دارای مالک مشخص است.
- نبودن آن، کاربر را به بنبست قابل مشاهده میرساند.
لینک یک کمپین موقت، مقاله تصادفی یا همه شهرهای هدف معمولاً نباید سراسری شود. لینک Contextual در خود محتوا، Category navigation و پیشنهاد بعدی غالباً جای مناسبتری دارند.
روشهای کشف نیاز
- Search log داخلی: کاربر چه عبارتهایی را پیدا نمیکند؟
- تیکت پشتیبانی: کدام اطلاعات بارها پرسیده میشود؟
- تست Tree یا Card sorting: گروهبندی تیم با مدل ذهنی کاربر همخوان است؟
- تحلیل مسیر: کدام Task پس از دیدن فوتر تکمیل میشود؟
- مصاحبه و تست: نام ستونها و Anchorها قابل پیشبینیاند؟
برای طراحی مطالعه و تبدیل مشاهده به Severity، از راهنمای تست کاربردپذیری کمک بگیرید.
الگوی پیشنهادی گروهبندی لینکها
برای بسیاری از سایتها، سه تا پنج گروه معنایی کافی است؛ تعداد ستون هدف نیست. گروهها میتوانند «محصول/خدمات»، «راهنما و پشتیبانی»، «شرکت» و «قوانین و دسترسپذیری» باشند. عنوان «لینکهای مفید» معمولاً اطلاعات کمی میدهد؛ عنوان دقیقتر، پیشبینی مقصد را آسان میکند.
| گروه | نمونه Anchor خوب | نمونه ضعیف |
|---|---|---|
| پشتیبانی | پیگیری سفارش، روشهای ارسال، شرایط مرجوعی | اطلاعات بیشتر، کلیک کنید |
| شرکت | درباره مایندیو، تماس با تیم، فرصتهای همکاری | ما، ارتباط |
| قوانین | حریم خصوصی، شرایط استفاده، سیاست کوکی | قوانین ۱، قوانین ۲ |
| محصول | عنوان واقعی دسته یا خدمت | بهترین خرید ارزان تهران |
Anchor باید کوتاه، توصیفی و طبیعی باشد. عنوان مقصد را فقط وقتی تغییر دهید که Label روشنتری برای کاربر دارید؛ نه برای افزودن چند کلمه کلیدی.
فوتر و سئو؛ نقش واقعی لینکهای سراسری
لینک فوتر میتواند به کشف URL و فهم رابطه صفحات کمک کند، اما جای لینک زمینهمند در متن، Navigation اصلی و معماری درست را نمیگیرد. گوگل در راهنمای رسمی لینکها میگوید لینک قابل Crawl معمولاً عنصر <a> با href است و Anchor توصیفی به کاربر و موتور جستوجو Context میدهد.
اصلاح یک باور قدیمی: سقف ۱۰۰ لینک وجود ندارد
نسخههای قدیمی راهنماها عدد «کمتر از ۱۰۰ لینک در صفحه» را تکرار میکردند. راهنمای فعلی گوگل صریح است: تعداد ایدهآل جادویی وجود ندارد؛ اگر تعداد برای انسان بیشازحد بهنظر میرسد، احتمالاً باید کم شود. تصمیم را با هدف، تمایز بصری، حجم DOM و قابلیت پیمایش بگیرید، نه یک سقف ساختگی.
فوتر، HTML sitemap نیست
قرار دادن تمام محصولات، شهرها یا مقالهها در فوتر، مسیر را بهتر نمیکند. برای ساختار بزرگ از Category، Facet کنترلشده، Search و صفحه HTML sitemap استفاده کنید. XML sitemap نیز برای موتور جستوجو نقش جداگانه دارد و جایگزین لینک داخلی قابل Crawl نیست.
لینکاسپم در Templateهای توزیعشده
سیاست Spam گوگل لینکهای گسترده در Footer یا Template سایتهای مختلف را از نمونههای Link spam میشمارد، وقتی هدف اصلی دستکاری رتبه باشد. این موضوع با Navigation داخلی مفید در یک سایت یکسان نیست.
- اعتبار طراحی یا پلتفرم را با رضایت مالک و Anchor برند درج کنید، نه عبارت Keyword-rich.
- لینک تبلیغاتی/اسپانسری را با
rel="sponsored"یا در صورت مناسبnofollowمشخص کنید. - لینکهای Widget توزیعشده را به کسب اعتبار اجباری تبدیل نکنید.
- شهرها و خدمات را صرفاً برای ساخت بلوک Keyword در فوتر تکرار نکنید.
HTML معنایی و Landmark فوتر
عنصر <footer> فقط یک نام CSS نیست. طبق استاندارد HTML، فوتر اطلاعات مربوط به نزدیکترین Sectioning content یا ریشه را نمایش میدهد. فوتر مستقیم صفحه با فوتر داخل article معنای یکسان ندارد.
راهنمای W3C برای Contentinfo توضیح میدهد که <footer> در Context عنصر body یک Landmark از نوع contentinfo میسازد؛ Footer داخل article، main، nav یا section چنین نقشی ندارد. معمولاً یک Contentinfo سطح بالا کافی است.
نمونه ساختار ساده
<footer>
<nav aria-labelledby="footer-support">
<h2 id="footer-support">راهنما و پشتیبانی</h2>
<ul>
<li><a href="/shipping/">روشهای ارسال</a></li>
<li><a href="/returns/">شرایط مرجوعی</a></li>
</ul>
</nav>
<address><a href="tel:+982100000000">۰۲۱–۰۰۰۰۰۰۰۰</a></address>
</footer>اگر چند nav دارید، هرکدام نام قابل تشخیص داشته باشد. Heading میتواند از نظر بصری ساده یا با روش درست visually hidden شود، اما ساختار را فقط با div و متن Bold شبیهسازی نکنید. ARIA را برای جبران HTML نادرست اضافه نکنید.
دسترسپذیری فوتر با WCAG ۲.۲
فوتر معمولاً تعداد زیادی لینک کوچک و کمکنتراست دارد؛ بنابراین به نقطه خطای پرتکرار تبدیل میشود. WCAG 2.2 معیارهایی درباره Contrast، Reflow، Focus، Link purpose، Consistent navigation و Target size دارد که مستقیماً به فوتر مربوطاند.
چکلیست دسترسپذیری
- متن معمولی نسبت کنتراست حداقل ۴٫۵:۱ و متن بزرگ حداقل ۳:۱ داشته باشد.
- Focus کاملاً قابل مشاهده باشد و Sticky bar یا Cookie banner آن را نپوشاند.
- ترتیب Tab با ترتیب بصری و معنایی سازگار بماند.
- هدفهای مستقل سطح AA حداقل ۲۴×۲۴ پیکسل CSS یا فاصله/استثنای معتبر داشته باشند.
- Link فقط با رنگ از متن عادی متمایز نشود و Purpose آن از متن یا Context روشن باشد.
- آیکون شبکه اجتماعی Accessible name دقیق مانند «لینکدین مایندیو» داشته باشد.
- لوگوی تکراری با مقصد خانه Alt مناسب داشته باشد؛ تصویر تزئینی Alt خالی بگیرد.
- فرم خبرنامه Label، راهنمای خطا، وضعیت موفقیت و Focus management درست داشته باشد.
- در Zoom و افزایش فاصله متن، لینک یا ستون حذف و بریده نشود.
هدف ۴۴×۴۴ پیکسل CSS معیار Enhanced سطح AAA است؛ آن را با الزام AA اشتباه نگیرید. برای طراحی و آزمون کاملتر، راهنمای طراحی فراگیر و WCAG ۲.۲ را ببینید.
طراحی Responsive و فوتر موبایل
ستونهای Desktop نباید فقط باریک شوند. در عرض کوچک، ترتیب گروهها را بر اساس کارهای پرتکرار تغییر دهید، اما ترتیب DOM و Focus را بیدلیل از ظاهر جدا نکنید. در عرض معادل ۳۲۰ پیکسل CSS، محتوای معمول باید بدون از دست رفتن اطلاعات یا Scroll دوبعدی Reflow شود.
Accordion فوتر در موبایل
Accordion میتواند طول بصری را کم کند، اما الزامی نیست. اگر استفاده میکنید:
- Trigger یک
buttonواقعی با نام روشن باشد. aria-expandedو ارتباط با Panel بهروز شود.- عنوان گروه با لمس و Keyboard کار کند.
- لینکهای ضروری بدون JavaScript شکستخورده قابل دسترسی بمانند.
- Search engine و DOM رندرشده محتوا را دریافت کنند.
- باز/بسته شدن Layout shift آزاردهنده یا پرش Focus نسازد.
راهنمای کامل Touch، RTL، تست دستگاه و Reflow در مقاله موبایل فرندلی و سئو موبایل آمده است.
تایپوگرافی، رنگ و سلسلهمراتب بصری
فوتر نباید بهدلیل «ثانویه بودن» ناخوانا شود. اندازه Font را بر اساس Typeface فارسی، فاصله خط، دستگاه و آزمون خوانایی تعیین کنید؛ نسخه واحد «همیشه دو پیکسل کوچکتر» نداریم.
- عنوان گروه، Link و متن توضیحی سه سطح قابل تشخیص داشته باشند.
- عرض محتوا با Grid اصلی صفحه همراستا و فضای سفید منظم باشد.
- Link hover، focus و visited فقط به تغییر بسیار ظریف رنگ وابسته نباشد.
- پسزمینه تیره مجوز خاکستری کمکنتراست نیست.
- Divider باید ساختار را تقویت کند، نه شلوغی را بیشتر.
- Badge و آیکون اندازه بصری هماهنگ داشته باشند، اما نام برند مخدوش نشود.
RTL فارسی، شماره تلفن و متن دوجهته
ترکیب فارسی، شماره، ایمیل و URL میتواند ترتیب بصری را بههم بزند. جهت صفحه را rtl نگه دارید و برای رشته ذاتاً چپبهراست از dir="ltr" روی همان قطعه استفاده کنید.
- شماره نمایشی میتواند فارسی باشد، اما
href="tel:+98..."باید قابل شمارهگیری و استاندارد باشد. - ایمیل را بهشکل بصری خوانا و بدون شکستن بیقاعده نمایش دهید.
- نام شبکه اجتماعی یا Language switcher را با زبان واقعی Label کنید.
- آدرس طولانی و کدپستی را روی گوشی واقعی و افزایش Font تست کنید.
- ترتیب ستونهای RTL را با اهمیت کاربر تنظیم کنید، نه فقط Mirror خودکار طرح LTR.
اعتماد: اطلاعات قابل راستیآزمایی، نه تزئین
فوتر میتواند شواهد اعتماد را قابل یافتن کند، اما یک ادعا را معتبر نمیکند. نام حقوقی یا تجاری، راه تماس فعال، سیاستهای بهروز و مسیر شکایت/پشتیبانی از چند Badge عمومی ارزشمندترند.
نماد و گواهی
- نماد باید از منبع معتبر، قابل کلیک و متصل به صفحه راستیآزمایی همان کسبوکار باشد.
- Screenshot ثابت نماد، مدرک اعتبار جاری نیست.
- لوگوی «SSL Secure» جای HTTPS صحیح، تمدید گواهی و امنیت واقعی را نمیگیرد.
- جایزه، عضویت یا Partner badge منقضی را حذف کنید.
- ادعای «۱۰۰٪ امن» یا «تضمین کامل» نسازید؛ دامنه و محدودیت ادعا را بنویسید.
برای تبدیل ادعا به Evidence، Owner و Review cadence، راهنمای E‑E‑A‑T و شواهد اعتماد مفید است.
فوتر فروشگاه ایرانی و اطلاعات پیش از خرید
این بخش راهنمای حقوقی اختصاصی نیست و نوع فعالیت ممکن است الزامهای دیگری داشته باشد. بااینحال، مواد ۳۳ تا ۳۵ قانون تجارت الکترونیکی ایران بر ارائه بهموقع، روشن و صریح اطلاعاتی مانند هویت تأمینکننده، راه تماس، هزینه، شرایط معامله، پشتیبانی و فسخ تأکید دارند؛ متن قانون در WIPO Lex قابل مشاهده است.
نکته طراحی: لینک سیاستها در فوتر Discoverability را بهتر میکند، اما اگر اطلاعات مؤثر تصمیم خرید باید پیش از قرارداد دیده شود، پنهان کردن آن فقط در فوتر کافی نیست. هزینه ارسال، زمان تحویل، موجودی، ضمانت و شرایط مرجوعی را در Product/Cart/Checkout و تأیید سفارش نیز در Context درست ارائه کنید.
| اطلاعات | فوتر | محل Contextual ضروری |
|---|---|---|
| هویت و تماس | خلاصه و لینک صفحه تماس | پشتیبانی و تأیید سفارش |
| ارسال و مرجوعی | لینک سیاست کامل | محصول، سبد و Checkout |
| هزینه کل | معمولاً نه | پیش از تأیید پرداخت |
| ضمانت/خدمات | لینک راهنما | محصول و تأیید سفارش |
| حریم خصوصی | لینک نسخه جاری | نقطه جمعآوری داده و Consent لازم |
برای جزئیات ریزش، فرم آدرس و پرداخت، راهنمای بهینهسازی Checkout فروشگاه را ببینید.
کپیرایت و صفحات سیاستی را دقیق بنویسید
اعلان «تمام حقوق محفوظ است» میتواند مالک ادعایی و سال انتشار را روشن کند، اما بهتنهایی از کپی جلوگیری نمیکند و جای فرایند ثبت شواهد، مجوز محتوا و پیگیری حقوقی را نمیگیرد. نام صاحب حق را با هویت واقعی کسبوکار هماهنگ کنید.
- سال میتواند Server-side بهروز شود؛ خرابی JavaScript نباید متن را حذف کند.
- برای محتوای دارای مجوز متفاوت، Link مجوز را روشن نمایش دهید.
- Privacy، Terms، Cookie، Accessibility statement و سیاست اصلاحات نسخه و تاریخ بازبینی داشته باشند.
- صفحه خالی یا Template عمومی اعتماد نمیسازد؛ متن باید با پردازش واقعی داده و خدمت منطبق باشد.
- مالک محتوایی و بازبین حقوقی هر سیاست مشخص باشد.
فرم خبرنامه در فوتر؛ فقط با ارزش روشن
رسیدن به فوتر رضایت برای پیام بازاریابی نیست. اگر خبرنامه واقعاً محصول محتوا دارد، ارزش، تناوب و نوع پیام را کوتاه توضیح دهید. یک فیلد ایمیل بیتوضیح و دکمه «عضویت» انتظار شفافی نمیسازد.
حداقلهای فرم سالم
- Label واقعی «ایمیل» و CTA مشخص مانند «دریافت خبرنامه ماهانه»
- اطلاع کوتاه از کاربرد داده و لینک سیاست حریم خصوصی
- Consent جدا برای هدفهای جدا؛ Checkbox از پیش انتخابشده نباشد
- اعتبارسنجی قابل فهم و حفظ مقدار پس از خطا
- پیام موفقیت قابل تشخیص برای Screen reader
- مسیر لغو عضویت ساده و قابل اجرا
- Rate limit و محافظت ضدسوءاستفاده بدون CAPTCHA مسدودکننده غیرضروری
الگوهای اجبار، پیشانتخاب و دشوار کردن خروج را با چکلیست طراحی اخلاقی و دارکپترن ارزیابی کنید.
CTA در فوتر؛ یک پیشنهاد، نه چند فریاد
Footer CTA باید با Journey صفحه سازگار باشد. در صفحه مقاله ممکن است «مشاهده خدمات مرتبط» منطقی باشد؛ در صفحه پشتیبانی، «ارسال تیکت» و در Checkout، افزودن CTA بازاریابی میتواند حواسپرتی باشد.
- یک CTA اصلی و حداکثر یک مسیر ثانویه روشن نگه دارید.
- متن نتیجه را بگوید: «دریافت برآورد پروژه»، نه فقط «شروع کنید».
- CTA را از لینکهای Navigation و Social متمایز کنید.
- برای تماس، ساعت پاسخگویی یا زمان تقریبی پاسخ واقعی بنویسید.
- موفقیت را با Task completion و Lead واجدشرایط بسنجید، نه فقط Click.
شبکه اجتماعی و لینکهای خارجی
فقط کانالهایی را نمایش دهید که رسمی و فعالاند. Icon خالی از متن برای همه قابل فهم نیست. Accessible name باید نام شبکه و برند را بیان کند؛ مثلاً «صفحه لینکدین مایندیو».
- لینک را به Profile رسمی بدهید، نه صفحه اصلی شبکه.
- باز کردن در Tab جدید را پیشفرض نکنید؛ اگر ضروری است، به کاربر اطلاع دهید.
- در صورت استفاده از
target="_blank"رفتار امنیتی مرورگر وrel="noopener"را بررسی کنید. - Widget زنده Social را فقط با ارزش روشن بارگذاری کنید؛ Script شخص ثالث هزینه و حریم خصوصی دارد.
- کانال تعطیل و شناسه تغییرکرده را در Audit دورهای پیدا کنید.
عملکرد فوتر و Core Web Vitals
فوتر خارج از Viewport اولیه است، اما رایگان نیست. HTML، CSS، Font، Badge script، Map embed و Social widget همچنان دانلود و اجرا میشوند. Component دیررس نیز میتواند هنگام رسیدن کاربر Layout shift بسازد.
- نقشه را به Link تبدیل کنید؛ Embed فقط هنگام نیاز کاربر بارگذاری شود.
- برای Logo و Badge ابعاد رزرو کنید.
- فونت و Icon font جدا فقط برای فوتر نفرستید؛ SVG امن و بهینه را بررسی کنید.
- Script نماد، چت و Newsletter را Inventory و Budget کنید.
- DOM تکراری Desktop/Mobile را با CSS مخفی نکنید مگر ضرورت قابل دفاع باشد.
- فوتر را Server-render کنید تا Linkهای حیاتی به Hydration وابسته نباشند.
Sticky footer، Bottom bar و Safe area
برای رساندن فوتر به پایین Viewport در صفحه کوتاه، Layout طبیعی Flex/Grid مناسب است؛ position: fixed راهحل عمومی نیست. Fixed footer در موبایل میتواند محتوا، Keyboard و Focus را بپوشاند.
اگر Bottom bar اپمانند لازم دارید، ارتفاع، env(safe-area-inset-bottom)، Zoom، صفحهکلید، Orientation، Cookie banner و دکمه سیستم را تست کنید. کاربر باید بتواند محتوای پشت آن را ببیند و Focus هیچ کنترل مهمی کاملاً پنهان نشود.
اندازهگیری فوتر بدون Vanity metric
CTR فوتر بهتنهایی کیفیت را نشان نمیدهد؛ Footer کوتاه یک Landing page و Footer انتهای مقاله بلند Exposure متفاوتی دارند. Tracking plan باید Impression قابل مشاهده و Click را از هم جدا کند.
| رویداد/شاخص | پرسش | هشدار تفسیر |
|---|---|---|
| footer_view | فوتر واقعاً وارد Viewport شد؟ | رسیدن لزوماً علاقه نیست |
| footer_link_click | کدام Group/Link/Template کلیک شد؟ | Click بالا ممکن است ضعف Header باشد |
| support_task_success | کاربر پاسخ یا پیگیری را کامل کرد؟ | نیازمند اتصال رویدادهای بعدی است |
| newsletter_confirmed | عضویت معتبر و تأییدشده چند است؟ | Submit خام با Lead برابر نیست |
| broken_link_rate | چند مقصد خطا یا Redirect chain دارد؟ | مانیتور خودکار لازم است |
| contact_quality | تماس مرتبط و قابل پاسخ چقدر است؟ | حریم خصوصی و حداقلسازی داده رعایت شود |
برای هر Link شناسه پایدار، Group، Template و نسخه Footer را ثبت کنید. پیش و پس از تغییر، Task success، خطای Navigation و کیفیت تماس را مقایسه کنید. نتیجه یک A/B test را بدون اندازه نمونه و Guardrail قطعی ندانید.
سیستم محتوا و مالکیت فوتر
فوتر Component سراسری با Blast radius بالا است. یک URL غلط یا Script خراب میتواند همه صفحات را درگیر کند. تغییر آن باید Review، Preview و Rollback داشته باشد.
| دارایی | مالک نمونه | تناوب بازبینی |
|---|---|---|
| Navigation و Label | Product/Content Design | فصلی و پس از تغییر IA |
| تماس و شعب | عملیات/پشتیبانی | ماهانه یا هنگام تغییر |
| سیاستهای حقوقی | Legal/مدیر مسئول | نسخهدار و رویدادمحور |
| نماد و گواهی | Compliance/Security | پیش از انقضا و ماهانه |
| کد و Accessibility | Frontend/QA | هر Release |
| Analytics | Data/Product | پس از تغییر Schema رویداد |
اشتباهات رایج در طراحی فوتر
- کپی کردن Footer رقیب بدون توجه به Journey و نوع سایت
- قرار دادن همه صفحهها، شهرها و کلمات کلیدی در یک Mega footer
- ساخت لینک با
onclickبدونhrefواقعی - استفاده از Anchorهای تکراری و Keyword-rich برای دستکاری سئو
- پنهان کردن هزینه، مرجوعی یا هویت فقط پشت لینک Footer
- نمایش Badge غیرقابل کلیک، منقضی یا متعلق به کسبوکار دیگر
- فونت ریز، Contrast پایین و Focus نامرئی
- آیکون Social بدون نام قابل دسترس
- Accordion موبایل خراب یا وابسته به JavaScript نامطمئن
- فرم خبرنامه بدون توضیح استفاده از داده و مسیر لغو
- Fixed footer که محتوا و صفحهکلید را میپوشاند
- سال، شماره، شعبه و Link قدیمی بدون Owner و Alert
فرایند طراحی و پیادهسازی فوتر
مرحله ۱: Brief و Inventory
نوع سایت، سه کار اصلی کاربر، الزامات کسبوکار و Scope Templateها را بنویسید. سپس تمام لینکها، Badgeها، فرمها و Scriptهای فعلی را فهرست کنید.
مرحله ۲: IA و Prototype
گروهها و Labelها را با Card sorting یا Tree test سبک بیازمایید. Prototype Desktop، موبایل، متن بلند و حالت خطا بسازید؛ فقط Happy path را طراحی نکنید.
مرحله ۳: Design و Content spec
Grid، Token فاصله/رنگ/تایپ، Stateهای Hover/Focus، Breakpoint، ترتیب DOM، Anchor، Alt، Accessible name و Error copy را مشخص کنید.
مرحله ۴: توسعه و تست
HTML معنایی، Link واقعی، فرم و Event schema را پیاده کنید. Keyboard، Screen reader، Zoom، RTL، ۳۲۰px، دستگاه واقعی، Script failure و Slow network را تست کنید.
مرحله ۵: Rollout و پایش
در Staging همه Templateها را بررسی و تغییر را Canary یا با Rollback روشن منتشر کنید. Link checker، Error log، RUM و رویدادهای Footer را پس از انتشار زیر نظر بگیرید.
ماتریس تست پذیرش فوتر
| لایه | آزمون | معیار پذیرش |
|---|---|---|
| محتوا | مالک، تاریخ، اطلاعات تماس و Policy | صحیح، جاری و قابل راستیآزمایی |
| Navigation | Anchor، مقصد، Status و Redirect | هدف روشن و بدون لینک شکسته/Chain |
| Semantic | Footer/Contentinfo/Nav/Heading/List | Landmark و نامها معنادار |
| Keyboard | Tab، Focus و Accordion | ترتیب منطقی، بدون Trap و پوشیدگی |
| Screen reader | Landmark، Link، Social و Form status | نام و وضعیت قابل فهم |
| Responsive | ۳۲۰px، Zoom، Landscape و RTL | بدون حذف، برش و Scroll دوبعدی |
| Performance | Script/Font/Image/CLS | در بودجه و بدون Regression |
| Analytics | View/Click/Task و Consent | رویداد درست، حداقل داده، QA شده |
برنامه ۳۰روزه بهبود فوتر
هفته اول: ممیزی
- لینک، مقصد، Status، Redirect chain، Badge و Script را Inventory کنید.
- تماسها، سیاستها و مالک هر محتوا را راستیآزمایی کنید.
- Baseline کلیک، تیکت و Taskهای پرتکرار را ثبت کنید.
هفته دوم: اولویت و Prototype
- لینکهای کمارزش، تکراری و Keyword-driven را حذف یا جابهجا کنید.
- گروه و Label را با پنج تا هشت کاربر هدف یا Tree test بررسی کنید.
- نسخه موبایل/RTL و حالت فرم خطادار را Prototype کنید.
هفته سوم: پیادهسازی
- HTML معنایی، Focus، Contrast، Tap target و Reflow را اصلاح کنید.
- Asset/Third-party را کم و Event schema را نسخهدار کنید.
- Policyها و Badgeهای معتبر را با Owner روشن بهروز کنید.
هفته چهارم: انتشار و یادگیری
- ماتریس دستگاه، Keyboard، Screen reader و Link را اجرا کنید.
- تغییر را با Rollback منتشر و Error/CLS/Task را پایش کنید.
- نتیجه را با Baseline مقایسه و Backlog بعدی را اولویت دهید.
چکلیست نهایی طراحی فوتر سایت
- فوتر برای کارهای واقعی انتخاب شده، نه کپی رقبا.
- هر لینک سراسری هدف، مقصد سالم و مالک دارد.
- گروهها عنوان دقیق و Anchorها متن طبیعی دارند.
- تعداد Link با نیاز تعیین شده، نه سقف ساختگی ۱۰۰.
- Keyword stuffing، لینک پنهان و Credit اجباری وجود ندارد.
- Linkها
<a href>واقعی و قابل Crawl هستند. - Footer سطح صفحه Landmark درست Contentinfo میسازد.
- چند Navigation نام قابل تشخیص دارند.
- Focus، Contrast، Target size و Reflow با WCAG ۲.۲ تست شدهاند.
- RTL، شماره، ایمیل و آدرس روی گوشی واقعی درست نمایش داده میشوند.
- اطلاعات تماس، Policy و نماد قابل راستیآزمایی و جاریاند.
- اطلاعات ضروری خرید فقط در Footer پنهان نشده است.
- خبرنامه Value proposition، Label، Privacy و لغو روشن دارد.
- Script، Embed، Font و Badge در بودجه عملکرد هستند.
- Footer view، Click و Task success با Context سنجیده میشوند.
- تغییر سراسری Preview، QA، Owner، Monitoring و Rollback دارد.
پرسشهای متداول
در فوتر سایت چه چیزهایی باید باشد؟
برای بیشتر سایتها راه تماس، Navigation ثانویه، پشتیبانی، هویت کسبوکار و لینک سیاستهای مرتبط پایهاند. دستههای محصول، خبرنامه، شبکه اجتماعی، نماد و CTA فقط وقتی اضافه شوند که برای Journey همان سایت ارزش و مالک مشخص دارند.
آیا لینکهای فوتر روی سئو اثر دارند؟
لینک قابل Crawl و Anchor روشن میتواند به کشف و فهم صفحات کمک کند، اما Footer جای لینک Contextual و معماری اطلاعات نیست. Linkهای Keyword-rich یا توزیعشده در Template سایتهای مختلف با هدف دستکاری رتبه میتوانند مشمول سیاست Link spam شوند.
تعداد مناسب لینکهای فوتر چند است؟
عدد ثابت و سقف جادویی وجود ندارد. کمترین مجموعهای را نگه دارید که کارهای سراسری مهم را پوشش میدهد و روی موبایل، Keyboard و Screen reader قابل پیمایش است. اگر گروهبندی و تمایز Linkها دشوار شده، تعداد یا محل آنها را بازنگری کنید.
آیا درج کپیرایت و نماد اعتماد کافی است؟
نه. متن کپیرایت بهتنهایی مانع کپی نیست و Badge تصویری نیز اعتبار جاری را ثابت نمیکند. هویت، راه تماس، Policyهای منطبق با عملیات، نماد قابل راستیآزمایی و فرایند پاسخگویی شواهد قویتریاند.
Accordion فوتر در موبایل خوب است؟
اگر طول Footer زیاد است میتواند مفید باشد، به شرط استفاده از Button واقعی، وضعیت aria-expanded، کارکرد Keyboard، دسترسی Linkها در DOM و نبود پرش Focus. برای Footer کوتاه، ستونهای Stackشده ممکن است سادهتر و مقاومتر باشند.
جمعبندی
فوتر خوب با تعداد ستون یا ظاهر پرزرقوبرق سنجیده نمیشود. باید به کاربر کمک کند مسیر، پشتیبانی و اطلاعات قابل اعتماد را پیدا کند؛ برای موتور جستوجو Link واقعی و طبیعی بسازد؛ در موبایل و فناوری کمکی کار کند؛ و با Owner و پایش سالم بماند. از Inventory و Task شروع کنید، Linkهای سراسری را سختگیرانه انتخاب کنید و هر Release را مانند یک تغییر پراثر در کل سایت آزمایش کنید.






