صفحه شغل منقضی‌شده در سایت کاریابی؛ حذف، نگهداری یا ریدایرکت

فرصت شغلی بسته شده، اما کارجو هنوز از گوگل وارد صفحه می‌شود و روی «ارسال رزومه» می‌زند. شاید فرم خطا بدهد یا درخواست را برای موقعیتی بگیرد که دیگر وجود ندارد. این فقط مشکل یک تاریخ در پنل نیست؛ متن صفحه، دکمه، دادهٔ ساختاریافته و پاسخ سرور ممکن است هرکدام وضعیت متفاوتی نشان دهند.

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

از کجا بفهمیم فرصت شغلی واقعاً پایان یافته است؟

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

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

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

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

نگهداری، حذف یا انتقال؛ کدام تصمیم مناسب است؟

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

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

در یک مثال فرضی، آگهی «کارشناس پشتیبانی شرکت الف در شیراز» بسته شده و شرکت ب برای فروش در تهران نیرو می‌خواهد. شباهت واژهٔ «کارشناس» این دو را معادل نمی‌کند. انتقال اجباری، کارجو را به قرارداد، شهر و کارفرمای دیگری می‌برد. اگر فرصت‌های مشابه را پیشنهاد می‌دهید، آن‌ها را به‌عنوان پیشنهاد جدا معرفی کنید.

برای اجرای گروهی، آگهی‌ها را ابتدا با وضعیت استخدام دسته‌بندی کنید و سپس برای هر وضعیت چند نمونهٔ واقعی ببینید. تاریخ قدیمی یک علامت برای بررسی است، نه حکم حذف. از یک ستون «روز انتشار» نمی‌توان فهمید فرصت هنوز باز است یا صفحه برای مراجعهٔ بعدی ارزش دارد.

اگر صفحه را نگه داریم، کارجو باید چه ببیند؟

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

پیام وضعیت را کنار عنوان یا در بخش نخست صفحه قرار دهید؛ پنهان‌کردن آن زیر چند بخش توضیح، کارجو را تا دکمهٔ نامعتبر جلو می‌برد. متن کوتاهی مانند «پذیرش درخواست برای این فرصت پایان یافته است» وضعیت را روشن می‌کند. فقط وقتی تاریخ پایان را بنویسید که در سامانه ثبت و تأیید شده باشد.

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

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

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

JobPosting و تاریخ انقضا را چطور اصلاح کنیم؟

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

گوگل در راهنمای رسمی JobPosting می‌گوید: «We don’t allow expired job postings.» برای پایان اعتبار، راهنما سه گزینه معرفی می‌کند: validThrough در گذشته، حذف صفحه با 404 یا 410، یا حذف دادهٔ JobPosting. این‌ها روش‌های جایگزین پایان اعتبارند و لازم نیست هر سه را هم‌زمان اجرا کنید. اگر صفحه را با JobPosting نگه می‌دارید، تاریخ گذشته را مطابق راهنما کنترل کنید. در روش حذف این داده، خروجی نهایی نباید نسخهٔ دیگری از JobPosting فعال داشته باشد.

validThrough تاریخ انقضاست و قالب آن ISO 8601 است. هنگام ثبت زمان، منطقهٔ زمانی را روشن نگه دارید تا پایان مهلت در رابط کاربری و خروجی ماشینی اختلاف پیدا نکند. تاریخ پایان را از روی حدس نسازید. اگر موقعیت زودتر پر شد، همان رویداد باید چرخهٔ بستن آگهی را فعال کند؛ آینده‌بودن مهلت اولیه دلیل بازبودن واقعی آن نیست.

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

اگر چند بخش سایت دادهٔ شغل تولید می‌کنند، همه را بررسی کنید. ممکن است یک JSON-LD را از افزونه حذف کرده باشید ولی قالب، نسخهٔ دیگری بسازد. در خروجی HTML دنبال نوع JobPosting و تاریخش بگردید؛ فقط شمار بلوک‌ها را نگاه نکنید. شناسهٔ شغل را هم تطبیق دهید تا اصلاح به آگهی دیگری اعمال نشده باشد.

چه زمانی 404، 410 یا ریدایرکت بدهیم؟

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

طبق مستند گوگل دربارهٔ کدهای وضعیت HTTP، نشانی‌های دارای پاسخ 4xx برای ایندکس استفاده نمی‌شوند و نسخه‌های ایندکس‌شده به‌مرور حذف می‌شوند. پاسخ 200 هم تضمین ایندکس نیست؛ صفحهٔ خالی یا شبیه خطا ممکن است soft 404 تشخیص داده شود. از تفاوت 404 و 410، وعدهٔ زمان حذف ثابت یا برتری قطعی برای هر سایت نسازید.

صفحهٔ حذف‌شده می‌تواند طراحی خوانا و راه رسیدن به فرصت‌های فعال داشته باشد، اما وضعیت پاسخ آن را نیز کنترل کنید. ممکن است قالبِ «آگهی پیدا نشد» کد 200 بدهد. در آن صورت، ظاهر صفحه با رفتار سرور هماهنگ نیست. آزمون را با درخواست مستقیم به نشانی قدیمی انجام دهید، نه فقط با دیدن قالب خطا در پیش‌نمایش.

