نوشته قبلی نوشته بعدی تله های خزنده: علل ، راه حل ها و پیشگیری – Deep Dive

تله های خزنده: علل ، راه حل ها و پیشگیری – Deep Dive

تله های خزنده: علل ، راه حل ها و پیشگیری – Deep Dive منتشر شده در آوریل 4, 2020ارسال دیدگاه

علاقه مند به حوزه Seo & Sem

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

در این مقاله ، ما می خواهیم از مهارت های برنامه نویسی که ایجاد کرده ایم برای یادگیری با انجام / کدنویسی استفاده کنیم .

تبلیغات
ادامه خواندن زیر

به طور خاص ، ما می خواهیم به یکی از تأثیرگذارترین مشکلات فنی SEO که می توانید حل کنید ، نگاهی دقیق بیندازیم: شناسایی و از بین بردن تله های خزنده.

ما می خواهیم تعدادی از مثالها – علل آنها ، راه حلها از طریق قطعه های HTML و کد پایتون را بررسی کنیم.

به علاوه ، ما یک کار جالب تر هم خواهیم کرد: یک خزنده ساده بنویسید که می تواند از تله های خزنده جلوگیری کند و فقط ۱۰ خط کد پایتون طول می کشد!

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

آغازگر در تله های خزنده

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

تبلیغات
ادامه خواندن زیر

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

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

این یک مشکل رایج در سایت های محور پایگاه داده است زیرا اکثر توسعه دهندگان حتی نمی دانند که این یک مشکل جدی است.

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

چگونه یک خزنده کار می کند

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

تبلیغات
ادامه خواندن زیر

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

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

تبلیغات
ادامه خواندن زیر

وقتی نوعی خزنده انتخابی می نویسید ، به راحتی می توانید بیشتر تله های خزنده را جست و خیز کنید!

می توانید کد را در یک پرونده محلی ذخیره کنید و عنکبوت را از خط فرمان اجرا کنید ، مانند این:

 $ scrapy runspider sejspider.py 

یا از یک نوت بوک یا یک نوت بوک jupyter.

در اینجا مثالی از اجرای برنامه خزنده است:

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

خزنده قبل از خزیدن آنها باید URL های نسبی را مطلق کند ، و از کدامیک از آنها بازدید کرده تا از بازدید دوباره خودداری کند.

یک خزنده موتور جستجو کمی پیچیده تر از این است. به عنوان یک خزنده توزیع شده طراحی شده است. این بدان معنی است که خزیدن به سایت شما از یک دستگاه / IP بلکه از چندین دستگاه پخش نمی شود.

تبلیغات
ادامه خواندن زیر

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

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

چگونه یک خزنده برای تله می افتد

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

یک راه حل معمول و نادرست برای تله های خزنده ، اضافه کردن روبات های متا noindex یا canonicals به صفحات تکراری است. این کار نخواهد کرد زیرا این امر فضای خزنده را کاهش نمی دهد. صفحات هنوز نیاز به خزیدن دارند. این یک نمونه از چرایی درک این مسئله است که چگونه کارها در یک سطح اساسی کار می کنند مهم است.

تبلیغات
ادامه خواندن زیر

شناسه جلسه

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

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

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

تبلیغات
ادامه خواندن زیر

اما به یاد داشته باشید که خزنده های موتور جستجو توزیع می شوند ، بنابراین درخواست ها از IP های مختلفی تهیه می شوند. این منجر به شناسه جلسات حتی بی نظیر می شود.

پیشنهاد ویژه  جان مولر گوگل: برای یافتن سایت خود صبر نکنید تا افراد سایت خود را پیدا کنند

ما می خواهیم خزنده های جستجو برای خزیدن:

اما آنها می خزند:

هنگامی که شناسه جلسه یک پارامتر URL است ، این یک مشکل آسان برای حل است زیرا می توانید آن را در تنظیمات پارامترهای URL مسدود کنید.

تبلیغات
ادامه خواندن زیر

