سایت‌تان برای قطعی اینترنت چقدر آماده است؟ چک‌لیست ۱۵ دقیقه‌ای + نمره‌ی آمادگی

اگر سایت وردپرسی‌تان در روزهای اختلال اینترنت بین‌الملل بدون ظاهر و تصویر باز می‌شود، یا پیشخوانش بی‌نهایت می‌چرخد و جواب نمی‌دهد، احتمالاً چک لیست آماده‌ سازی سایت برای قطعی اینترنت را بررسی نکرده اید!

مشکل از چیزی است که کمتر دیده می‌شود: وابستگی‌های خارجی.

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

وقتی اختلال پیش می‌آید، هرکدام تبدیل به یک نقطه‌ی خرابی می‌شود.

در این راهنما نشان می‌دهیم این وابستگی‌ها را چطور پیدا کنید و هرکدام را چطور رفع کنید. بررسی همه‌ی موارد چک‌لیست حدود ۱۵ دقیقه طول می‌کشد؛ رفع هر مورد البته زمان خودش را دارد.

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

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

وقتی اینترنت بین‌الملل قطع می‌شود، سایت ایرانی دقیقاً چه می‌شود؟

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

نوع اول: خرابی ظاهری

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

نوع دوم: خرابی نامرئی در سمت سرور

این نوع را با چشم نمی‌بینید. خود وردپرس و افزونه‌ها در پس‌زمینه به سرویس‌های خارجی درخواست می‌زنند: بررسی آپدیت، تأیید لایسنس، ارسال داده‌ی تله‌متری، صدا زدن API.

اگر آن سرور جواب ندهد، درخواست تا پایان زمان انتظار (timeout) باز می‌ماند و تا آن موقع سایت یا پیشخوان شما منتظر است. نتیجه‌اش همان پیشخوانی است که انگار قفل شده، یا صفحه‌ای که بعد از چند ده ثانیه بالا می‌آید.

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

نوع سوم: خرابی زیرساختی

اینجا پای DNS، ثبت‌کننده‌ی دامنه و گواهی SSL در میان است. اگر کاربری از DNS عمومی خارجی مثل 8.8.8.8 یا 1.1.1.1 استفاده کند و آن‌ها در اختلال در دسترس نباشند، ممکن است حتی سایت‌های ایرانی هم برایش باز نشود.

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

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

این پرسش را زیاد می‌شنویم. هاست ایران فقط یک چیز را تضمین می‌کند: سرور شما از داخل کشور در دسترس است.

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

پیش از شروع: وابستگی‌های خارجی را چطور پیدا کنیم؟ (۵ دقیقه)

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

روش اول: تب Network مرورگر

1. صفحه‌ی اصلی سایت را در Chrome یا مرورگر مشابه باز کنید و کلید F12 را بزنید.
2. به تب Network بروید و گزینه‌ی Disable cache را فعال کنید.
3. صفحه را دوباره بارگذاری کنید (Ctrl+Shift+R).
4. روی سربرگ ستون‌ها راست‌کلیک کنید و ستون Domain را فعال کنید، بعد روی آن کلیک کنید تا لیست بر اساس دامنه مرتب شود.
5. هر دامنه‌ای که دامنه‌ی خودتان نیست، یک وابستگی خارجی است. اسم‌هایی مثل این‌ها را یادداشت کنید:

fonts.googleapis.com
fonts.gstatic.com
cdnjs.cloudflare.com
www.googletagmanager.com
secure.gravatar.com

همین کار را روی یک مقاله، یک صفحه‌ی محصول و صفحه‌ی تماس هم تکرار کنید. هر صفحه ممکن است اسکریپت متفاوتی بارگذاری کند.

روش دوم: جست‌وجو در سورس صفحه و فایل‌های CSS

با Ctrl+U سورس صفحه را باز کنید و با Ctrl+F دنبال https:// بگردید. هر آدرسی که به دامنه‌ی شما نمی‌خورد، مشکوک است.

یک نکته‌ی تخصصی: بعضی فونت‌ها اصلاً در HTML دیده نمی‌شوند و از داخل فایل CSS قالب یا افزونه، با دستور @importوارد می‌شوند. فایل‌های CSS اصلی را هم باز کنید و همین عبارت را در آن‌ها جست‌وجو کنید.

