راهنمای ساخت زیردامنه آزمایشی و جلوگیری از ایندکس شدن

سایت اصلی‌تان بالا است، مشتری‌ها در حال خریدند، و شما نمی‌توانید ریسک کنید که یک افزونهٔ جدید را مستقیم روی همان نسخهٔ production تست کنید. پس یک زیردامنه می‌سازید: test.example.com. نیم ساعت بعد متوجه می‌شوید گوگل همان صفحهٔ تست را ایندکس کرده، فرم تماس سایت تست ایمیل واقعی می‌فرستد، و لینک‌های داخلی نسخهٔ تست به دامنهٔ اصلی اشاره می‌کنند. این مقاله دقیقاً دربارهٔ همین سه درد است.

زیردامنه آزمایشی را کجا بسازیم: DNS یا پنل هاست

اولین تصمیم این است که رکورد DNS را خودتان بسازید یا اجازه دهید پنل هاست این کار را بکند. اگر دامنه روی همان سروری است که هاست روی آن است، پنل معمولاً یک رکورد A خودکار اضافه می‌کند و کار تمام است. اگر DNS را جای دیگری مدیریت می‌کنید، باید دستی اضافه کنید:

test.example.com.    3600    IN    A    203.0.113.45
www.test.example.com. 3600   IN    CNAME    test.example.com.

عدد 3600 همان TTL است، یعنی یک ساعت. برای زیردامنهٔ آزمایشی این عدد را پایین بیاورید؛ 300 یعنی پنج دقیقه. دلیلش ساده است: وقتی بعداً IP را عوض می‌کنید یا زیردامنه را پاک می‌کنید، نمی‌خواهید یک ساعت منتظر بمانید تا کش DNS در سراسر دنیا پاک شود. اگر مطمئن نیستید رکورد درست منتشر شده یا نه، از بررسی DNS و شبکه استفاده کنید و مقدار برگشتی را با آنچه در پنل نوشته‌اید مقایسه کنید.

نکته‌ای که خیلی‌ها را زمین می‌زند: زیردامنه در DNS ساخته می‌شود، اما وب‌سرور هم باید بداند این دامنه را سرو کند. اگر فقط رکورد A بسازید و در پنل هاست دامنه را اضافه نکنید، مرورگر صفحهٔ پیش‌فرض سرور یا خطای ۴۰۴ می‌گیرد. ترتیب درست این است: اول دامنه را در پنل اضافه کنید، بعد رکورد DNS را تنظیم کنید.

جلوگیری از ایندکس شدن زیردامنه آزمایشی

این مهم‌ترین بخش است و بیشترین اشتباه هم همین‌جا رخ می‌دهد. یک زیردامنهٔ تست که ایندکس شود، می‌تواند محتوای تکراری تولید کند و در بدترین حالت، نسخهٔ تست را جای نسخهٔ اصلی در نتایج نشان دهد. سه لایه محافظت وجود دارد و من هر سه را همزمان می‌گذارم.

لایهٔ اول: هدر X-Robots-Tag

این هدر روی هر پاسخی که وب‌سرور می‌دهد سوار می‌شود، حتی فایل‌های PDF و تصاویر که راهی برای گذاشتن متا تگ ندارند. در فایل .htaccess ریشهٔ زیردامنه:

Header set X-Robots-Tag "noindex, nofollow, noarchive"

اگر ماژول mod_headers فعال نباشد، این خط بی‌صدا نادیده گرفته می‌شود. تست کنید: curl -I https://test.example.com و ببینید هدر در خروجی هست یا نه. نبودنش را با چشم غیرمسلح نمی‌بینید، فقط گوگل می‌بیند.

لایهٔ دوم: robots.txt

User-agent: *
Disallow: /

این فایل جلوی خزش را می‌گیرد، اما جلوی ایندکس شدن را نه. اگر جایی به صفحهٔ تست لینک داده باشد، گوگل می‌تواند بدون خزش هم آن را ایندکس کند. به همین دلیل robots.txt به‌تنهایی کافی نیست و باید با هدر noindex ترکیب شود. اگر می‌خواهید فهرست کامل دستورات را ببینید، مرجع کامل دستورات htaccess برای هاست لینوکس همهٔ گزینه‌ها را با مثال توضیح داده.

لایهٔ سوم: احراز هویت HTTP

اگر می‌خواهید هیچ رباتی حتی به صفحهٔ لاگین نرسد، کل زیردامنه را پشت رمز بگذارید:

AuthType Basic
AuthName "Staging"
AuthUserFile /home/user/.htpasswd
Require valid-user