اما ، اگر شناسه جلسه در مسیر واقعی URL ها جاسازی شود ، چه می شود؟ بله ، این امکان پذیر و معتبر است.

سرورهای وب براساس مشخصات Enterprise Java Beans که برای پیوست شناسه جلسه در مسیری مانند این استفاده می شوند:؛ jsessionid. به راحتی می توانید سایتهایی که هنوز با این کار نمایه می شوند را در URL های خود پیدا کنید.

مسدود کردن این پارامتر زمانی که در مسیر وجود دارد امکان پذیر نیست. شما باید آن را در منبع حل کنید .

تبلیغات
ادامه خواندن زیر

حال ، اگر شما در حال نوشتن خزنده خود هستید ، می توانید به راحتی از این کد ip پرش کنید

پیمایش آسان

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

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

تبلیغات
ادامه خواندن زیر

به طور سنتی ، شما این موارد را با استفاده از JavaScript تولید می کنید ، اما از آنجا که Google می تواند آنها را اجرا و خزنده کند ، کافی نیست.

یک روش بهتر اضافه کردن پارامترها به عنوان قطعات URL است. خزنده های موتور جستجو قطعات URL را نادیده نمی گیرند. بنابراین قطعه فوق به صورت زیر بازنویسی می شود.

در اینجا کد برای تبدیل پارامترهای خاص به قطعات است.

یک پیاده سازی ناوبری وحشتناک که اغلب مشاهده می کنیم پارامترهای URL را به مسیرهایی تبدیل می کند که فیلتر کردن با رشته پرس و جو تقریبا غیرممکن است.

تبلیغات
ادامه خواندن زیر

به عنوان مثال ، به جای / دسته؟ رنگ = آبی ، شما / دسته / رنگ = آبی / را دریافت می کنید.

پیوندهای نسبی معیوب

من قبلاً مشكلات زیادی را با URL های نسبی مشاهده می كردم كه به مشتریان توصیه می كنم همیشه تمام URL ها را مطلق كنند. بعدا فهمیدم که این یک اقدام شدید است ، اما بگذارید با کد نشان دهم که چرا پیوندهای نسبی می توانند باعث ایجاد تله های خزنده شوند.

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

در اینجا کد برای تبدیل یک لینک نسبی به مطلق است.

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

در اینجا کدی وجود دارد که پیوند مطلق را نشان می دهد.

تبلیغات
ادامه خواندن زیر

اکنون ، اینجا جایی است که دام خزنده انجام می شود. وقتی این URL جعلی را در مرورگر باز می کنم ، ۴۰۴ دریافت نمی کنم که باعث می شود خزنده بتواند صفحه را رها کند و پیوندهای مربوط به آن را دنبال نکند. من دارم ۴۰۴ نرم می گیرم که تله را به حرکت در می آورد.

هنگامی که خزنده سعی می کند یک URL مطلق ایجاد کند ، پیوند معیوب ما در پاورقی دوباره رشد خواهد کرد.

تبلیغات
ادامه خواندن زیر

خزنده با این فرآیند ادامه خواهد یافت و URL جعلی تا زمانی که به حداکثر URL که توسط نرم افزار سرور وب یا CDN پشتیبانی می شود ، رشد نمی کند. این توسط سیستم تغییر می کند.

به عنوان مثال ، IIS و Internet Explorer از URL های طولانی تر از ۲،۰۴۸-۲،۰۸۳ کاراکتر پشتیبانی نمی کنند .

یک روش سریع و آسان یا طولانی یا دردناک برای گرفتن این نوع تله خزنده وجود دارد.

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

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

تبلیغات
ادامه خواندن زیر

راه سریع و آسان این است که به دنبال وجود خطای کد وضعیت ۴۱۴ در سیاهههای مربوط به سرور باشید. بیشتر سرورهای وب سازگار با W3C 414 را درخواست می کنند وقتی URL درخواست شده طولانی تر از زمان لازم باشد.

اگر سرور وب ۴۱۴s گزارش نمی دهد ، می توانید به طور متناوب طول URL های درخواستی را در پرونده اندازه گیری کرده و هر کدام را بالاتر از ۲۰۰۰ نویسه فیلتر کنید.