روش سوم: پیدا کردن درخواست‌های سمت سرور با Query Monitor

برای خرابی نوع دوم، افزونه‌ی رایگان Query Monitor را نصب کنید (ترجیحاً روی نسخه‌ی تست، یا فقط برای مدت بررسی). بعد از فعال‌سازی، در نوار بالای سایت منوی آن ظاهر می‌شود.

بخش HTTP API Calls فهرست درخواست‌هایی را نشان می‌دهد که وردپرس به سرورهای دیگر فرستاده، همراه با زمان پاسخ و خطا. هر درخواستی که طولانی یا ناموفق است، یک وابستگی خارجی است که در اختلال سایت را معطل می‌کند. بعد از پایان بررسی، افزونه را غیرفعال کنید.

چک‌لیست ۱۵ دقیقه‌ای آماده‌ سازی سایت برای قطعی اینترنت و وابستگی‌های خارجی

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

الف) منابع فرانت‌اند: فونت، اسکریپت و آیکون

فونت‌ها را محلی کنید

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

راه‌حل: فایل فونت را دانلود کنید، در پوشه‌ی wp-content/uploads/fonts/ بگذارید و با @font-face به آن وصل کنید. مثال با فونت فارسی Vazirmatn:

@font-face {
  font-family: "Vazirmatn";
  src: url("/wp-content/uploads/fonts/vazirmatn-regular.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

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

بعد از تغییر، دوباره تب Network را نگاه کنید تا مطمئن شوید درخواستی به fonts.googleapis.com نمی‌رود.

اسکریپت‌ها و آیکون‌های CDN را محلی کنید

بعضی افزونه‌ها کتابخانه‌هایی مثل Font Awesome، اسلایدرها یا ماژول‌های جاوااسکریپت را از CDN خارجی (مثل cdnjs.cloudflare.com یا cdn.jsdelivr.net) می‌آورند. علامت خرابی: دکمه‌ها، آیکون‌ها یا اسلایدر کار نمی‌کنند و به‌جای آیکون، کادر خالی می‌بینید.

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

ب) کپچا، ردیابی و Gravatar

کپچا: reCAPTCHA گوگل برای کار کردن باید با سرورهای گوگل حرف بزند. در اختلال یا فرم باز نمی‌شود یا کاربر نمی‌تواند ارسال کند. راه‌حل، جایگزین محلی است، مثل کپچای سؤال ساده، تصویر ساخته‌شده روی خود سرور یا honeypot.

صادق باشیم: این‌ها از reCAPTCHA ضعیف‌ترند. بهتر است با محدودکردن تعداد ارسال از یک IP ترکیبشان کنید. حذف reCAPTCHA بدون جایگزین، فرم را در برابر اسپم بی‌دفاع می‌کند.

Analytics، Tag Manager و چت آنلاین خارجی: این اسکریپت‌ها معمولاً غیرحیاتی‌اند، ولی اگر هم‌زمان (synchronous) بارگذاری شوند، می‌توانند نمایش کل صفحه را عقب بیندازند. مطمئن شوید با async یا defer لود می‌شوند.

اگر آمار برایتان مهم است و می‌خواهید در اختلال هم داده‌ای از دست ندهید، یک ابزار تحلیل خودمیزبان مثل Matomo را می‌توانید روی یک سرور مجازی ایران راه بیندازید.

Gravatar: آواتار نویسنده‌ها و کامنت‌گذارها به‌صورت پیش‌فرض از secure.gravatar.com می‌آید. ما برای عکس نویسنده‌ی همین وبلاگ هم همین کار را کردیم: عکس را مستقیم در کتابخانه‌ی رسانه آپلود کردیم و نمایش آواتار Gravatar را از «تنظیمات ← گفتگو» غیرفعال کردیم.

بعد از آن، در تب Network هیچ درخواستی به Gravatar باقی نماند.

پ) درخواست‌های نامرئی سمت سرور وردپرس

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

معمولاً سه دسته‌اند: بررسی آپدیت، تأیید لایسنس، و API خود افزونه‌ها (مثلاً ابزارهای هوش مصنوعی یا نرخ ارز).