هزینه‌اش این است که خودتان هم هر بار باید رمز بزنید و ابزارهایی مثل PageSpeed Insights دیگر نمی‌توانند صفحه را تحلیل کنند. برای تست‌های سریع این آزاردهنده است. من معمولاً لایهٔ اول و دوم را همیشه می‌گذارم و لایهٔ سوم را فقط وقتی فعال می‌کنم که مشتری واقعی روی نسخهٔ تست کار کند.

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

همگام‌سازی زیردامنه آزمایشی با سایت اصلی

بعد از اینکه زیردامنه ساخته شد و از دید گوگل پنهان ماند، سؤال بعدی این است: چطور محتوای production را بیاوریم روی تست، بدون اینکه چیزی خراب شود؟

دیتابیس

یک دیتابیس جدا بسازید، نه اینکه به دیتابیس اصلی وصل شوید. اگر wp-config.php نسخهٔ تست به دیتابیس production اشاره کند، اولین تست افزونه می‌تواند جدول‌های واقعی را تغییر دهد. برای ساخت دیتابیس و کاربر، ساخت دیتابیس و اتصال آن به سایت مراحل را قدم‌به‌قدم گفته.

برای انتقال، dump بگیرید و ایمپورت کنید. اگر حجم دیتابیس بالای چند صد مگابایت است، ایمپورت ساده از phpMyAdmin معمولاً با خطای timeout می‌خورد. روش درست را در ایمپورت SQL بزرگ بدون تایم‌اوت و خطا توضیح داده‌ایم.

بعد از ایمپورت، آدرس‌ها را جایگزین کنید. یک sed ساده کافی است:

sed -i 's|https://example.com|https://test.example.com|g' dump.sql

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

فایل‌ها و مجوزها

فایل‌ها را با rsync کپی کنید، نه با cp -r. دلیلش این است که rsync فقط تفاوت‌ها را منتقل می‌کند و بار دوم که می‌خواهید تست را به‌روز کنید، چند ثانیه طول می‌کشد نه چند دقیقه:

rsync -avz --exclude='wp-content/cache' /var/www/main/ /var/www/test/

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

کارهای زمان‌بندی‌شده و ایمیل

این دو مورد را همه فراموش می‌کنند. اگر cron سایت اصلی روی زیردامنه هم کپی شده باشد، دو نسخه از یک اسکریپت همزمان اجرا می‌شوند و ممکن است یک رکورد را دو بار ثبت کنند. کرون‌های زیردامنه را غیرفعال کنید یا زمان‌بندی‌شان را به ساعاتی ببرید که تداخل نداشته باشد. نحو درست فیلدها را در نحو کرون: مرجع کامل پنج فیلد داریم.

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

کدام روش را انتخاب کنم؟

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

یک محدودیت دیگر هم هست که کمتر گفته می‌شود: اگر سایت اصلی ترافیک بالایی داشته باشد، زیردامنهٔ تست روی همان هاست می‌تواند در ساعات اوج، TTFB سایت اصلی را بالا ببرد. اگر بعد از ساخت زیردامنه دیدید سایت اصلی کند شده، احتمالاً همین است.

پرسش‌های پرتکرار

آیا زیردامنه آزمایشی روی سرچ گوگل تأثیر می‌گذارد؟

اگر هدر noindex و robots.txt را درست تنظیم کنید، نه. مشکل وقتی پیش می‌آید که فقط یکی از این دو را بگذارید یا فایل robots.txt فیزیکی توسط وردپرس نادیده گرفته شود. بعد از راه‌اندازی، با جستجوی site:test.example.com در گوگل چک کنید که هیچ صفحه‌ای ایندکس نشده باشد.

چرا زیردامنه‌ام بعد از ساخت رکورد DNS باز نمی‌شود؟

در بیشتر موارد چون دامنه در پنل هاست اضافه نشده است. رکورد DNS فقط ترافیک را به IP سرور می‌رساند؛ این وب‌سرور است که باید بداند کدام پوشه را برای آن دامنه سرو کند. ترتیب درست: اول دامنه در پنل، بعد رکورد DNS. اگر هر دو درست بود، با ابزار بررسی DNS مقدار رکورد را چک کنید.

چطور بفهمم زیردامنه تست به دیتابیس اصلی وصل نشده؟

فایل wp-config.php نسخهٔ تست را باز کنید و مقدار DB_NAME را ببینید. اگر با دیتابیس اصلی یکی است، همین حالا عوضش کنید. یک راه سریع‌تر: در phpMyAdmin هر دو دیتابیس را باز کنید و ببینید آیا جدول‌های یکسانی با تعداد رکورد یکسان دارند یا نه.

بعد از پایان تست، زیردامنه را چطور پاک کنم؟

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

قبل از اینکه دست به production بزنید، زیردامنه را بسازید و همان روز سه لایهٔ محافظت را بگذارید. بعداً اضافه کردنشان سخت نیست، اما یادتان رفتنشان گران تمام می‌شود.