در اینجا کد انجام یکی از آنها وجود دارد.

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

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

تبلیغات
ادامه خواندن زیر

انفجار کش

Cache busting روشی است که توسط توسعه دهندگان برای مجبور کردن CDN (شبکه تحویل محتوا) برای استفاده از آخرین نسخه پرونده های میزبانی شده استفاده می شود.

این تکنیک نیاز به اضافه کردن شناسه منحصر به فرد به صفحات یا منابع صفحه ای دارد که می خواهید از طریق حافظه نهان CDN به آن تبدیل شوید.

پیشنهاد ویژه  SEO Real-Time: آینده پژوهش ، اطلاعات و رتبه بندی داده ها

هنگامی که توسعه دهندگان از یک یا چند مقدار شناسه منحصر به فرد استفاده می کنند ، URL های اضافی را برای خزیدن ، عموماً تصاویر ، CSS و پرونده های JavaScript ایجاد می کند ، اما این به طور کلی کار بزرگی نیست.

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

این چیزی است که به نظر میرسد.

می توانید این موارد را در سیاهههای مربوط به سرور خود تشخیص دهید و من کد را پوشش می دهم تا این کار را در قسمت بعدی انجام دهم.

تبلیغات
ادامه خواندن زیر

ذخیره سازی صفحه نسخه با اندازه تغییر اندازه

شبیه به بوت شدن حافظه نهان ، یک مشکل کنجکاوی در رابطه با افزونه های ذخیره کننده صفحه استاتیک مانند آنچه توسط یک شرکت به نام MageWorx ایجاد شده است ، ایجاد می شود.

برای یکی از مشتری های ما ، افزونه Magento آنها برای هر تغییری که مشتری ایجاد کرده بود ، نسخه های مختلفی از منابع صفحه را ذخیره می کرد.

این مسئله وقتی پیچیده شد که افزونه به طور خودکار تصاویر را در اندازه های مختلف در هر وسیله پشتیبانی تغییر اندازه داد.

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

مسئله این است که خزنده های موتور جستجو هم اکنون منابع صفحه را خزیده و تمام نسخه های ایجاد شده توسط افزونه caching را خزنده می کنند.

ما مشتری داشتیم که میزان خزیدن ۱۰۰ برابر اندازه سایت و ۷۰٪ درخواست های خزیدن به تصاویر ضربه می زد. شما فقط می توانید با نگاه کردن به سیاههها ، مسئله ای مانند این را تشخیص دهید.

تبلیغات
ادامه خواندن زیر

ما برای نشان دادن بهتر مسئله می خواهیم درخواست های جعلی Googlebot را برای تصاویر به صورت تصادفی ذخیره شده ایجاد کنیم و بنابراین می توانیم نحوه شناسایی مسئله را یاد بگیریم.

در اینجا کد اولیه سازی است:

در اینجا حلقه تولید مدخل های جعلی است.

در مرحله بعد ، بگذارید از پاندا و ماتپلولیت برای شناسایی این مسئله استفاده کنیم.

این طرح تصویر زیر را نشان می دهد.

این طرح درخواست های Googlebot را در هر روز نشان می دهد. این شبیه به ویژگی Crawl Stats در کنسول جستجوی قدیمی است. این گزارش همان چیزی بود که ما را وادار کرد تا عمیق تر در سیاهههای مربوط حفر کنیم.

تبلیغات
ادامه خواندن زیر

بعد از اینکه درخواست های Googlebot را در یک قاب داده Pandas مشاهده کردید ، تشخیص این مشکل بسیار آسان است.

در اینجا آمده است که چگونه می توانیم با یکی از سنبل های خزیدن به یکی از روزها فیلتر کنیم و بر اساس نوع صفحه با پسوند پرونده تجزیه کنیم.

زنجیرها و حلقه های تغییر مسیر طولانی

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

بیایید یک زنجیره تغییر مسیر را مثال بزنیم که منجر به حلقه می شود تا آنها را بهتر بشناسیم.