راه‌حل حرفه‌ای این است که در اختلال، به‌جای اینکه این درخواست‌ها تا پایان timeout معطل بمانند، فوراً شکست بخورند. وردپرس برای همین ثابتی به نام WP_HTTP_BLOCK_EXTERNAL دارد که در فایل wp-config.php قرار می‌گیرد:

define( 'WP_HTTP_BLOCK_EXTERNAL', true );

با این خط، وردپرس درخواست به هر هاستی غیر از خود سایت را رد می‌کند و دیگر منتظر جواب نمی‌ماند. اما دو هشدار جدی دارد:

• آپدیت افزونه‌ها، قالب و هسته هم متوقف می‌شود، چون آن‌ها هم درخواست خارجی‌اند.
• سرویس‌های ایرانی هم «خارجی» حساب می‌شوند. اگر درگاه پرداخت، پنل پیامک یا هر API داخلی دیگری دارید، باید آدرسشان را با ثابت دیگری مجاز کنید.

این ثابت دیگر WP_ACCESSIBLE_HOSTS است:

define( 'WP_ACCESSIBLE_HOSTS', 'api.your-gateway.ir,sms.your-panel.ir' );

پیشنهاد ما این است که اول روی نسخه‌ی تست امتحانش کنید و پیش از هر تغییری در wp-config.php بکاپ بگیرید. بعد از پایان اختلال هم خط را بردارید تا آپدیت‌ها دوباره کار کنند.

توضیح رسمی این ثابت‌ها در مستندات وردپرس درباره‌ی wp-config.php هست.

WP-Cron را با کرون واقعی سرور عوض کنید

وردپرس کارهای زمان‌بندی‌شده‌اش (انتشار زمان‌بندی‌شده، بکاپ، بررسی آپدیت، ارسال ایمیل صف‌بندی‌شده) را با WP-Cron انجام می‌دهد؛ مکانیزمی که با بازدید کاربران فعال می‌شود. اگر یکی از وظایف به سرور خارجی وصل باشد و گیر کند، می‌تواند بقیه‌ی کارها را هم معطل کند.

روش بهتر این است که WP-Cron را خاموش کنید و یک کرون واقعی روی سرور بگذارید. اول ثابت DISABLE_WP_CRON را در wp-config.php فعال کنید:

define( 'DISABLE_WP_CRON', true );

بعد در بخش Cron Jobs پنل هاست، فایل wp-cron.php را هر ۵ دقیقه اجرا کنید:

*/5 * * * * php /home/USERNAME/public_html/wp-cron.php

مسیر PHP و پوشه‌ی سایت در هر هاست فرق می‌کند؛ مقدار دقیقش را از پنل یا پشتیبانی هاستتان بگیرید.

لایسنس و فایل‌های نصبی افزونه‌ها

افزونه‌ها و قالب‌های پولی معمولاً برای فعال ماندن لایسنس یا دریافت آپدیت به سرور سازنده وصل می‌شوند. رفتارشان بدون اینترنت جهانی یکسان نیست: بعضی فقط یک اخطار نشان می‌دهند و بعضی بخشی از امکانات را قفل می‌کنند.

ما دو کار توصیه می‌کنیم:

• روی نسخه‌ی تست با WP_HTTP_BLOCK_EXTERNAL ببینید هر افزونه‌ی پولی چه واکنشی نشان می‌دهد.
• فایل‌های نصبی (zip) همه‌ی افزونه‌ها و قالب‌ها را همین حالا روی یک حافظه‌ی محلی نگه دارید. در اختلال نمی‌توانید دوباره از سایت سازنده دانلودشان کنید.

ت) ایمیل، درگاه پرداخت و وب‌هوک‌ها

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

ایمیل‌های سایت

ایمیل‌های سایت (فرم تماس، تأیید سفارش، بازیابی رمز) اگر از طریق یک SMTP خارجی بروند، در اختلال ارسال نمی‌شوند و کاربر هم خطایی نمی‌بیند.

