بازطراحی سایت را از کجا شروع کنیم؟ ممیزی پیش از تغییر ظاهر

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

چرا «ظاهر قدیمی» همیشه مشکل اصلی نیست؟

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

چهار نوع مشکل که باید جدا شوند

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

بخش تجربهٔ کاربری: چه چیزی را بررسی کنیم؟

سه وظیفهٔ اصلی بازدیدکنندهٔ هدف را فهرست کنید (مثلاً پیداکردن خدمت مناسب، دیدن نمونه‌کار، تماس) و آن‌ها را روی نسخهٔ فعلی از ابتدا تا انتها انجام دهید؛ هر جا گیر کردید ثبت کنید. تفاوت UX و UI را در UX چیست و چرا فقط زیبا بودن سایت نیست ببینید تا ظاهر و تجربه را در ممیزی جدا کنید.

دسترس‌پذیری پیش از طراحی جدید

W3C در روش ارزیابی WCAG-EM 2.0 (یادداشت گروه کاری، ۲۳ ژوئیهٔ ۲۰۲۶) می‌نویسد ارزیابی دسترس‌پذیری می‌تواند پیش از عرضه، خرید یا بازطراحی یک محصول، و همچنین برای پایش دوره‌ای انجام شود. روش شامل پنج گام است: تعریف دامنه، شناخت محصول، انتخاب نمونهٔ معرف، ارزیابی نمونه و گزارش یافته‌ها. در بیشتر کاربردها فقط نمونه‌ای از محصول ارزیابی می‌شود؛ برای سایتی با صفحه‌های کم می‌توان همهٔ صفحه‌ها را ارزیابی کرد. اما حواستان به یک مرز مهم باشد: همان سند صریحاً می‌گوید ادعای انطباق WCAG 2 برای کل یک وب‌سایت را نمی‌توان فقط بر پایهٔ ارزیابی زیرمجموعه‌ای از صفحه‌ها و قابلیت‌ها گذاشت، چون همیشه ممکن است خطاهای شناسایی‌نشده وجود داشته باشد؛ و در بیشتر موقعیت‌ها استفاده از این روش به‌تنهایی به ادعای انطباق نمی‌انجامد. پس در ممیزی پیش از بازطراحی، یافته‌های نمونه را «تشخیص و اولویت‌بندی مشکلات» بنامید، نه «تأیید دسترس‌پذیری کل سایت». جزئیات مفهومی را در Accessibility چیست مرور کنید. همچنین این یادداشت راهنمای اطلاعاتی است و الزامات خود WCAG را جایگزین نمی‌کند.

بخش فنی و سئو: چه چیزهایی را نباید از دست داد؟

اگر سایت فعلی ترافیک ارگانیک یا لینک ورودی دارد، آدرس‌ها دارایی‌اند. Google Search Central در راهنمای انتقال سایت توصیه می‌کند فهرست آدرس‌های قدیمی را از منابع مختلف جمع کنید: sitemap، گزارش‌های سرور یا ابزار تحلیل، گزارش لینک‌ها در Search Console و فهرست URLهای CMS. همچنین تصویر، ویدیو، CSS و JavaScript هم باید در برنامه دیده شوند، چون این آدرس‌ها هم مثل بقیهٔ محتوا نقل‌مکان می‌کنند. این سند دربارهٔ تغییر آدرس‌هاست؛ اگر بازطراحی شما آدرس‌ها را عوض نمی‌کند بعضی بخش‌ها (مثل ریدایرکت) لازم نیست، ولی منطق «فهرست کن، نقشه بکش، اندازه بگیر» همچنان مفید است.

چند نکتهٔ عملی از همان راهنما:

• یک تغییر در هر نوبت: Google می‌گوید اگر می‌خواهید هم دامنه عوض شود، هم CMS و هم چیدمان، آن‌ها را یکی پس از دیگری انجام دهید.
• نوسان موقت را انتظار داشته باشید: با تغییرات مهم ممکن است رتبه موقتاً نوسان کند؛ برای سایت‌های متوسط ممکن است چند هفته یا بیشتر طول بکشد تا آدرس‌های جدید جای قدیمی را بگیرند.
• ریدایرکت دائمی: طبق همان راهنما، ریدایرکت‌های ۳۰۱ و سایر ریدایرکت‌های دائمی باعث از دست رفتن PageRank نمی‌شوند.
• محتوای حذف یا ادغام‌شده: آدرس‌هایی که دیگر معادل ندارند باید در سایت جدید ۴۰۴ یا ۴۱۰ برگردانند.
• نسخهٔ آزمایشی را قفل نکنید: اگر در دوران توسعه robots.txt یا noindex گذاشته‌اید، فهرست رفع آن‌ها را از قبل آماده کنید تا هنگام انتشار فراموش نشود.
• ظرفیت سرور: پس از مهاجرت، Google موقتاً سنگین‌تر از معمول سایت را می‌خزد؛ ظرفیت کافی لازم است.

یک خط پایه (baseline) قبل از تغییر بسازید

بدون عدد «قبل»، بعد از انتشار نمی‌توانید بگویید بازطراحی کمک کرده یا ضرر زده. حداقل سه چیز را ثبت کنید. اول، گزارش Performance در Search Console: طبق راهنمای رسمی، نمای پیش‌فرض کلیک و نمایش سه ماههٔ اخیر را نشان می‌دهد و کلیک، نمایش، CTR و میانگین جایگاه را می‌توان بر اساس پرسش و صفحه دید؛ از آن صفحه‌هایی را که بیشترین کلیک را می‌گیرند فهرست کنید تا آدرسشان حفظ شود. دوم، Core Web Vitals: web.dev آستانه‌های LCP تا ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰٫۱ را معرفی می‌کند و می‌گوید باید در صدک ۷۵ بارگذاری‌ها سنجیده شود؛ پس از دادهٔ میدانی استفاده کنید و اگر حجم بازدید کم است ممکن است دادهٔ کافی نباشد. سوم، رویدادهای تبدیل واقعی مثل ارسال فرم یا تماس.

چارچوب تصمیم: حفظ، بهبود یا بازسازی؟

برای هر صفحه یا بخش یکی از چهار تصمیم را بنویسید:

1. حفظ: هم عملکرد خوب دارد هم محتوای درست؛ آدرس و متن را دست نزنید.
2. بهبود: پایه درست است، فقط محتوا یا فرم یا سرعت نیاز به اصلاح دارد.
3. ادغام یا حذف: دو صفحه با یک نیت یا صفحهٔ بی‌ارزش؛ با ریدایرکت یا ۴۰۴/۴۱۰ درست مدیریت شود.
4. بازسازی: ساختار یا فناوری مانع بهبود است و باید از نو ساخته شود.

اگر بازسازی در فهرست زیاد شد، سؤال بعدی انتخاب مسیر است: WordPress یا توسعهٔ اختصاصی.

چک‌لیست پیش از مهاجرت

1. ممیزی چهارحوزه‌ای با شاهد برای هر یافته انجام شده است (یافته‌های دسترس‌پذیری به‌عنوان تشخیص مشکل ثبت شده‌اند، نه ادعای انطباق کل سایت).
2. فهرست آدرس‌های مهم (ترافیک، لینک، sitemap) و نقشهٔ آدرس قدیم به جدید آماده است.
3. خط پایهٔ Search Console، Core Web Vitals و رویدادهای تبدیل ثبت شده است.
4. تصمیم حفظ/بهبود/ادغام/بازسازی برای هر بخش نوشته شده است.
5. نسخهٔ آزمایشی آماده، robots.txt و noindex آن مدیریت و فهرست رفع‌شان آماده است.
6. ظرفیت سرور و برنامهٔ پایش بعد از انتشار مشخص است.
7. تغییرات بزرگ (دامنه، CMS، چیدمان) تا حد ممکن جدا از هم زمان‌بندی شده‌اند.

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

منابع و مراجع

• Site Moves and Migrations (How to move a site) — Google Search Central.
• WCAG Evaluation Methodology (WCAG-EM) 2.0 — W3C Group Note، ۲۳ ژوئیهٔ ۲۰۲۶.
• Performance report (Search results): Overview and basic setup — Search Console Help، Google.
• Web Vitals — web.dev (Google)، آخرین به‌روزرسانی ۳۱ اکتبر ۲۰۲۴.