درود بر شما. من محمد صدرا حسینی هستم، کارشناس سئو در مجموعه وزیر سئو.
انتخاب بین دامنه با www یا بدون آن، یکی از اولین دوراهیهای فنی است که اغلب مدیران سایت را به اشتباه میاندازد. بسیاری تصور میکنند این صرفاً یک سلیقه بصری است، اما در واقعیت، این تصمیم مستقیماً بر سرعت بارگذاری، مدیریت کوکیها و توزیع اعتبار لینکها تأثیر میگذارد. تعیین صحیح دامنه ترجیحی و یکپارچهسازی آدرسها، یکی از حیاتیترین مراحل در پیکربندی پایه سئو در وردپرس است. اگر این خشت اول کج نهاده شود، سایت شما در آینده با مشکلاتی نظیر محتوای تکراری و هدر رفتن بودجه خزش مواجه خواهد شد. در این مقاله تخصصی، ما از بحثهای سطحی عبور کرده و با نگاهی مهندسی، بهترین ساختار را برای کسبوکار شما انتخاب میکنیم.
جدول کاربردی (Actionable Table)
| فاکتور تصمیمگیری | دامنه با www (کلاسیک) | دامنه بدون www (مدرن) |
| مقیاسپذیری فنی (DNS) | عالی (انعطافپذیر با CNAME) | محدود (نیاز به CNAME Flattening) |
| مدیریت کوکیها | ایزوله و بهینه برای زیردامنهها | ارسال اجباری کوکی به تمام سابدامینها |
| استفاده از CDNهای عظیم | بسیار سازگار و ایمن | ممکن است با چالشهای DNS روبرو شود |
| زیبایی و کوتاهی URL | طولانیتر و سنتی | کوتاهتر، مینیمال و تمیز |
| مناسب برای | فروشگاههای بزرگ، بانکها، سازمانها | استارتاپها، بلاگها، سایتهای شخصی |
ماهیت فنی ماجرا: www در برابر دامنه بدون پیشوند (Naked Domain)
در نگاه اول، example.com و www.example.com ممکن است یکسان به نظر برسند و اکثر کاربران نهایی تفاوتی قائل نمیشوند. اما برای مهندسان شبکه و متخصصان سئو تکنیکال، این دو ماهیت کاملاً متفاوتی دارند. دامنه بدون پیشوند (که به آن Naked Domain یا Root Domain گفته میشود) و زیردامنهی www، رفتارهای متفاوتی در سطح رکوردهای DNS و مدیریت کوکیها از خود نشان میدهند.
تفاوت ساختاری در رکوردهای DNS (محدودیتهای CNAME و A Record)
برای درک عمیق این موضوع، باید به نحوه ترجمه نام دامنه به آدرس IP توسط سیستم نام دامنه (DNS) توجه کنیم. اینجاست که محدودیتهای فنی خود را نشان میدهند:
- محدودیت دامنه ریشه (Naked Domain): طبق استانداردهای کلاسیک DNS (RFC 1034)، دامنه ریشه (مثلاً com) باید حتماً به یک A Record اشاره کند. A Record یک آدرس IP ثابت (Static IP) است. شما نمیتوانید برای دامنه ریشه از CNAME (نام مستعار) استفاده کنید.
- انعطافپذیری www: پیشوند www در واقع یک زیردامنه (Subdomain) است. زیردامنهها محدودیتی در استفاده از CNAME Record ندارند. CNAME به شما اجازه میدهد که نام دامنه خود را به جای یک IP ثابت، به یک نام دامنه دیگر (مانند آدرس سرورهای ابری یا لود بالانسرها) ارجاع دهید.
نکته فنی: اگر از دامنه ریشه (بدون www) استفاده کنید، به یک آدرس IP خاص محدود میشوید. اگر نیاز باشد سرور را تغییر دهید و IP عوض شود، باید رکوردهای DNS را آپدیت کنید که زمانبر است (DNS Propagation). اما با www و استفاده از CNAME، این تغییرات سمت ارائهدهنده هاستینگ انجام شده و شما نیازی به تغییر IP در رکوردهای خود ندارید.
مدیریت کوکیها (Cookies) و تاثیر آن بر درخواستهای سرور
یکی از مهمترین دلایل استفاده از www در سایتهای بزرگ، بحث بهینهسازی پرفورمنس (Performance) و مدیریت کوکیها است.
- مشکل دامنه ریشه: وقتی شما کوکیها را روی دامنه ریشه (com) تنظیم میکنید، طبق استانداردهای HTTP، این کوکیها به صورت خودکار به تمام زیردامنهها نیز ارسال میشوند.
- چرا این بد است؟ فرض کنید شما تصاویر و فایلهای استاتیک (CSS/JS) خود را روی یک زیردامنه مانند example.com میزبانی میکنید. اگر کوکیها روی دامنه ریشه ست شده باشند، مرورگر کاربر در هر درخواستی که برای دریافت یک عکس ساده ارسال میکند، کوکیها را نیز ضمیمه میکند. این کار باعث افزایش بیهوده حجم هدرهای HTTP و درگیر شدن پهنای باند میشود، در حالی که سرور فایلهای استاتیک هیچ نیازی به خواندن کوکیهای احراز هویت ندارد.
- راهکار www: اگر سایت اصلی شما روی example.com باشد، میتوانید کوکیها را محدود به همین زیردامنه کنید. در نتیجه، زیردامنههای دیگر شما (مثل static.example.com) کاملاً بدون کوکی (Cookie-Free) باقی میمانند و درخواستها سبکتر و سریعتر ارسال میشوند.
چرا سایتهای بزرگ و پرترافیک معمولاً از www استفاده میکنند؟ (بحث CDN)
سایتهای پرترافیک برای توزیع محتوا و جلوگیری از حملات DDoS، به شدت به شبکههای تحویل محتوا (CDN) وابسته هستند.
- سازگاری با CDN: سرویسهای CDN برای عملکرد بهینه، معمولاً نیاز دارند که ترافیک شما از طریق CNAME به شبکه آنها هدایت شود تا بتوانند به صورت پویا نزدیکترین سرور را به کاربر اختصاص دهند.
- چالش دامنه بدون پیشوند: همانطور که گفته شد، دامنههای ریشه معمولاً از CNAME پشتیبانی نمیکنند. اگرچه برخی سرویسدهندگان DNS مدرن (مانند Cloudflare) راهحلهایی مثل “CNAME Flattening” یا “ANAME” ارائه دادهاند تا این مشکل را دور بزنند، اما این راهحلها همیشه استاندارد نیستند و ممکن است در برخی سناریوهای پیچیده شبکه دچار اختلال شوند.
- پایداری و افزونگی (Redundancy): استفاده از www به مهندسان این امکان را میدهد که ترافیک را بین چندین دیتاسنتر با استفاده از رکوردهای CNAME توزیع کنند. این سطح از مدیریت ترافیک برای سایتهایی با میلیونها بازدیدکننده حیاتی است.
جمعبندی اجرایی: اگر سایت شما کوچک است، تفاوت چندانی احساس نمیکنید. اما اگر افق دید شما مقیاسپذیری بالا (High Scalability) و استفاده حرفهای از CDN است، استفاده از ساختار www استانداردتر و کمریسکتر است.
تاثیر انتخاب www یا non-www بر سئو (SEO) و رتبهبندی
بسیاری از مدیران سایت تصور میکنند که انتخاب یکی از این دو حالت، یک “فاکتور رتبهبندی” (Ranking Factor) است. بگذارید همین ابتدای کار شفاف باشم: گوگل ذاتاً هیچ ارجحیتی برای www یا بدون www قائل نیست.
اما، عدم ثبات در انتخاب یکی از این دو، میتواند فاجعهبار باشد. تاثیر اصلی این انتخاب بر سئو، در نحوه مدیریت “یکپارچگی” سایت شما نهفته است.
مشکل محتوای تکراری (Duplicate Content) و همخواری صفحات
خطرناکترین پیامد عدم تنظیم صحیح این ساختار، ایجاد “محتوای تکراری” است.
- سناریوی شکست: فرض کنید شما مقالهای عالی درباره “سئو تکنیکال” نوشتهاید. اگر سرور شما هر دو آدرس (با و بدون www) را باز کند و کد وضعیت 200 (OK) برگرداند، رباتهای گوگل (Googlebots) هر دو صفحه را خزش میکنند.
- نتیجه: گوگل دو صفحه با محتوای کاملاً یکسان در دو آدرس متفاوت میبیند.
- همنوعخواری (Cannibalization): در این حالت، الگوریتم گوگل گیج میشود که کدام نسخه را در نتایج جستجو نمایش دهد. گاهی نسخه www را رتبه میدهد و گاهی نسخه بدون www را. این تقسیم توجه باعث میشود که قدرت صفحه اصلی شما نصف شود و رقبای شما (که شاید محتوای ضعیفتری داشته باشند اما ساختار فنی سالمی دارند) از شما پیشی بگیرند.
راهکار اجرایی: باید یک نسخه را به عنوان نسخه اصلی (Canonical) انتخاب کنید و دیگری را با استفاده از ریدایرکت ۳۰۱ (301 Redirect) به نسخه اصلی ارجاع دهید. همچنین استفاده از تگ rel=”canonical” در هدر صفحات الزامی است تا به گوگل سیگنال قطعی بدهید که کدام نسخه “ارباب” است.
توزیع اعتبار لینک (Link Juice) در صورت عدم یکپارچهسازی
در سئو، ما مفهومی به نام “عصاره لینک” یا Link Equity داریم. بکلینکها سوخت حرکت سایت شما در نتایج جستجو هستند.
- هدر رفتن اعتبار: تصور کنید سایتهای خبری معتبر به دامنه شما لینک دادهاند. برخی به example.com لینک میدهند و برخی دیگر (بهصورت ناخودآگاه) به example.com.
- دیوار بین اعتبار: اگر ریدایرکت ۳۰۱ بین این دو نسخه برقرار نباشد، گوگل این بکلینکها را متعلق به دو موجودیت جداگانه میداند. یعنی شما عملاً ۵۰٪ از اعتبار دامنه (Domain Authority) خود را دور میریزید.
- تجمیع قدرت: با تنظیم ریدایرکت ۳۰۱ سراسری (Site-wide 301 Redirect)، تمام اعتباری که به نسخه فرعی وارد میشود، فوراً و به طور کامل (یا نزدیک به ۱۰۰٪) به نسخه اصلی منتقل میشود. این کار باعث میشود تمام تلاشهای لینکسازی شما در یک نقطه متمرکز شود و قدرت دامنه افزایش یابد.
آیا گوگل بین این دو تبعیض قائل میشود؟ (تحلیل الگوریتم)
از نظر فنی و الگوریتمی، پاسخ خیر است. جان مولر (John Mueller) از گوگل بارها تأیید کرده است که گوگل “اولویت ذاتی” برای هیچکدام ندارد.
اما بیایید عمیقتر نگاه کنیم. گوگل به دنبال تجربه کاربری (UX) و اعتماد (Trust) است.
- سیگنالهای برند: در برخی صنایع سنتی و شرکتی، کاربران هنوز انتظار دارند آدرس را با www تایپ کنند. وجود www میتواند حس رسمی بودن و “شرکتی بودن” را منتقل کند.
- رفتار کاربر: اگر کاربر آدرس را بدون www وارد کند و سایت باز نشود (یا برعکس)، این یک تجربه کاربری منفی است. اگرچه این مستقیم الگوریتم نیست، اما افزایش نرخ پرش (Bounce Rate) یا عدم دسترسی، سیگنال منفی به گوگل میفرستد.
- کنسول جستجو (GSC): در گذشته لازم بود هر دو نسخه را در سرچ کنسول ثبت کنید. اما اکنون با قابلیت Domain Property، گوگل تمام نسخهها (http, https, www, non-www) را یکجا رصد میکند. این نشان میدهد که برای گوگل، “تجمیع دادهها” اولویت دارد، نه پیشوند دامنه.
جمعبندی استراتژیک این بخش: انتخاب با شماست، اما ثبات با سرور است.
- اگر برند جدید و مدرنی هستید و میخواهید آدرسهای کوتاه و مینیمال داشته باشید -> بدون www (Naked Domain).
- اگر سایتی بسیار بزرگ هستید که نگران کوکیها و توزیع ترافیک روی CDN هستید (مطابق بحث فنی قبل) -> با www.
مهمترین اقدام این است که همین امروز مطمئن شوید فقط یک نسخه باز میشود و نسخه دیگر ریدایرکت ۳۰۱ میشود.
دامنه ترجیحی (Preferred Domain) چیست و چگونه انتخاب کنیم؟
در اصطلاح سئو، دامنه ترجیحی نسخهای از آدرس سایت شماست (با www یا بدون آن) که شما میخواهید گوگل آن را ایندکس کند و کاربران آن را ببینند.
در گذشته، کنسول جستجوی گوگل (Google Search Console) گزینهای داشت که مستقیماً از شما میپرسید: “کدام را ترجیح میدهید؟”. اما اکنون گوگل هوشمندتر شده و بر اساس تگهای Canonical، ریدایرکتها و ساختار سایتمپ، انتخاب شما را تشخیص میدهد.
قانون طلایی من: انتخاب شما باید “باینری” (صفر و یک) باشد. هرگز نباید هر دو نسخه را فعال نگه دارید. اما چگونه انتخاب کنیم؟ بیایید فاکتورهای انسانی را تحلیل کنیم.
بررسی فاکتورهای زیباییشناسی، کوتاهی URL و رفتار کاربران موبایل
امروزه “مینیمالیسم دیجیتال” (Digital Minimalism) حرف اول را میزند. بیایید تفاوتها را در دنیای واقعی ببینیم:
۱. رویکرد مدرن و کوتاه (بدون www):
- زیباییشناسی: دامنههای بدون پیشوند (Naked Domains) تمیزتر، کوتاهتر و خواناتر هستند. برای مثال com بسیار جذابتر و سریعتر از www.vazirseo.com خوانده میشود.
- رفتار کاربران موبایل: در موبایل، فضای نوار آدرس (Omnibar) بسیار محدود است. حذف ۴ کاراکتر اضافی () میتواند باعث شود که نام برند یا ساختار URL شما کاملتر دیده شود.
- تایپ راحتتر: کاربران موبایل از تایپ کردن بیزارند. حذف www یعنی حذف چهار ضربه اضافه به صفحه کلید.
۲. رویکرد سنتی و رسمی (با www):
- تشخیص هویت: برای کاربران مسنتر یا کمتر تکنیکال، دیدن www تضمینی است بر اینکه “این یک وبسایت است”. در برخی موارد، نبودن آن ممکن است باعث شود کاربر فکر کند آدرس ناقص است (هرچند این تصور رو به کاهش است).
نکته انحرافی مرورگرها: توجه داشته باشید که مرورگرهای مدرن مانند Google Chrome، اغلب پروتکل (https://) و زیردامنه (www) را در نوار آدرس مخفی میکنند تا ظاهری تمیزتر ارائه دهند. اما وقتی کاربر آدرس را کپی میکند تا در واتساپ یا تلگرام بفرستد، این پیشوندها ظاهر میشوند. بنابراین، “طول واقعی کاراکترها” همچنان برای اشتراکگذاری اهمیت دارد.
اهمیت ثبات برند (Brand Consistency) در انتخاب نهایی
فراتر از صفحه نمایش، برند شما در دنیای فیزیکی و کلامی نیز زندگی میکند. تصمیم شما باید با استراتژی بازاریابی آفلاین شما هماهنگ باشد.
- تبلیغات محیطی و کارت ویزیت: اگر روی کارت ویزیت خود فضای کمی دارید، دامنه بدون www (com) گزینهای عالی است. فونت درشتتر و خوانایی بیشتر. اما اگر مخاطب شما بسیار سنتی است، شاید لازم باشد www را درج کنید تا متوجه شوند این یک آدرس اینترنتی است.
- گفتار و تبلیغات صوتی (پادکست/رادیو): گفتن “دبلیو دبلیو دبلیو” در تبلیغات صوتی، حدود ۲ تا ۳ ثانیه زمان میبرد و ریتم کلام را میشکند. گفتن “به سایت وزیر سئو دات کام سر بزنید” بسیار روانتر است.
- یکپارچگی در لینکسازی: وقتی تصمیم گرفتید، باید متعصبانه روی آن بایستید. تمام لینکهای داخلی، امضای ایمیل کارکنان، پروفایلهای شبکههای اجتماعی و بکلینکهای رپورتاژی باید دقیقاً با همان فرمت انتخابی باشند. عدم ثبات در اینجا، سیگنالهای متناقض به گوگل میفرستد.
جدول راهنمای تصمیمگیری سریع:
| نوع کسبوکار | توصیه محمدصدرا حسینی | دلیل استراتژیک |
| استارتاپها، SaaS، سایتهای تکنولوژی | بدون www | مدرن، کوتاه، مناسب برای مخاطبِ آگاه به تکنولوژی. |
| فروشگاههای اینترنتی بسیار بزرگ | با www | نیاز به مدیریت کوکی و CDN (بحث فنی قبلی)، ایجاد حس امنیت سنتی. |
| سازمانهای دولتی، بانکها، بیمه | با www | القای حس رسمی بودن، ساختار سازمانی و اعتماد کلاسیک. |
| بلاگهای شخصی، پورتفولیو | بدون www | صمیمیت بیشتر، سادگی و سهولت در اشتراکگذاری. |
جمعبندی این بخش:
اگر محدودیت فنی خاصی (مثل CDNهای پیچیده قدیمی) ندارید، پیشنهاد من به عنوان یک استراتژیست مدرن، حرکت به سمت دامنه بدون www است. این آینده وب است: کوتاهتر، سریعتر و تمیزتر.
آموزش تنظیم دامنه ترجیحی و ریدایرکت صحیح (گامبهگام)
برای اینکه موتورهای جستجو و کاربران فقط یک نسخه از سایت شما را ببینند، باید یک دیوار محکم بنا کنیم. ما این کار را در سه لایه انجام میدهیم: لایه اپلیکیشن (CMS)، لایه سرور (Server Config) و لایه HTML (Canonicals).
تنظیم صحیح آدرسها در تنظیمات عمومی وردپرس (WordPress)
اگر از وردپرس استفاده میکنید، این اولین و سادهترین گام است. وردپرس به طور پیشفرض بسیاری از ریدایرکتها را مدیریت میکند، اما باید آدرس صحیح را بشناسد.
- وارد پنل مدیریت وردپرس شوید.
- به مسیر تنظیمات > عمومی (Settings > General) بروید.
- دو فیلد مهم را پیدا کنید:
- نشانی وردپرس (WordPress Address)
- نشانی سایت (Site Address)
- هر دو فیلد را دقیقاً به فرمتی که انتخاب کردهاید تغییر دهید.
- اگر انتخاب شما بدون www است: https://example.com
- اگر انتخاب شما با www است: https://www.example.com
هشدار فنی: بلافاصله پس از ذخیره تغییرات، از پنل مدیریت خارج میشوید و باید دوباره لاگین کنید. نترسید، این نشانه درستی کار شماست.
کدنویسی ریدایرکت ۳۰۱ در فایل .htaccess (برای سرورهای آپاچی)
بسیاری از سایتها روی سرورهای وب Apache یا LiteSpeed میزبانی میشوند که از فایل .htaccess برای مدیریت درخواستها استفاده میکنند. این روش، قدرتمندترین روش برای اجبار ریدایرکت قبل از بارگذاری وردپرس است.
فایل .htaccess را در ریشه هاست خود (معمولاً public_html) ویرایش کنید و کدهای زیر را در ابتدای فایل قرار دهید.
سناریو ۱: اجبار به استفاده از دامنه “بدون www” (پیشنهاد مدرن)
اگر میخواهید همه ترافیک www.example.com به example.com منتقل شود:
Apache
<IfModule mod_rewrite.c>RewriteEngine OnRewriteCond %{HTTP_HOST} ^www\.example\.com [NC]RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]</IfModule>
سناریو ۲: اجبار به استفاده از دامنه “با www” (پیشنهاد کلاسیک)
اگر میخواهید همه ترافیک example.com به www.example.com منتقل شود:
Apache
<IfModule mod_rewrite.c>RewriteEngine OnRewriteCond %{HTTP_HOST} ^example\.com [NC]RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]</IfModule>
تفسیر کد: عبارت R=301 به مرورگر و گوگل میگوید که این تغییر آدرس “دائمی” است. این کلید انتقال اعتبار سئو است.
پیکربندی سرور برای Nginx (تکنیکهای پیشرفته سرور)
اگر سایت شما روی سرورهای پرسرعت Nginx (بدون آپاچی) میزبانی میشود، فایل .htaccess کارایی ندارد. شما باید “Server Block”ها را در فایل کانفیگ سرور (معمولاً در مسیر /etc/nginx/sites-available/) ویرایش کنید.
سناریو: ریدایرکت از www به non-www در Nginx
شما باید یک بلوک سرور جداگانه برای نسخه www بسازید که تنها وظیفهاش ریدایرکت کردن است:
Nginx
server { listen 80; listen 443 ssl; server_name www.example.com; return 301 $scheme://example.com$request_uri;}
این کد بسیار بهینه است زیرا Nginx نیازی به پردازش درخواست ندارد و بلافاصله کاربر را به آدرس صحیح پرتاب میکند.
تعیین استراتژی کنونیکال (Canonical Tags) برای تضمین ایندکس صحیح
ریدایرکتها کاربر را هدایت میکنند، اما تگ کنونیکال (Rel=Canonical) با گوگل صحبت میکند. این تگ به عنوان یک “بیمهنامه” عمل میکند تا اگر به هر دلیلی ریدایرکت عمل نکرد، گوگل بداند نسخه اصلی کدام است.
- منطق کار: حتی اگر کاربری بتواند نسخه www را ببیند، سورس کد آن صفحه باید حاوی تگی باشد که بگوید: “من نسخه اصلی نیستم، نسخه اصلی در آدرس non-www قرار دارد.”
- اجرا در وردپرس: خوشبختانه افزونههایی مثل Yoast SEO یا RankMath این کار را خودکار انجام میدهند.
- به محض اینکه تنظیمات عمومی وردپرس (مرحله اول) را انجام دهید، این افزونهها به صورت خودکار تگ canonical را برای تمام صفحات روی نسخه انتخابی شما تنظیم میکنند.
اقدام پایانی (بررسی نهایی): پس از اعمال این تغییرات، سایت خود را باز کنید.
- آدرس نسخه غلط را تایپ کنید (مثلاً با www).
- باید به صورت خودکار به نسخه صحیح (بدون www) منتقل شوید.
- از ابزارهایی مثل Redirect Checker استفاده کنید تا مطمئن شوید که کد وضعیت دقیقاً 301 است (نه 302 یا 307).
وضعیت تنظیم دامنه ترجیحی در سرچ کنسول جدید گوگل (GSC)
در نسخه کلاسیک سرچ کنسول، در بخش Site Settings، گزینهای وجود داشت که صراحتاً از شما میپرسید: “Don’t set a preferred domain” یا بین www و non-www یکی را انتخاب کنید.
اما در سرچ کنسول جدید، اگر تمام منوها را زیر و رو کنید، این گزینه را نخواهید یافت. گوگل این تنظیم دستی را در سال ۲۰۱۹ به طور کامل حذف کرد. این تغییر برای بسیاری گیجکننده بود، اما در پسِ آن یک منطق فنی هوشمندانه نهفته است.
تغییرات گوگل: چرا گزینه Preferred Domain حذف شد؟
گوگل تصمیم گرفت مسئولیت این انتخاب را از دوش کاربر (که ممکن بود خطا کند) بردارد و آن را به الگوریتمهای هوشمند خود بسپارد. دلایل اصلی این تغییر عبارتند از:
- تکیه بر سیگنالهای واقعی (Actual Signals): گوگل اعلام کرد که به جای تکیه بر یک “دکمه تنظیمات” در پنل، به سیگنالهای فنی که شما در سایت پیاده کردهاید احترام میگذارد. یعنی همان ریدایرکتهای ۳۰۱ و تگهای Canonical که در بخش قبل تنظیم کردیم.
- جلوگیری از تناقض: در گذشته بسیار پیش میآمد که مدیر سایت در فایل .htaccess ریدایرکت را روی non-www تنظیم کرده بود، اما در سرچ کنسول به اشتباه گزینه www را تیک میزد. این تناقض باعث سردرگمی رباتهای گوگل میشد. با حذف این گزینه، گوگل حالا مستقیماً “واقعیت سایت” را میبیند، نه “ادعای مدیر سایت” را.
- هوشمندتر شدن الگوریتم: گوگل اکنون توانایی تشخیص الگوی لینکسازی داخلی، سایتمپ (Sitemap) و بکلینکهای خارجی را دارد و بر اساس تجمیع این اطلاعات، نسخه اصلی (Canonical) را با دقت بسیار بالا شناسایی میکند.
نکته کلیدی: سرچ کنسول دیگر ابزاری برای “تعیین” دامنه ترجیحی نیست، بلکه ابزاری برای “رصد” آن است. شما ترجیح خود را روی سرور (Server-Side) اعمال میکنید و گوگل آن را میپذیرد.
نحوه معرفی نسخه اصلی به گوگل در حال حاضر (Site Verification)
با حذف آن دکمه، استراتژی ما برای ثبت سایت در سرچ کنسول باید تغییر کند. ما اکنون دو روش برای ثبت سایت داریم که روش اول (Domain Property) اکیداً توصیه میشود.
۱. استفاده از Domain Property (روش حرفهای و پیشنهادی)
این بهترین روش برای مدیریت یکپارچگی دامنه است.
- چگونه کار میکند؟ شما فقط نام دامنه ریشه (مثلاً com بدون هیچ پروتکل یا پیشوندی) را وارد میکنید.
- مزیت حیاتی: گوگل به صورت خودکار تمام نسخههای سایت شما را تجمیع میکند (http, https, www, non-www).
- چرا عالی است؟ با این روش، شما نگران این نیستید که ترافیک روی کدام نسخه افتاده است. گوگل تمام دادهها را یکجا به شما نشان میدهد. این یعنی شما یک تصویر کامل (Holistic View) از عملکرد سایت خود دارید.
- روش تأیید: نیاز به ثبت یک رکورد DNS (متن TXT) در پنل هاستینگ دامنه دارد.
۲. استفاده از URL Prefix (روش سنتی)
اگر به هر دلیلی (مثل عدم دسترسی به DNS) نمیتوانید از روش اول استفاده کنید، باید از این روش استفاده کنید.
- قانون مهم: در این روش، شما باید دقیقاً همان نسخهای را ثبت کنید که به عنوان دامنه ترجیحی انتخاب کردهاید و ریدایرکتها به سمت آن میروند.
- مثال: اگر سایت شما روی https://vazirseo.com باز میشود (با SSL و بدون www)، باید دقیقاً همین آدرس را ثبت کنید. اگر http://vazirseo.com را ثبت کنید، آمارها را صفر یا ناقص خواهید دید.
نتیجهگیری اجرایی: دیگر دنبال دکمه تنظیمات نگردید.
- ریدایرکت ۳۰۱ و تگ Canonical را روی سایت (توسط دولوپر یا خودتان) فیکس کنید.
- سایت را ترجیحاً از طریق Domain Property در سرچ کنسول ثبت کنید.
- چند روز صبر کنید؛ گوگل خودکار نسخه صحیح را به عنوان نسخه اصلی ایندکس خواهد کرد.
اشتباهات مهلک در مهاجرت بین www و non-www
تغییر پیشوند دامنه، شاید در ظاهر ساده باشد، اما در باطن یک جراحی روی سیستم عصبی سایت است. اگر مسیرهای ارتباطی (لینکها و ریدایرکتها) را درست ترمیم نکنید، گوگل و کاربر هر دو گمراه خواهند شد.
خطای زنجیرههای ریدایرکت (Redirect Chains) و کاهش سرعت سایت
خطرناکترین قاتل خاموش در این پروسه، ایجاد ناخواسته “زنجیره ریدایرکت” است. بسیاری از مدیران سایت، ریدایرکتها را به صورت لایهلایه اضافه میکنند بدون اینکه قبلیها را اصلاح کنند.
- سناریوی فاجعه: فرض کنید شما دامنه را از http://example.com (بدون SSL و بدون www) به https://www.example.com (امن و با www) منتقل کردهاید.
- مسیر اشتباه (زنجیره): کاربر آدرس قدیمی را تایپ میکند -> سرور او را به https://example.com میفرستد (ریدایرکت ۱) -> سپس سرور او را به https://www.example.com میفرستد (ریدایرکت ۲).
- چرا این بد است؟ هر ریدایرکت یعنی یک رفتوبرگشت (Round Trip) اضافه به سرور. این کار زمان تاخیر (Latency) را به شدت افزایش میدهد و سرعت بارگذاری را میکشد. همچنین، ربات گوگل (Googlebot) ممکن است پس از چند پرش، خزش را متوقف کند و بودجه خزش (Crawl Budget) شما هدر برود.
راهکار اجرایی: ریدایرکت باید مستقیم باشد. کد .htaccess یا تنظیمات سرور شما باید به گونهای نوشته شود که هر درخواستی (از هر نسخه غلطی) را یکضرب به مقصد نهایی (https://www.example.com) پرتاب کند. از ابزارهایی مثل “Redirect Path” در کروم استفاده کنید تا مطمئن شوید کد وضعیت 301 فقط یک بار صادر میشود.
فراموشی بهروزرسانی نقشه سایت (Sitemap) و فایل Robots.txt
شما ساختار را عوض کردهاید، اما آیا نقشه راه را هم بهروز کردهاید؟ یکی از اشتباهات رایج، ارسال سیگنالهای متناقض به گوگل است.
- مشکل سایتمپ: اگر در فایل xml هنوز آدرسهای قدیمی (مثلاً نسخه بدون www) وجود داشته باشد، شما عملاً به گوگل میگویید: “لطفاً این آدرسهای قدیمی را ایندکس کن”. گوگل به آنجا میرود و با ریدایرکت مواجه میشود. این تناقض باعث میشود گوگل در شناخت نسخه اصلی (Canonical) دچار تردید شود.
- مشکل txt: گاهی اوقات قوانین فایل robots.txt برای نسخه جدید بهدرستی تنظیم نشده است یا سهواً دسترسی رباتها به زیردامنهی جدید محدود شده است.
اقدام فوری: ۱. بلافاصله پس از تغییر، سایتمپ خود را بازتولید کنید تا تمام لینکها با فرمت نهایی و جدید باشند. ۲. سایتمپ قدیمی را از سرچ کنسول حذف و نسخه جدید را ثبت کنید. ۳. فایل Robots.txt را چک کنید تا مطمئن شوید نسخه نهایی مسدود (Disallow) نشده باشد.
مشکل گواهی SSL در هنگام تغییر ساختار آدرس
این یک نکته بسیار فنی و ظریف است که اغلب نادیده گرفته میشود: دست دادن (Handshake) امنیتی قبل از ریدایرکت اتفاق میافتد.
- سناریوی خطا: فرض کنید دامنه اصلی شما example.com است و شما فقط برای همین نسخه گواهی SSL تهیه کردهاید.
- مشکل: اگر کاربری https://example.com (نسخه امن اما بدون www) را تایپ کند، قبل از اینکه سرور فرصت کند او را ریدایرکت کند، مرورگر سعی میکند گواهی SSL را چک کند. چون گواهی شما فقط برای www صادر شده، مرورگر خطای ترسناک “This connection is not private” را به کاربر نشان میدهد و کاربر فرار میکند. ریدایرکت هرگز اتفاق نمیافتد!
راهکار اجرایی: شما باید مطمئن شوید گواهی SSL شما هر دو نسخه را پوشش میدهد. ۱. استفاده از Wildcard SSL (که تمام زیردامنهها *.example.com را پوشش میدهد). ۲. یا استفاده از گواهینامهای که در بخش SAN (Subject Alternative Name)، نام دامنه ریشه (example.com) را هم شامل شود. بدون این کار، نیمی از ترافیک شما قبل از رسیدن به سایت، پشت دیوار امنیتی متوقف میشود.
ما تمامی جنبههای فنی، استراتژیک و خطرات احتمالی انتخاب دامنه (www vs non-www) را پوشش دادیم. اکنون زیرساخت سایت شما برای یک عملکرد بینقص آماده است.
جمعبندی و نتیجهگیری (Conclusion)
در نهایت، جنگ میان www و non-www برندهای مطلق ندارد؛ برنده واقعی کسی است که ثبات داشته باشد. گوگل تبعیضی بین این دو قائل نیست، اما بینظمی را به شدت جریمه میکند. ما در این مقاله آموختیم که سایتهای بزرگ با ترافیک سنگین بهتر است از ساختار www برای مدیریت بهتر DNS و کوکیها استفاده کنند، در حالی که کسبوکارهای مدرن میتوانند از سادگی دامنه بدون پیشوند (Naked Domain) بهره ببرند.
اقدام نهایی شما: همین حالا آدرس سایت خود را با و بدون www چک کنید. اگر هر دو باز میشوند، شما در حال آسیب زدن به سئوی خود هستید. طبق آموزشهای داده شده، ریدایرکت ۳۰۱ را فعال کنید و نسخه واحد خود را در سرچ کنسول تثبیت نمایید. یکپارچگی، کلید قدرت دامنه شماست.