چطور بفهمیم: وارد تنظیمات افزونه‌ی SMTP سایت شوید (مثلاً WP Mail SMTP یا FluentSMTP) و آدرس سرور (Host) را ببینید. اگر یکی از این‌هاست، ارسال ایمیل شما به سرویس خارجی وابسته است:

smtp.gmail.com
smtp.sendgrid.net
smtp.mailgun.org

اگر اصلاً افزونه‌ی SMTP ندارید، وردپرس ایمیل‌ها را با سرویس ایمیل خود هاست می‌فرستد و از این نظر وابستگی خارجی ندارید.

راه‌حل: یک صندوق ایمیل روی خود هاست بسازید (مثلاً noreply@yourdomain.com) و آدرس سرور، پورت، نام کاربری و رمز همان صندوق را در افزونه‌ی SMTP وارد کنید. این مشخصات در cPanel، بخش Email Accounts، گزینه‌ی Connect Devices دیده می‌شود؛ اسم گزینه در نسخه‌های مختلف کمی فرق می‌کند.

برای اینکه ایمیل‌ها به پوشه‌ی اسپم نروند، در بخش Email Deliverability همان cPanel بررسی کنید رکوردهای SPF و DKIM دامنه درست باشند. بعد با دکمه‌ی ایمیل آزمایشی افزونه، یک ایمیل به یک آدرس داخلی بفرستید و پوشه‌ی اسپم را هم نگاه کنید.

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

درگاه پرداخت و افزونه‌های جانبی ووکامرس

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

چطور بفهمیم: اختلال را روی نسخه‌ی تست شبیه‌سازی کنید. ثابت WP_HTTP_BLOCK_EXTERNAL را که در بخش قبل گفتیم فعال کنید و آدرس درگاه پرداخت را با WP_ACCESSIBLE_HOSTS مجاز کنید. بعد یک سفارش آزمایشی کامل ثبت کنید: افزودن به سبد، محاسبه‌ی ارسال، پرداخت و ایمیل تأیید.

هر مرحله‌ای که کند شد یا خطا داد، یک وابستگی خارجی است. خطاها را در مسیر WooCommerce ← Status ← Logs هم می‌توانید ببینید.

راه‌حل: برای هر مورد، حالت دستی یا آفلاین را فعال کنید:

• تبدیل ارز: نرخ ارز را به‌جای دریافت خودکار از API خارجی، دستی تنظیم کنید یا از یک منبع داخلی بگیرید.
• هزینه‌ی ارسال: به‌جای محاسبه‌ی زنده از سرویس خارجی، روش Flat rate یا هزینه‌ی ثابت ووکامرس را بگذارید.
• مالیات و اعتبارسنجی آدرس: اگر اجباری نیستند، در اختلال غیرفعالشان کنید.
• افزونه‌ای که حالت آفلاین ندارد: جایگزین داخلی پیدا کنید یا پیش از اختلال خاموشش کنید. قاعده‌ی کلی این است که تسویه‌ی سبد خرید نباید به یک API خارجی وابسته باشد.

درگاه پرداخت را هم یک بار آزمایش کنید. اگر درگاهتان حالت آزمایشی دارد، یک تراکنش آزمایشی انجام دهید و مطمئن شوید بازگشت به سایت (callback) درست کار می‌کند.

وب‌هوک‌ها

وب‌هوک یعنی یک سرویس به‌محض وقوع رویداد (مثلاً ثبت سفارش) به یک آدرس پیام بفرستد. در اختلال دو حالت پیش می‌آید: وب‌هوک‌هایی که سایت شما به بیرون می‌فرستد به مقصد نمی‌رسند، و وب‌هوک‌هایی که از سرویس خارجی به سایت شما می‌آیند هم نمی‌رسند.

چطور بفهمیم: در ووکامرس به مسیر WooCommerce ← Settings ← Advanced ← Webhooks بروید و ستون آدرس تحویل (Delivery URL) را ببینید. هر آدرس خارجی، یک وابستگی است. برای وب‌هوک‌های ورودی هم فهرستی از سرویس‌هایی بنویسید که به سایت شما پیام می‌فرستند، مثل CRM، ربات یا ابزار اتوماسیون.