این همان چیزی است که هنگام باز کردن اولین URL در Chrome اتفاق می افتد.

همچنین می توانید زنجیره را در سیاهه برنامه وب ببینید

تبلیغات
ادامه خواندن زیر

هنگامی که از توسعه دهندگان می خواهید قوانین بازنویسی را برای این موارد اعمال کنند:

  • تغییر از http به https.
  • URL های موردی کوچک
  • موتور جستجوی URL را دوستانه کنید.
  • و غیره.
تبلیغات
ادامه خواندن زیر

آنها هر قانون را آبشار می دهند تا هرکدام به جای یک منبع از مبدا به مقصد ، نیاز به تغییر مسیر جداگانه داشته باشند.

زنجیرهای تغییر مسیر آسان هستند زیرا کد زیر را می بینید.

پس از شناسایی کد مشکل ساز ، آنها همچنین نسبتاً آسان هستند. همیشه از مبدأ به مقصد نهایی هدایت شوید.

پیوند تغییر مسیر موبایل / دسک تاپ

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

با این حال ، کوکی ها و تشخیص عامل کاربر نیز محبوب هستند و این زمانی است که حلقه ها می توانند رخ دهند زیرا خزنده های موتور جستجو کوکی ها را تنظیم نمی کنند.

تبلیغات
ادامه خواندن زیر

این کد نحوه عملکرد صحیح آن را نشان می دهد.

این یکی نشان می دهد که چگونه می تواند با تغییر مقادیر پیش فرض نادرست (منوط به حضور کوکی های HTTP) به صورت نادرست کار کند.

URL های پروکسی حلقوی

این اتفاق اخیراً برای ما افتاده است. این یک مورد غیر عادی است ، اما من انتظار دارم که هرچه بیشتر سرویس ها در پشت سرویس های پراکسی مانند Cloudflare حرکت کنند ، این اتفاق بیشتر رخ دهد.

تبلیغات
ادامه خواندن زیر

می توانید URL هایی داشته باشید که چندین بار از طریق پروکسی استفاده می شوند به شکلی که زنجیره ای ایجاد کنند. مشابه نحوه اتفاق افتادن در تغییر مسیرها.

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

ما یک برنامه در Cloudflare داریم که تماس های API را به باطن ما می دهد تا تغییرات سئو را انجام دهد. تیم ما اخیراً خطایی را ایجاد کرده است که باعث می شود تماس های API به خود نسبت داده شود و در نتیجه حلقه نامطبوع و مشکل باشد.

ما از برنامه فوق العاده مفید Logflare از chasers برای بررسی گزارش تماس های API در زمان واقعی استفاده کردیم. این چیزی است که تماسهای معمولی به نظر می رسد.

تبلیغات
ادامه خواندن زیر

در اینجا نمونه ای از ظاهری دایره ای / بازگشتی وجود دارد. این یک درخواست عظیم است هنگام رمزگشایی متن ، صدها درخواست زنجیر یافتم.

پیشنهاد ویژه  SEM در مقابل سئو در مقابل PPC تعریف شده: تفاوت چیست؟

ما می توانیم از همان ترفندی که برای شناسایی پیوندهای نسبی معیوب استفاده کردیم استفاده کنیم. ما می توانیم با کد وضعیت ۴۱۴ یا حتی طول درخواست فیلتر کنیم.

تبلیغات
ادامه خواندن زیر

بیشتر درخواست ها نباید بیش از ۲،۰۴۹ نویسه باشد. می توانید به کدی که برای تغییر مسیرهای معیوب استفاده کردیم مراجعه کنید.

URL های جادویی + متن تصادفی

مثال دیگر ، هنگامی است که URL ها شامل متن اختیاری هستند و فقط برای ارائه مطالب به شناسه نیاز دارند.

به طور کلی ، این یک چیز بزرگ نیست ، به جز هنگامی که URL ها می توانند با هر متن تصادفی و متناقض از داخل سایت مرتبط شوند.

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