در راهنمای ریدایرکت ۳۰۱، انتقال دائمی و انتخاب مقصد توضیح داده شده است. برای شغل منقضی‌شده، ابتدا معادل‌بودن را ثابت کنید: آیا همان فرصت، همان کارفرما و همان شرایط استخدام به نشانی تازه رفته است؟ اگر جواب منفی است، وجود یک شغل تازه به‌تنهایی دلیل انتقال آگهی بسته نیست.

اگر آگهی مشابهی دوباره منتشر می‌شود، دربارهٔ هویت آن با مسئول محصول تصمیم بگیرید. یک تمدید واقعی با موقعیت جدیدی که شرح شغل یا کارفرمایش تغییر کرده یکسان نیست. برای هر تغییر، شناسه، علت و نسبت با آگهی قبلی را ثبت کنید. پیش از بازگشایی همان رکورد، تأیید کنید درخواست‌های قبلی به کدام دورهٔ استخدام تعلق دارند و صفحه چه زمانی دوباره فعال شده است. این تفکیک، از مخلوط‌شدن سابقهٔ یک استخدام بسته با فرصت تازه جلوگیری می‌کند. این تصمیم را به قاعده‌ای مانند «هر عنوان مشابه به آخرین آگهی برود» نسپارید.

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

تغییر آگهی را چگونه به گوگل اطلاع دهیم؟

برای آگهی شغلی واجد شرایط، نوع اعلان را براساس وضعیت واقعی URL انتخاب کنید. صفحه‌ای که به آرشیو تبدیل شده با صفحه‌ای که کاملاً حذف شده یک حالت ندارد. ابتدا خروجی سایت را اصلاح کنید و بعد اعلان مناسب بفرستید؛ ارسال درخواست به API جای تغییر محتوا، دادهٔ شغلی یا پاسخ سرور را نمی‌گیرد.

در مستند استفاده از Indexing API، URL_UPDATED برای صفحهٔ تازه یا تغییرکرده و URL_DELETED برای درخواست حذف معرفی شده است. پیش از اعلان حذف، نشانی باید 404 یا 410 بدهد یا صفحه دارای noindex باشد. دریافت پاسخ موفق API، مشاهدهٔ تغییر در نتایج را ثابت نمی‌کند. این API مسیر عمومی برای اعلان همهٔ مقالات و صفحات سایت نیست.

برای URL شغلی که قبلاً واجد شرایط بوده و حالا به آرشیو تبدیل شده، سناریوی «تغییر» را از «حذف کامل از ایندکس» جدا پیاده کنید. اگر صفحه با کد 200 باقی است و قرار نیست از نتایج عادی حذف شود، صرف پایان استخدام دلیل ارسال اعلان حذف کامل URL نیست. وضعیت نهایی موردنظر را در پروندهٔ همان آگهی ثبت کنید. «حذف از تجربهٔ مشاغل» و «حذف خود صفحه از نتایج عادی» دو هدف متفاوت‌اند؛ نام هرکدام را در معیار پذیرش بنویسید تا اعلان حذف برای یک صفحهٔ آرشیویِ قرارگرفته در مسیر نگهداری فرستاده نشود.

در مقالهٔ محدودهٔ استفاده از Indexing API گوگل، نوع صفحات مجاز و تفاوت اعلان با نتیجهٔ ایندکس توضیح داده شده است. اجرای آگهی‌های پایان‌یافته باید همین محدودیت را رعایت کند. از افزودن JobPosting غیرواقعی به یک مقاله یا صفحهٔ خدمات برای استفاده از API خودداری کنید؛ این کار نوع محتوا را عوض نمی‌کند.

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

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

چرخهٔ بستن آگهی را چطور در سامانه اجرا کنیم؟

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

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

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

برای مثال، اگر بستن درخواست موفق و به‌روزرسانی سرویس جست‌وجوی داخلی ناموفق بود، رکورد را «تکمیل‌شده» نزنید. همان مرحله را با شناسهٔ آگهی در صف پیگیری نگه دارید و هشدار را به مسئول آن برسانید. تکرار عملیات نیز نباید فرصت بسته را دوباره باز کند یا تاریخ پایان را عوض کند. این رفتار را پیش از اجرای انبوه آزمایش کنید.

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

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

پس از اجرا چه چیزهایی را آزمایش و پایش کنیم؟

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

یک آزمون فرضی را با آگهی JOB-204 در نظر بگیرید. تصمیم نگهداری آرشیو است. معیار قبولی: صفحه باز می‌شود، پیام پایان در بخش نخست دیده می‌شود، درخواست برای همان شغل پذیرفته نمی‌شود و JobPosting فعال باقی نمانده است. این شناسه و نتیجه، نمونهٔ آموزشی هستند؛ آن‌ها را گزارش پروژه یا شاهد رفتار واقعی یک سایت ندانید.

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

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

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

جمع‌بندی

پایان استخدام را به همهٔ خروجی‌های آگهی برسانید و بعد برای URL تصمیم بگیرید. آرشیو باید صریحاً بسته باشد؛ حذف باید پاسخ درست داشته باشد؛ انتقال به مقصد معادل نیاز دارد. وضعیت JobPosting و نوع اعلان گوگل را با همین تصمیم تطبیق دهید و نتیجه را از مسیر واقعی کارجو آزمایش کنید.

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

منابع

• Google Search Central: سیاست JobPosting و پایان اعتبار آگهی
• Google Crawling Infrastructure: رفتار کدهای وضعیت HTTP
• Google Search Central: اعلان به‌روزرسانی و حذف در Indexing API