راه‌حل: اگر می‌شود، مقصد وب‌هوک‌های خروجی را به سرویسی روی سرور داخلی ببرید؛ مثلاً ابزار اتوماسیونی که خودتان روی یک سرور مجازی ایران نصب کرده‌اید. برای ورودی‌ها بررسی کنید سرویس مبدأ در صورت شکست دوباره تلاش می‌کند یا نه، و کار حیاتی مثل تأیید پرداخت را فقط به یک وب‌هوک خارجی وابسته نکنید.

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

ث) دامنه، DNS و SSL

DNS: اول ببینید نیم‌سرورهای دامنه‌تان کجایند. در Command Prompt یا ترمینال این دستور را بزنید و به‌جای yourdomain.com دامنه‌ی خودتان را بگذارید:

nslookup -type=NS yourdomain.com

اگر نیم‌سرورها مال یک سرویس خارجی بودند (مثل Cloudflare)، لزوماً بد نیست، اما رفتارش در اختلال باید برایتان روشن باشد. ممکن است دسترسی کاربران داخل کشور به این نیم‌سرورها مختل شود.

اگر می‌خواهید DNS را به نیم‌سرورهای هاست یا یک سرویس DNS ایرانی ببرید، این ترتیب را رعایت کنید:

1. همه‌ی رکوردهای فعلی (A، MX، TXT و…) را یادداشت کنید.
2. همان رکوردها را در DNS جدید بسازید و رکوردهای ایمیل (MX) را فراموش نکنید.
3. یک روز قبل از تغییر، TTL رکوردها را پایین بیاورید (مثلاً ۳۰۰ ثانیه).
4. نیم‌سرورها را در پنل ثبت‌کننده‌ی دامنه عوض کنید.
5. با همان دستور nslookup، باز کردن سایت و یک ایمیل آزمایشی مطمئن شوید همه‌چیز سر جایش است.

این کار را حتماً پیش از اختلال انجام دهید، چون بعدش شاید به پنل ثبت‌کننده دسترسی نداشته باشید. اگر از Cloudflare به‌عنوان CDN استفاده می‌کنید، با انتقال DNS آن را هم از دست می‌دهید؛ این یک داد و ستد است و باید آگاهانه تصمیم بگیرید.

گواهی SSL اگر در اختلال تمام شود چه می‌شود؟

گواهی‌های رایگان Let’s Encrypt معمولاً حدود ۹۰ روز اعتبار دارند و تمدیدشان به‌صورت خودکار انجام می‌شود. برای تمدید، مرجع صادرکننده باید از بیرون به سایت شما وصل شود و دامنه را تأیید کند. اگر در زمان اختلال این ارتباط برقرار نباشد، تمدید انجام نمی‌شود.

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

اگر میزبان شما چنین امکانی ندارد، تاریخ انقضای گواهی را همین حالا از مرورگر (قفل کنار آدرس ← جزئیات گواهی) ببینید. اگر نزدیک است، پیش از اختلال تمدیدش کنید و از میزبانتان بپرسید فرایند تمدید در اختلال چطور انجام می‌شود.

ج) بکاپ و دسترسی مدیریتی

بکاپی که فقط روی همان سرور باشد، بکاپ حساب نمی‌شود. یک نسخه‌ی کامل از پایگاه داده و پوشه‌ی wp-content را روی یک حافظه‌ی محلی یا سرور داخلی جدا نگه دارید و یک بار بازیابی‌اش را روی نسخه‌ی تست امتحان کنید.

بکاپی که هیچ‌وقت بازیابی نشده، یک فرضیه است.

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

یک اپلیکیشن تأیید دومرحله‌ی آفلاین (مبتنی بر TOTP) و یک ایمیل ادمین روی سرویس داخلی، این خطر را کم می‌کند. کدهای بازیابی را هم روی کاغذ یا فایل محلی نگه دارید.

چ) دسترسی گوگل به سایت و ایندکس

این بخش را صاحب سایت به‌تنهایی نمی‌تواند حل کند، چون به مسیر شبکه‌ی میزبان بستگی دارد، نه به تنظیمات وردپرس. وقتی سایتی از بیرون ایران قابل دسترس نباشد، ربات‌های گوگل هم به آن نمی‌رسند.

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

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

