هر چه وب با فریم‌ورک جاوا اسکریپت، front endهای کتابخانه در وب‌سایت‌ها، اپلیکیشن‌های وب پیشرفته، اَپ‌های تک صفحه‌ای، JSON-LD و … پیچیده‌تر می‌شود، محدوده‌ خطاها نیز گسترده‌تر می‌گردد. زمانی که همه دارایی شما HTML، CSS و لینک‌ها باشند چیزهای زیادی برای خراب شدن وجود دارند. گرچه در دنیای امروز که وب‌سایت‌ها به صورت داینامیک و با رابط‌های کاربری جهانی JS تولید می‌شوند روزنه‌های زیادی برای بروز خطا وجود دارد.

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

راه قدیمی

از لحاظ تاریخی اگر یک تحلیل‌گر Log باشید، تجزیه و تحلیل مسائل مانند جستجو در فایل‌های ورود به سیستم (log files) را به وسیله اکسل انجام می‌دهید. این عالی است اما نیازمند این است که مشکل را بدانید یا باید در بخش‌های مختلف Log که دارای مشکل هستند جستجو کنید. این کار غیر ممکن نیست و در این مورد به طور مفصل هم در وبلاگ خود و هم در راهنمای تجزیه و تحلیل log file توضیح داده‌ایم.

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

یک کمک‌ کننده

اولین کاری که باید انجام دهیم این است که سرور خود را طوری تنظیم کنیم که فایل‌های ورود به سیستم را به جایی ارسال کند. راه حل استاندارد من برای این کار استفاده از log rotation است. بسته به سرور خود می‌‌توانید از روش‌های مختلف برای دستیابی به آن استفاده کنید اما در Nginx چیزی شبیه به این است:

# time_iso8601 looks like this: 2016-08-10T14:53:00+01:00
if ($time_iso8601 ~ “^(\d{4})-(\d{2})-(\d{2})”) {
set $year $1;
set $month $2;
set $day $3;
}
<span class=”redactor-invisible-space”>
</span>access_log /var/log/nginx/$year-$month-$day-access.log;

بدین وسیله می‌توانید logها را در هر تاریخ مشخصی یا مجموعه‌ای از تاریخ‌ها ببینید که این کار به سادگی با دریافت داده‌های مربوط به آن بازه تاریخی ممکن می‌شود. با تنظیم log rotation می‌توانیم یک اسکریپت را نیز تنظیم کنیم که ما این کار را در نیمه‌های شب به وسیله Cron انجام دادیم تا log file مربوط به داده‌های دیروز را بیرون کشیده و آن را تجزیه و تحلیل کنیم. اگر بخواهید می‌توانید چندین بار در طول روز، هفته‌ای یک بار و یا در هر بازه زمانی که برای سطح حجم داده‌های شما مناسب است، این کار را انجام دهید.

سوال بعدی این است که: باید به دنبال چه چیزی باشیم؟ خب، زمانی که لاگ‌های مورد نظر خود را به دست آوردیم، این گزارشی است که سیستم من می‌دهد:

کدهای وضعیت ۳۰*

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

کدهای وضعیت ۴۰۴

داستان مشابهی است. باید همه منابع ۴۰۴ را بررسی کرد تا ببینید که آیا گم شده‌اند یا خیر. هر چیزی که آنجاست را می‌توان مورد بررسی قرار داد و فهمید که چرا مشکل را حل نمی‌کند و می‌توان با لینک دادن به هر چیزی که گم شده است با همان روش مشابه رفتار کرد مانند کد ۳۰۱/۳۰۲٫

کدهای وضعیت ۵۰*

اگر کدهای ۵۰* زیادی را مشاهده می‌کنید چیز بدی اتفاق افتاده و روز خوبی نخواهید داشت. سرورتان نمی‌تواند پاسخ‌گوی درخواست‌های مربوط به منابعی خاص و یا تمام سایت‌تان باشد که البته این به میزان بدی این ماجرا نیز بستگی دارد.

بودجه ردیابی

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

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

درست مشابه بالا اما با بررسی جزئیات بیشترین و کمترین درخواست‌هایی که توسط موتورهای جستجو انجام شده است.

عمل‌کنندگان بد

بسیاری از ربات‌هایی که به دنبال آسیب‌ها هستند برای چیزهایی مانند wp_admin، wp_login، ۴۰۴ها، config.php و دیگر منابع متداول مانند URLها درخواست ارسال می‌کنند. هر آدرس IP که درخواست‌هایی تکراری را به این URLها ارسال می‌کند، می‌تواند به صورت خودکار به لیست سیاه IP اضافه شود.

گزارش URLهای مطابق با الگو

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

رفتار ردیاب جستجو

به تعداد درخواست‌هایی که هر روزه توسط Googlebot انجام می‌شود وارد شوید. اگر x% افزایش داشت بسیار خوب است. به عنوان یک نکته به خاطر داشته باشید که با داشتن دنباله‌های زیاد اعداد انجام محاسبه برای مشخص کردن داده‌های خارج از محدوده سخت نخواهد بود و احتمالاً ارزش وقت گذاشتن را دارد.

داده‌های خروجی

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

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

نتیجه‌گیری

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