
سایت وردپرسی ممکن است امروز کاملاً سالم باشد و یک ماه بعد بدون اینکه تغییر بزرگی انجام داده باشید، با فرم ازکارافتاده، افزونه قدیمی، بکاپ ناقص، لینک شکسته، افت سرعت یا حتی مشکل در پرداخت روبهرو شود. دلیلش ساده است: سایت یک سیستم ثابت نیست. وردپرس، قالبها، افزونهها، هاست، گواهی SSL، سرویس ایمیل، درگاه پرداخت و حتی لینکهای خارجی دائماً در حال تغییر هستند.
برای همین، نگهداری سایت نباید به زمانی موکول شود که خطا ظاهر شده است. یک چکلیست نگهداری ماهانه وردپرس کمک میکند قبل از اینکه مشکل به خرابی جدی، افت فروش یا کاهش ترافیک تبدیل شود، نشانههای آن را ببینید و برایش اقدام کنید.
در این راهنما 15 کاری را مرور میکنیم که برای بیشتر سایتهای وردپرسی باید حداقل ماهی یکبار بررسی شوند. بعضی از این کارها، مثل پایش خرابی سایت، شکست بکاپ، حمله امنیتی یا خطای پرداخت، برای سایتهای مهم باید روزانه یا حتی بهصورت خودکار کنترل شوند؛ بنابراین «ماهانه» را حداقل لایه جمعبندی و بازبینی در نظر بگیرید، نه فاصله مناسب برای همه اتفاقها.
اصل مهم این چکلیست: فقط تیک نزنید. برای هر مورد مشخص کنید چه چیزی بررسی شد، معیار سالم بودن چه بود، چه مدرکی از بررسی دارید و اگر نتیجه نامناسب بود، اقدام بعدی چیست. نگهداری حرفهای یعنی بتوانید ماه بعد وضعیت امروز را با عدد و مدرک مقایسه کنید.
چرا نگهداری ماهانه سایت وردپرسی مهم است؟
مشکلات سایت معمولاً یکشبه از هیچ بهوجود نمیآیند. فضای هاست بهتدریج پر میشود، جدولهای دیتابیس رشد میکنند، یک افزونه دیگر بروزرسانی نمیشود، فرم پس از تغییر SMTP ایمیل را تحویل نمیدهد یا صفحهای که ماه قبل سالم بوده بهدلیل حذف یک مقصد، لینک شکسته پیدا میکند.
فایل ارسالی برای این مقاله نیز روی همین نکته تأکید دارد که نگهداری فقط «بکاپ، بروزرسانی و امنیت» نیست؛ سلامت سایت باید از چند لایه دیده شود: دسترسپذیری، داده و بازیابی، نرمافزار، امنیت، عملکرد، سئو فنی و مسیرهای واقعی کسبوکار مثل فرم، خرید و ایمیل. این نگاه باعث میشود سایتی که از نظر پیشخوان «سبز» بهنظر میرسد اما فرم آن لید تحویل نمیدهد، سالم تلقی نشود.
قبل از اولین اجرای چکلیست یک وضعیت مرجع بسازید
اولین ماه، چند عدد و وضعیت را ثبت کنید: حجم دیتابیس، فضای مصرفشده هاست، تعداد مدیران، نسخه PHP، تعداد افزونههای فعال، وضعیت Core Web Vitals، تعداد خطاهای مهم Search Console، زمان آخرین بکاپ موفق، درآمد یا تعداد لید ماه و صفحات حیاتی سایت. از ماه بعد، تغییر نسبت به همین وضعیت اهمیت بیشتری از یک عدد جدا دارد.
مثلاً 8 گیگابایت مصرف دیسک لزوماً مشکل نیست؛ اما اگر مصرف سایت طی یک ماه از 8 به 15 گیگابایت رسیده و محتوای تازهای هم اضافه نشده، باید علت رشد را پیدا کنید. همین منطق درباره دیتابیس، خطاهای 404، زمان پاسخ، سفارش ناموفق و تعداد حساب مدیر هم صدق میکند.
1. گرفتن بکاپ کامل از سایت
اولین مورد چکلیست باید بکاپ باشد، اما نه به معنای اینکه ماهی یکبار تازه برنامه پشتیبانگیری را شروع کنید. سایت فعال بهتر است بکاپ خودکار با فاصله متناسب با نرخ تغییر داشته باشد؛ برای فروشگاه یا سایت عضویتی ممکن است حتی بکاپ روزانه هم کافی نباشد. بررسی ماهانه برای این است که مطمئن شوید سامانه پشتیبانگیری واقعاً کار میکند و نسخه قابل استفاده دارید.
طبق مستندات رسمی وردپرس، یک نسخه کامل باید هم فایلهای سایت و هم دیتابیس را پوشش دهد؛ چون محتوا، تنظیمات و کاربران در دیتابیس هستند، اما قالب، افزونه، رسانهها و فایلهای اجرایی در فایلسیستم قرار دارند.
در بررسی ماهانه بکاپ چه چیزهایی را کنترل کنیم؟
- آخرین بکاپ موفق در چه تاریخی ساخته شده است؟
- آیا فایلها و دیتابیس هر دو در همان بازه زمانی پشتیبانگیری شدهاند؟
- آیا دستکم یک نسخه خارج از همان هاست اصلی نگهداری میشود؟
- حجم بکاپ نسبت به ماه قبل تغییر غیرعادی نکرده است؟
- آیا امکان دانلود یا بازیابی نسخه وجود دارد؟
- آخرین بار چه زمانی یک بازیابی آزمایشی انجام دادهاید؟
وجود فایل ZIP بهتنهایی اثبات نمیکند بکاپ سالم است. هر چند وقت یکبار نسخه را روی یک محیط آزمایشی بازیابی کنید و حداقل ورود به پیشخوان، تصاویر، چند نوشته، فرمها و صفحات مهم را بررسی کنید. برای آشنایی با ابزارهای مختلف میتوانید راهنمای بهترین افزونههای بکاپ وردپرس و آموزش بکاپ و بازگردانی با UpdraftPlus را ببینید.
تا وقتی بکاپ تازه و مسیر بازگشت قابل اتکا ندارید، بروزرسانی بزرگ، تغییر نسخه PHP، پاکسازی دیتابیس یا مهاجرت را شروع نکنید.
2. بررسی بروزرسانی وردپرس، قالب و افزونهها
از پیشخوان به داشبورد ← بروزرسانیها بروید و وضعیت هسته وردپرس، قالبها و افزونهها را بررسی کنید. مستندات خود وردپرس نیز تأکید میکنند که نسخههای افزونه و قالب باید بهروز نگه داشته شوند و قبل از بروزرسانی داشتن بکاپ تازه ضروری است.
اما بروزرسانی حرفهای فقط کلیک روی «همه را بروزرسانی کن» نیست. ابتدا تغییرات نسخه را بخوانید. اگر بروزرسانی امنیتی است، اولویت بالاتری دارد. اگر نسخه اصلی یک افزونه فروشگاهی، صفحهساز یا افزونه عضویت است، بهتر است ابتدا در محیط تست بررسی شود.
بعد از بروزرسانی چه چیزی را تست کنیم؟
صفحه اصلی بهتنهایی کافی نیست. ورود به سایت، چند صفحه مهم، جستجو، فرم، موبایل و در سایت فروشگاهی سبد خرید و تسویهحساب را بررسی کنید. اگر چند افزونه حیاتی دارید، آنها را در گروههای کوچک بروزرسانی کنید تا در صورت بروز ناسازگاری، پیدا کردن علت سادهتر باشد.
بروزرسانی خودکار برای اجزای کمریسک میتواند مفید باشد، اما «خودکار» به معنای «بدون نظارت» نیست. باید بدانید اگر بروزرسانی شکست خورد چگونه مطلع میشوید و آیا امکان بازگشت دارید.
3. حذف افزونهها و قالبهای غیرضروری
هر افزونه و قالبی که روی سایت میماند باید دلیل مشخصی داشته باشد. افزونه غیرفعال هنوز روی سرور وجود دارد و اگر آسیبپذیر یا رهاشده باشد، صرف «غیرفعال بودن» آن را به یک دارایی بیخطر تبدیل نمیکند. بخش Site Health وردپرس هم به حذف افزونهها و قالبهای غیرفعال و غیرضروری توصیه میکند.
ماهی یکبار فهرست افزونهها را مرور کنید و برای هر مورد پاسخ دهید: آیا واقعاً استفاده میشود؟ آیا توسعهدهنده هنوز آن را بروزرسانی میکند؟ آیا دو افزونه کار مشابه انجام میدهند؟ آیا افزونهای فقط برای یک عملیات موقت نصب شده و فراموش شده است؟
در مورد قالبها نیز قالب فعال، Child Theme در صورت استفاده و یک قالب پیشفرض برای عیبیابی میتوانند منطقی باشند. نگه داشتن تعداد زیادی قالب قدیمی که هیچ استفادهای ندارند، ارزش عملی کمی دارد.
4. بررسی سلامت هاست و منابع مصرفی
مشکل سرعت و پایداری همیشه از وردپرس نیست. ممکن است فضای دیسک رو به پایان باشد، مصرف CPU یا RAM در ساعات خاص بالا برود، Cronها عقب افتاده باشند یا فایل خطا بدون کنترل رشد کند.
از مسیر ابزارها ← سلامت سایت در وردپرس میتوانید اطلاعاتی درباره نسخه PHP، سرور، دیتابیس، دسترسی فایلها، افزونهها، قالبها، رویدادهای زمانبندیشده و بعضی مشکلات پیکربندی ببینید. این بخش ابزار تشخیص خوبی است، اما جای پنل هاست را برای CPU، RAM، پهنای باند و فضای دیسک نمیگیرد.
در پنل هاست چه مواردی را ببینیم؟
- فضای دیسک و سرعت رشد آن
- مصرف CPU و RAM و تعداد دفعات رسیدن به محدودیت
- پهنای باند و جهش غیرعادی مصرف
- نسخه PHP و وضعیت پشتیبانی آن
- لاگ خطاهای PHP و وبسرور
- وظایف زمانبندیشده و صفهایی که عقب افتادهاند
- حجم فایلهای لاگ، بکاپهای قدیمی و پوشه uploads
اگر مصرف منابع بالا رفته است، قبل از ارتقای پلن هاست علت را پیدا کنید. یک افزونه، بات، Query سنگین، فایل لاگ یا فرآیند Cron میتواند علت اصلی باشد. ارتقای منابع بدون تشخیص، فقط مشکل را گرانتر میکند.
5. بررسی سرعت سایت
برای بررسی ماهانه سرعت، از هر ماه یک شرایط نسبتاً ثابت بسازید. چند صفحه نماینده انتخاب کنید: صفحه اصلی، یک مقاله، یک صفحه محصول یا خدمت و اگر فروشگاهی هستید، صفحه دسته یا محصول سنگین. فقط یک بار تست گرفتن از صفحه اصلی تصویر کاملی نمیدهد.
PageSpeed Insights هم داده آزمایشگاهی و هم در صورت کافی بودن داده، تجربه واقعی کاربران را نمایش میدهد. در معیارهای اصلی تجربه کاربری، سه شاخص مهم عبارتاند از:
- LCP: زمان نمایش بزرگترین محتوای اصلی؛ مقدار خوب معمولاً تا 2.5 ثانیه است
- INP: سرعت پاسخ صفحه به تعامل؛ مقدار خوب تا 200 میلیثانیه است
- CLS: میزان جابهجایی ناگهانی چیدمان؛ مقدار خوب تا 0.1 است
هدف نگهداری ماهانه گرفتن «امتیاز 100» نیست. روند مهمتر است. اگر LCP صفحه محصول نسبت به ماه قبل شدیداً بدتر شده، باید ببینید چه چیزی تغییر کرده: تصویر اصلی، اسکریپت تبلیغاتی، افزونه، فونت، سرور یا کش.
برای رفع علت کندی، بهجای نصب تصادفی افزونههای بیشتر، میتوانید از راهنمای افزایش سرعت سایت وردپرسی استفاده کنید.
6. بررسی خطاهای سرچ کنسول
Google Search Console یکی از بهترین جاها برای دیدن مشکلاتی است که ممکن است از داخل پیشخوان وردپرس اصلاً دیده نشوند. ماهی یکبار گزارشهای مهم را مرور کنید و بهدنبال تغییر تازه باشید، نه اینکه هر وضعیت «ایندکس نشده» را خطا تصور کنید.
کدام بخشها مهمترند؟
- Page Indexing: افت یا جهش غیرعادی تعداد صفحات ایندکسشده و دلیل ایندکس نشدن URLها
- Core Web Vitals: گروههای URL ضعیف یا نیازمند بهبود
- HTTPS: مشکلات مربوط به نسخه امن صفحات در صورت نمایش گزارش
- Manual Actions: هر اقدام دستی گوگل باید فوراً بررسی شود
- Security Issues: هشدارهای هک، فیشینگ، بدافزار یا محتوای مضر
- Sitemaps: وضعیت خواندن نقشه سایت و خطاهای تازه
گوگل در مستندات Search Console توضیح میدهد که اگر اقدام دستی یا مشکل امنیتی تازهای رخ دهد، معمولاً اعلان و ایمیل هم دریافت میکنید؛ بنابراین این گزارشها برای یافتن رخدادهای مهم هستند، نه اینکه هر ماه بدون دلیل روی تکتک URLها درخواست ایندکس بزنید.
اگر با گزارشها آشنا نیستید، مقاله سرچ کنسول چیست و چگونه از آن استفاده کنیم؟ را بخوانید.
7. بررسی لینکهای شکسته
لینک شکسته فقط یک مشکل سئو نیست؛ ممکن است کاربر را از مقاله به صفحه 404، فایل حذفشده یا محصولی که دیگر وجود ندارد بفرستد. لینکهای خارجی هم ممکن است بعد از مدتی تغییر کنند یا مقصدشان حذف شود.
برای سایت کوچک میتوانید صفحات مهم را با ابزارهای بررسی لینک یا افزونه مناسب اسکن کنید. در سایت بزرگ، یک خزنده خارجی معمولاً انتخاب بهتری است چون بار دائمی روی سرور وردپرس ایجاد نمیکند. همچنین گزارش 404 سرور و لینکهای داخلی صفحات مهم میتواند سرنخ بدهد.
هر لینک خراب را ریدایرکت نکنید
اگر URL مقصد اشتباه تایپی دارد، همان لینک را اصلاح کنید. اگر صفحهای حذف شده ولی جایگزین واقعی دارد، ریدایرکت منطقی است. اما انتقال هر صفحه حذفشده به صفحه اصلی، تجربه خوبی ایجاد نمیکند و مسئله را پنهان میکند.
برای روشهای پیدا کردن و اصلاح این موارد، راهنمای یافتن و رفع لینکهای شکسته در وردپرس را ببینید.
8. بررسی صفحات مهم سایت
ممکن است افزونهها سالم باشند و هیچ خطای واضحی هم در پیشخوان نبینید، اما یک بخش واقعی سایت برای کاربر خراب شده باشد. ماهی یکبار چند مسیر مهم را در حالت خروج از حساب کاربری و روی موبایل هم باز کنید.
بسته به نوع سایت، فهرست شما میتواند شامل صفحه اصلی، صفحات خدمت، محصول پرفروش، تماس با ما، درباره ما، صفحه ورود، جستجو، آرشیو اصلی، سبد خرید، تسویهحساب، حساب کاربری و صفحه تشکر باشد.
به چه چیزهایی دقت کنیم؟
- منو و دکمههای اصلی کار میکنند؟
- تصویر یا آیکون شکسته وجود ندارد؟
- محتوا پشت پنجره پاپآپ یا بنر رضایت کوکی گیر نکرده است؟
- در موبایل چیزی از صفحه بیرون نمیزند؟
- قیمت، شماره تماس و اطلاعات مهم بهروز هستند؟
- کاربر بدون ورود هم تجربه درست دارد؟
- کش، نسخه قدیمی یا اطلاعات شخصی را به کاربر دیگر نشان نمیدهد؟
برای این مرحله نیازی به ابزار پیچیده نیست. چند دقیقه استفاده واقعی از سایت، گاهی ایرادی را پیدا میکند که هیچ داشبوردی گزارش نکرده است.
9. بررسی فرمهای تماس و ثبت سفارش
«فرم باز میشود» به معنی «فرم سالم است» نیست. یک فرم تماس باید ثبت شود، پیام موفقیت نشان دهد، ایمیل یا اعلان به مقصد برسد و اگر به CRM یا سیستم پیامکی متصل است، اطلاعات آنجا هم ثبت شود.
یک فرم واقعی را با ایمیل آزمایشی ارسال کنید و تمام مسیر را تا مقصد بررسی کنید. در فروشگاه نیز بررسی ظاهری صفحه تسویهحساب کافی نیست. مستندات WooCommerce توصیه میکنند آزمون سفارش و پرداخت در محیط آزمایشی و با حالت تست درگاه انجام شود تا پول واقعی جابهجا نشود.
چکلیست آزمون تبدیل
- فرم بدون خطای جاوااسکریپت ارسال میشود
- پیام موفقیت یا صفحه بعد درست است
- ایمیل به صندوق مقصد میرسد، نه فقط اینکه وردپرس آن را «ارسالشده» بداند
- لید در CRM یا پنل فرم ثبت میشود
- در فروشگاه، سبد، هزینه ارسال، کوپن، پرداخت و وضعیت سفارش درست هستند
- ایمیل سفارش برای مشتری و مدیر در صورت نیاز ارسال میشود
- سفارش یا لید آزمایشی علامتگذاری و بعد از ثبت مدرک پاک یا لغو میشود
10. بررسی امنیت ورود کاربران
ماهانه فهرست کاربران دارای دسترسی بالا را مرور کنید. حساب مدیر برای نیرویی که دیگر با شما همکاری نمیکند، کاربر آزمایشی قدیمی یا حسابی که مالک مشخصی ندارد، نباید برای همیشه فعال بماند.
برای حسابهای حساس، فعال بودن تأیید دومرحلهای، بررسی نشستهای فعال و توجه به ورودهای غیرعادی اهمیت دارد. همچنین اگر از Application Passwords، کلید API یا حسابهای سرویس استفاده میکنید، موارد قدیمی و بدون مالک را فراموش نکنید.
در صورت نیاز به جزئیات بیشتر، راهنمای افزایش امنیت وردپرس و آموزش فعالسازی تأیید دومرحلهای در وردپرس را ببینید.
11. تغییر یا بررسی رمزهای مهم
این بخش یک اصلاح مهم نسبت به توصیههای قدیمی امنیتی دارد: لازم نیست رمزهای قوی را صرفاً بهخاطر رسیدن یک تاریخ ثابت، مثلاً هر 30 یا 90 روز، عوض کنید. راهنمای جدید NIST توصیه میکند تغییر دورهای و بیدلیل رمز اجباری نشود؛ تغییر باید زمانی انجام شود که کاربر درخواست کرده یا نشانهای از افشای رمز وجود دارد.
پس در چکلیست ماهانه، بهجای «تعویض همه رمزها» این موارد را بررسی کنید:
- رمزهای مدیر وردپرس، هاست، دامنه، ایمیل و سرویسهای حیاتی یکتا و طولانی هستند؟
- یک رمز بین چند سرویس تکرار نشده است؟
- نیرویی که دسترسی داشته از تیم خارج شده است؟
- نشانهای از نشت اطلاعات، ورود مشکوک یا فیشینگ دیدهاید؟
- تأیید دومرحلهای برای حسابهای مهم فعال است؟
- رمزها در مدیر رمز عبور امن نگهداری میشوند و داخل فایل اکسل یا پیامرسان پراکنده نیستند؟
اگر احتمال میدهید یکی از رمزها افشا شده است، آن را فوراً تغییر دهید، نشستهای فعال را لغو کنید و علت افشا را بررسی کنید. فقط عوض کردن رمز بدون بستن مسیر نفوذ کافی نیست.
12. پاکسازی دیتابیس وردپرس
پاکسازی دیتابیس یکی از بخشهایی است که بیشترین احتمال «بهینهسازی بیش از حد» را دارد. هر ماه لازم نیست حتماً چیزی را حذف کنید. اول ببینید چه چیزی رشد کرده و آیا واقعاً روی عملکرد اثر دارد.
دادههایی مانند رونوشتهای بسیار زیاد، نظرات اسپم، بعضی Transientهای منقضیشده، لاگهای افزونهها، Sessionها و جدولهای باقیمانده از افزونههای حذفشده میتوانند در طول زمان حجم دیتابیس را بالا ببرند. اما حذف کورکورانه آنها خطرناک است.
روش امنتر پاکسازی
- قبل از هر تغییر از دیتابیس بکاپ تازه بگیرید
- حجم جدولها را با ماه قبل مقایسه کنید
- اگر یک جدول غیرعادی بزرگ شده، مشخص کنید متعلق به کدام افزونه است
- از ابزار پاکسازی همان افزونه یا روش مستندش استفاده کنید
- پس از پاکسازی، بخش مرتبط سایت را تست کنید
همه Transientها الزاماً داخل دیتابیس نیستند؛ در سایتهایی که کش شیء پایدار مانند Redis دارند، ممکن است این دادهها در کش بیرونی ذخیره شوند. بنابراین «حذف Transient برای افزایش سرعت» یک نسخه عمومی برای همه سایتها نیست.
13. بررسی نظرات اسپم
اگر دیدگاه در سایت فعال است، پوشه Spam و Pending را مرور کنید. پاک کردن اسپم فقط برای سبک شدن پیشخوان نیست؛ رشد ناگهانی اسپم میتواند نشان دهد فرم دیدگاه بیشتر هدف رباتها قرار گرفته یا راهکار ضداسپم شما درست عمل نمیکند.
دیدگاههای منتظر تأیید را هم فراموش نکنید. نظر واقعی کاربری که یک ماه در صف مانده، تجربه خوبی ایجاد نمیکند. در سایتهایی که ثبتنام عمومی دارند، حسابهای اسپم را نیز کنار دیدگاهها بررسی کنید.
اگر حجم Spam ناگهان چند برابر شده است، بهجای صرفاً خالی کردن پوشه، منبع را بررسی کنید: کدام فرم هدف است؟ آیا CAPTCHA یا ضداسپم درست کار میکند؟ آیا یک URL خاص بیشترین حمله را دریافت میکند؟
14. بررسی وضعیت SSL
SSL معمولاً باید بهصورت خودکار تمدید شود، اما «خودکار بودن» دلیل نمیشود هرگز بررسی نشود. خرابی تمدید گواهی میتواند ناگهان سایت را با هشدار امنیتی مرورگر روبهرو کند.
در بازبینی ماهانه مطمئن شوید:
- سایت با
https://بدون هشدار باز میشود - گواهی هنوز معتبر است و تمدید خودکار فعال است
- نسخه
http://به HTTPS هدایت میشود - صفحات مهم محتوای ناامن ترکیبی ندارند
- دامنههای اصلی و زیردامنههای ضروری در گواهی پوشش داده شدهاند
- پس از تغییر CDN یا هاست، زنجیره گواهی و تنظیم HTTPS سالم مانده است
برای راهاندازی و رفع مشکلات رایج، مقاله فعالسازی SSL در وردپرس را ببینید.
نکته مهم این است که تمدید گواهی را به حافظه انسان وابسته نکنید. سرویسهایی مانند Let’s Encrypt روی تمدید خودکار تأکید دارند؛ بهتر است هشدار انقضا نیز فعال باشد تا خرابی فرآیند تمدید قبل از پایان اعتبار دیده شود.
15. بررسی درآمد، سفارشها یا لیدهای سایت
آخرین مورد چکلیست فنی بهنظر نمیرسد، اما شاید مهمترین آن باشد. سایت برای یک هدف ساخته شده است: فروش، دریافت درخواست مشاوره، ثبتنام، تماس یا تولید سرنخ. ممکن است همه افزونهها سبز باشند ولی تعداد لیدها بهدلیل خرابی فرم نصف شده باشد.
در پایان ماه چه چیزی را مقایسه کنیم؟
- تعداد سفارش موفق، ناموفق و لغوشده
- مبلغ فروش و میانگین ارزش سفارش
- تعداد فرمهای ثبتشده و لیدهای دریافتشده
- اختلاف میان تعداد ثبت فرم و تعداد ایمیل یا رکورد CRM
- افت غیرعادی نرخ تبدیل صفحات مهم
- اختلاف سفارشهای WooCommerce با گزارش درگاه یا حسابداری
- کاهش ناگهانی فروش که همزمان با یک بروزرسانی، تغییر فرم یا تغییر درگاه رخ داده است
در این بخش دنبال «عدد خوب جهانی» نباشید. روند خود سایت مهم است. اگر تعداد بازدید ثابت مانده ولی لیدها ۵۰ درصد کم شدهاند، احتمال مشکل در مسیر تبدیل وجود دارد. اگر سفارشها ثبت میشوند اما پرداخت موفق نمیشود، مشکل با افت ترافیک فرق دارد.
گزارش ماهانه را طوری بنویسید که برای مدیر کسبوکار قابل فهم باشد؛ مثلاً «فرم درخواست قیمت تست شد و پیام به ایمیل و CRM رسید» بسیار دقیقتر از جمله «افزونه فرم سالم است» است.
جدول چکلیست نگهداری ماهانه وردپرس
جدول زیر نسخه اجرایی همین مقاله است. میتوانید در شروع هر ماه آن را کپی کنید و برای هر ردیف وضعیت «انجام شد / نیاز به اقدام / بحرانی» و مدرک مربوط را در گزارش خود ثبت کنید.
| ردیف | کار ماهانه | چه چیزی بررسی شود؟ | معیار قبولی | اگر مشکل بود |
|---|---|---|---|---|
| 1 | بکاپ کامل | فایلها، دیتابیس، مقصد خارج از هاست و امکان بازیابی | نسخه تازه، سالم و قابل دانلود/بازیابی | تغییرات پرریسک متوقف و مشکل بکاپ رفع شود |
| 2 | بروزرسانیها | هسته وردپرس، قالب، افزونهها و سازگاری PHP | نسخههای ضروری اعمال و مسیرهای حیاتی تست شدهاند | در محیط تست بررسی یا به نسخه قبلی برگردانید |
| 3 | افزونه و قالب اضافی | موارد غیرفعال، بدون استفاده، رهاشده یا تکراری | فقط اجزای لازم و پشتیبانیشده باقی ماندهاند | وابستگی را مشخص و سپس حذف کنید |
| 4 | سلامت هاست | فضای دیسک، CPU، RAM، PHP، خطاها، Cron و صفها | مصرف عادی و بدون خطای بحرانی | علت رشد مصرف یا خطا بررسی شود |
| 5 | سرعت سایت | صفحات نماینده، LCP، INP، CLS و زمان پاسخ | روند نسبت به ماه قبل بدتر نشده است | عامل افت؛ سرور، تصویر، افزونه یا اسکریپت شناسایی شود |
| 6 | Search Console | ایندکس، صفحات مهم، خطاهای جدید، اقدام دستی و امنیت | افت یا خطای تازه بدون توضیح وجود ندارد | URLهای نمونه و علت اصلی بررسی شوند |
| 7 | لینکهای شکسته | لینک داخلی، خارجی، تصویر و مقصدهای 404 | مسیرهای مهم بدون لینک خراب هستند | اصلاح URL، جایگزینی منبع یا ریدایرکت منطقی |
| 8 | صفحات مهم | خانه، خدمت/محصول، تماس، ورود، جستجو و صفحات تبدیل | در موبایل و حالت خروج از حساب درست نمایش داده میشوند | مشکل طراحی، کش، محتوا یا اسکریپت رفع شود |
| 9 | فرم و سفارش | ارسال فرم، ایمیل، CRM، سبد، پرداخت و صفحه تشکر | آزمون واقعی تا انتها موفق است | مسیر شکست مشخص و فوراً پیگیری شود |
| 10 | امنیت ورود | مدیران، تأیید دومرحلهای، ورودهای غیرعادی، نشستها و Application Passwords | فقط دسترسیهای شناختهشده و لازم فعالاند | حساب یا نشست مشکوک تعلیق و بررسی شود |
| 11 | رمزهای مهم | رمزهای ضعیف/تکراری، خروج نیروی سابق و نشانه افشا | رمزهای یکتا و امن؛ بدون اجبار تعویض بیدلیل | در صورت احتمال افشا فوراً تغییر و نشستها لغو شوند |
| 12 | دیتابیس | رشد جدولها، Revision، Log، Transient و داده افزونههای حذفشده | رشد قابل توضیح و بدون انباشت غیرعادی | قبل از پاکسازی، مالک داده و بکاپ مشخص شود |
| 13 | نظرات اسپم | Spam، Pending، ثبتنامهای مشکوک و عملکرد ضداسپم | صف بررسی کنترل شده و جهش غیرعادی ندارد | قواعد ضداسپم و فرمهای هدف بررسی شوند |
| 14 | SSL و HTTPS | اعتبار گواهی، تمدید خودکار، ریدایرکت HTTPS و Mixed Content | گواهی معتبر و سایت بدون هشدار مرورگر | تمدید، زنجیره گواهی یا محتوای ناامن اصلاح شود |
| 15 | درآمد، سفارش و لید | روند فروش/لید، نرخ تبدیل، سفارش ناموفق و اختلاف با درگاه/CRM | افت غیرعادی یا گمشدن داده مشاهده نمیشود | مسیر فنی و تجاری افت بهصورت جدا بررسی شود |
گزارش ماهانه چه اطلاعاتی داشته باشد؟
حداقل تاریخ اجرا، نام مسئول، وضعیت قبل و بعد، لینک یا تصویر مدرک، تغییر انجامشده، نقطه بازگشت و کارهای باز ماه بعد را ثبت کنید. اگر تیم چندنفره است، «تیم فنی پیگیری کند» مسئول مشخصی نیست؛ هر کار باز باید صاحب و موعد داشته باشد.
هر چند وقت یکبار باید سایت وردپرسی را بررسی کنیم؟
برای همه سایتها یک برنامه ثابت وجود ندارد. تناوب باید بر اساس نرخ تغییر و هزینه خرابی تعیین شود. یک وبلاگ شخصی کمتغییر با فروشگاهی که هر ساعت سفارش دارد، نمیتواند برنامه یکسان داشته باشد.
| بازه | چه کارهایی مناسب این بازهاند؟ | برای چه سایتهایی باید کوتاهتر شود؟ |
|---|---|---|
| پیوسته / روزانه | آپتایم، شکست بکاپ، خطاهای بحرانی، امنیت، پرداخت و سرویسهای حیاتی | فروشگاه، عضویت، سایت پرترافیک و سایت درآمدزا |
| هفتگی | صف بروزرسانیها، فرمها، نظرات، لاگها، محتوا و تغییرات تازه | سایتهایی که روزانه محتوا یا سفارش زیادی دارند |
| ماهانه | اجرای کامل همین 15 مورد، مقایسه روندها و ثبت گزارش | تقریباً همه سایتهای فعال |
| فصلی | آزمون کامل بازیابی، ممیزی دسترسی، ارزیابی افزونههای حیاتی و بررسی عمیق دیتابیس | تیمها و فروشگاههای حساس میتوانند زودتر انجام دهند |
| سالانه | دامنه، هاست، لایسنس، معماری، هزینهها، ظرفیت و برنامه بحران | در صورت تغییر زیرساخت یا رشد سریع، زودتر بازبینی شود |
پس چرا این مقاله «ماهانه» است؟ چون ماه یک بازه مناسب برای جمعبندی همه لایهها، مقایسه روندها و بستن کارهای باز است. اما کارهای حیاتی مثل آپتایم، شکست بکاپ، حمله امنیتی و خرابی پرداخت را نباید تا گزارش آخر ماه رها کرد.
چه زمانی نگهداری عادی را متوقف کنیم؟
اگر بکاپ قابل بازیابی ندارید، حساب مدیر ناشناس دیدهاید، نشانه نفوذ وجود دارد، بروزرسانی با تغییر بزرگ دیتابیس همراه است یا سفارش و اطلاعات کاربر در خطر حذف هستند، اجرای عادی چکلیست را متوقف کنید. در چنین شرایطی چند تغییر پشتسرهم یا نصب ابزارهای بیشتر میتواند شواهد را از بین ببرد و مشکل را پیچیدهتر کند.
جمعبندی
نگهداری ماهانه وردپرس یعنی سایت را قبل از خرابی بررسی کنید، نه بعد از آن. ۱۵ مورد این چکلیست از بکاپ و بروزرسانی شروع میشوند، اما به همانها محدود نیستند؛ هاست، سرعت، Search Console، لینکها، صفحات مهم، فرمها، امنیت ورود، رمزها، دیتابیس، اسپم، SSL و در نهایت درآمد و لید هم باید دیده شوند.
مهمتر از تعداد تیکها، قابل سنجش بودن نگهداری است. اگر ماه بعد ندانید چه چیزی بررسی شده، چه عددی داشته و چه تغییری انجام شده، چکلیست تبدیل به یک کار تشریفاتی میشود. یک گزارش کوتاه با مدرک و معیار قبولی باعث میشود روندهای بد قبل از تبدیل شدن به بحران دیده شوند.
اگر بخواهیم کل مقاله را در یک جمله خلاصه کنیم: بکاپ قابل بازیابی داشته باشید، تغییرات را کنترلشده انجام دهید، مسیرهای واقعی کاربر را تست کنید و هر ماه روند سلامت فنی و تجاری سایت را با ماه قبل مقایسه کنید.