پس از هر اختلال هم گزارش خزش و ایندکس را در Google Search Console بررسی کنید و خطاهای تازه را پیگیری کنید.

نمره‌ی آمادگی سایتتان را در ۲ دقیقه بگیرید

حالا که با موارد آشنا شدید، ۱۲ سؤال ساده زیر را جواب بدهید تا نمره‌ی آمادگی سایتتان را ببینید. اگر از پاسخ مطمئن نیستید، گزینه‌ی «خیر / نمی‌دانم» را بزنید؛ ندانستن هم یک ریسک است.

این نمره فقط یک راهنمای ساده است، نه یک استاندارد رسمی، و هیچ اطلاعاتی از سایت شما ذخیره یا ارسال نمی‌شود.

جدول خلاصه: وابستگی، علامت خرابی و راه‌حل

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

وابستگی	علامت خرابی	راه‌حل	اولویت
فونت گوگل	متن با فونت پیش‌فرض یا صفحه‌ی خالی برای لحظاتی	میزبانی محلی با @font-face	بالا
اسکریپت و آیکون از CDN	آیکون‌ها و اسلایدر کار نمی‌کنند	بارگذاری از مسیر خود سایت	بالا
reCAPTCHA	فرم باز نمی‌شود یا ارسال نمی‌شود	کپچای محلی یا honeypot و محدودیت نرخ	متوسط
Analytics و چت خارجی	کندی نمایش صفحه	بارگذاری async یا defer، حذف موارد غیرضروری	متوسط
Gravatar	درخواست معلق به سرور Gravatar	آواتار محلی و غیرفعال‌سازی Gravatar	پایین
درخواست‌های سمت سرور	پیشخوان کند یا یخ‌زده	WP_HTTP_BLOCK_EXTERNAL با مجازکردن سرویس‌های داخلی	بالا
WP-Cron	کارهای زمان‌بندی‌شده انجام نمی‌شود یا کند است	DISABLE_WP_CRON و کرون واقعی	متوسط
لایسنس افزونه و قالب	اخطار لایسنس یا قفل‌شدن بخشی از امکانات	نگه‌داشتن فایل zip و آزمایش روی نسخه‌ی تست	متوسط
SMTP و افزونه‌های جانبی ووکامرس	ایمیل ارسال نمی‌شود، ثبت سفارش گیر می‌کند	SMTP داخلی و بررسی APIهای خارجی	بالا
ثبت‌کننده‌ی دامنه و DNS	امکان تغییر نیم‌سرور یا رکورد نیست	بررسی دسترسی و یادداشت رکوردها	بالا
گواهی SSL	هشدار «ارتباط شما خصوصی نیست»	تمدید زودهنگام یا میزبان با تمدید مستقل	بالا
بکاپ و دسترسی ادمین	نداشتن نسخه‌ی قابل بازیابی یا قفل‌شدن از حساب	بکاپ محلی، TOTP آفلاین و ایمیل داخلی	بالا

محتوای جدول به صورت تصویر برای ذخیره:

چه چیزهایی را نمی‌شود کاملاً حل کرد؟

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

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

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

نقش زیرساخت میزبان در این ماجرا

بخش بزرگی از این چک‌لیست به تنظیمات سایت مربوط است و در اختیار خودتان. اما دو مورد، یعنی تمدید SSL و دسترسی ربات‌های گوگل، عملاً به زیرساخت میزبان بستگی دارند و از داخل وردپرس نمی‌شود درستشان کرد.

به همین دلیل ما زیرساخت DNS Cluster را راه انداخته‌ایم؛ تا در هاست‌های فن‌نگارهاست این دو مورد سر جای خودشان بمانند و لازم نباشد سراغ هاست اروپایی، GEO DNS یا سرویس واسط بروید. جزئیات این زیرساخت را در صفحه‌ی زیرساخت DNS Cluster فن‌نگارهاست می‌توانید ببینید.

اگر سایت وردپرسی‌تان فروشگاهی یا پربازدید است و می‌خواهید منابع و پایداری بیشتری داشته باشید، هاست وردپرس حرفه‌ای گزینه‌ی مناسبی است.

جمع‌بندی و قدم بعدی

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

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

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

سوالات متداول