در اینجا یک مثال آورده شده است.

اگر پیوند محصول ۱۱۳۷۶۴۹-۴ را با یک متن کوتاه به عنوان توضیحات محصول دنبال کنم ، صفحه محصول را بارگذاری می کنم.

تبلیغات
ادامه خواندن زیر

اما ، می بینید که کانونیک متفاوت از صفحه ای است که من درخواست کردم.

در اصل ، شما می توانید هر متنی را بین محصول و شناسه محصول و همان صفحه بارگیری کنید.

تبلیغات
ادامه خواندن زیر

canonicals مسئله محتوای تکراری را برطرف می کند ، اما بسته به اینکه چند بار نام محصول به روز می شود ، فضای خزیدن می تواند بزرگ باشد.

برای ردیابی تأثیر این مسئله ، شما باید مسیرهای URL را به دایرکتوریها شکسته و URL ها را با شناسه محصول خود گروه بندی کنید. در اینجا کد برای انجام این کار آمده است.

در اینجا خروجی مثال آورده شده است.

پیوندهایی به جستجوهای داخلی پویا

برخی از فروشندگان جستجو در سایت با ایجاد جستجوهایی با تعداد زیادی از کلمات کلیدی و قالب بندی URL های جستجو مانند URL های معمولی ، به ایجاد محتوای مبتنی بر کلمه کلیدی "جدید" کمک می کنند.

تبلیغات
ادامه خواندن زیر

تعداد کمی از چنین آدرس های اینترنتی عموماً چیز بزرگی نیستند ، اما هنگامی که شما این کار را با لیست های کلیدی کلمات کلیدی ترکیب می کنید ، در وضعیت مشابهی قرار می گیرید مانند موردی که من برای ناوبری آسان ذکر کردم.

خیلی از URL ها منجر به محتوای مشابه می شوند.

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

تبلیغات
ادامه خواندن زیر

در مثال بالا ، من یک کلاس شناسه "sli_phrase" را مشاهده می کنم ، که نشان می دهد سایت از سیستم های SLI استفاده می کند تا جستجوی آنها را تأمین کند.

کد را رها می کنم تا این یکی را به عنوان یک تمرین برای خواننده تشخیص دهد.

پیوندهای تقویم / رویداد

این احتمالاً ساده ترین دام خزنده برای درک است.

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

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

نحوه گرفتن تله های خزنده قبل از انتشار کد تا تولید

اکثر تیم های توسعه مدرن برای اتوماسیون تحویل کد با کیفیت بالا به تولید از تکنیکی بنام ادغام مداوم استفاده می کنند.

تبلیغات
ادامه خواندن زیر

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

ایده این است که به محض شناسایی یک تله خزنده ، استقرار تولید متوقف می شود. می توانید برای بسیاری از مشکلات مهم SEO دیگر از همین رویکرد استفاده کرده و تست هایی بنویسید.

CircleCI یکی از فروشندگان این فضا است و در زیر می توانید نمونه خروجی یکی از ساختهای ما را مشاهده کنید.

نحوه تشخیص تله ها پس از واقعیت

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

تبلیغات
ادامه خواندن زیر

در جستجوی Google با استفاده از اپراتورهایی مانند سایت بررسی کنید: و در صورت وجود صفحات زیاد ایندکس شده ، تله ای دارید.

همچنین می توانید ابزار پارامترهای URL جستجوی کنسول Google را برای پارامترهایی با تعداد بیش از حد URL های نظارت شده بررسی کنید.

با جستجوی الگوهای تکراری ، بسیاری از تله های ذکر شده در اینجا را در سیاهههای مربوط به سرور خواهید یافت.

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

منابعی برای کسب اطلاعات بیشتر

در اینجا منابعی را که من هنگام تحقیق در این مقاله استفاده کردم ، آورده شده است:

تبلیغات
ادامه خواندن زیر

منابع بیشتر:


اعتبار تصویر

تمام تصاویر گرفته شده توسط نویسنده ، مه ۲۰۱۹

منبع مقاله

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *