نویسنده: مای محتوا
راهنمای جامع شناسایی و رفع خطای Soft 404 در صفحات محصول فروشگاه اینترنتی؛ بررسی تفاوت Soft 404 با خطای 404 و 410، مشکلات محصولات ناموجود، صفحات خالی، ریدایرکتهای نامرتبط، اختلال جاوااسکریپت و روش عیبیابی در Google Search Console. همراه با جدول تصمیمگیری، مثالهای عملی، دستورات بررسی پاسخ سرور و چکلیست سئوی فنی.
فرض کنید فروشگاه اینترنتی شما ۵۰۰ محصول دارد و تعدادی از آنها از طریق گوگل بازدیدکننده دریافت میکنند. یک روز وارد Google Search Console میشوید و در بخش Page Indexing با وضعیت Soft 404 روبهرو میشوید. وقتی یکی از آدرسهای گزارششده را باز میکنید، سایت ظاهراً مشکلی ندارد؛ هدر، منو و فوتر نمایش داده میشوند و حتی سرور پاسخ موفق HTTP 200 میدهد. پس چرا گوگل این صفحه را مشابه صفحه خطای پیدا نشدن محصول تشخیص داده است؟
پاسخ این است که گوگل فقط به عدد پاسخ سرور نگاه نمیکند. اگر صفحهای با کد موفقیت باز شود، اما محتوای اصلی آن وجود نداشته باشد، پیام خطا نمایش دهد یا هنگام پردازش تقریباً خالی به نظر برسد، ممکن است بهعنوان Soft 404 شناخته شود.
در فروشگاههای اینترنتی، این مشکل میتواند برای محصولات حذفشده، کالاهای ناموجود، صفحات محصول با اطلاعات ناقص، آدرسهای اشتباه، ریدایرکتهای نامرتبط یا صفحاتی که به جاوااسکریپت وابسته هستند اتفاق بیفتد.
رفع خطای Soft 404 در صفحات محصول به معنی تغییر کورکورانه همه پاسخها به ۲۰۰ یا ارسال دوباره همه آدرسها برای ایندکس نیست. ابتدا باید مشخص کنیم آیا محصول واقعاً وجود دارد، به آدرس دیگری منتقل شده، موقتاً ناموجود است یا بهدلیل مشکل فنی برای گوگل درست نمایش داده نمیشود.
در این مقاله با تعریف دقیق Soft 404، تفاوت آن با 404 و 410، علتهای رایج در سایت فروشگاهی، روش بررسی در سرچ کنسول، تست پاسخ HTTP و راهکار مناسب برای هر وضعیت آشنا میشوید. در پایان نیز یک جدول تصمیمگیری، برنامه اجرایی رفع خطا و چکلیست کامل ارائه میکنیم.
Soft 404 وضعیتی است که در آن گوگل تشخیص میدهد یک صفحه از نظر محتوایی شبیه صفحه ناموجود، خالی یا خطادار است، اما سرور پاسخ متناسب با این وضعیت را ارائه نکرده است.
برای مثال، صفحهای با آدرس https://example.com/products/model-123 ممکن است در ظاهر پیام «محصول یافت نشد» نشان دهد، درحالیکه سرور برای همان آدرس پاسخ 200 OK برمیگرداند.
کد ۲۰۰ به معنی موفق بودن پاسخ درخواست است. اما محتوای صفحه اعلام میکند که چیزی برای نمایش وجود ندارد. همین ناسازگاری میتواند باعث تشخیص Soft 404 شود.
در راهنمای رسمی گوگل درباره رفع خطاهای خزش توضیح داده شده که صفحه Soft 404 ممکن است علاوه بر پیام پیدا نشدن، محتوای اصلی نداشته باشد یا بر اثر بارگذاری نشدن فایلهای ضروری و خطاهای برنامه، تقریباً خالی نمایش داده شود.
گوگل همچنین بیان میکند صفحاتی که بهعنوان Soft 404 شناسایی میشوند، ممکن است از نتایج جستوجو کنار گذاشته شوند. این موضوع برای صفحه محصولی که قرار بوده از گوگل مشتری جذب کند اهمیت زیادی دارد.
خطای 404 واقعی یک کد وضعیت HTTP است که سرور آن را برمیگرداند تا اعلام کند منبع درخواستشده پیدا نشده است. در مقابل، Soft 404 یک تشخیص از سوی گوگل درباره ناسازگاری یا بیاعتبار بودن محتوای صفحه نسبت به پاسخ دریافتی است.
| ویژگی | 404 واقعی | Soft 404 |
|---|---|---|
| ماهیت | کد وضعیت HTTP | تشخیص گوگل از وضعیت صفحه |
| پاسخ متداول سرور | 404 Not Found | اغلب 200 OK یا انتقال نامرتبط |
| محتوای صفحه | ممکن است پیام پیدا نشدن داشته باشد | خطا، محتوای خالی یا محتوای نامتناسب |
| تفسیر گوگل | منبع وجود ندارد | صفحه ظاهراً موفق است اما محتوای قابل قبولی ندارد |
| راهحل | بسته به عمدی یا اشتباهی بودن حذف | هماهنگ کردن پاسخ و محتوای واقعی صفحه |
| نیاز قطعی به اصلاح | خیر، اگر حذف عمدی و درست باشد | برای صفحه ارزشمند یا خطای فنی باید بررسی شود |
برای مثال، اگر یک محصول برای همیشه حذف شده و جایگزین مناسبی ندارد، پاسخ 404 میتواند کاملاً صحیح باشد. اما اگر همان صفحه با کد 200 باز شود و فقط بنویسد «محصولی وجود ندارد»، وضعیت فنی مناسب نیست.
نکته مهم: داشتن چند صفحه 404 واقعی بهخودیخود نشانه افت سئو یا جریمه گوگل نیست. گوگل در راهنمای خطاهای 404 توضیح میدهد که آدرسهای ناموجود با پاسخ صحیح 404 عموماً مشکل سئویی برای کل سایت ایجاد نمیکنند.
برای اصلاح درست Soft 404 باید بدانیم هر کد پاسخ چه معنایی دارد و در چه شرایطی مناسب است.
| کد HTTP | معنا | کاربرد مناسب در فروشگاه |
|---|---|---|
| 200 | صفحه با موفقیت ارائه شده است | محصول واقعی با محتوای قابل استفاده |
| 301 | انتقال دائمی | محصول به آدرس جدید یا جانشین واقعاً مرتبط منتقل شده است |
| 308 | انتقال دائمی با حفظ روش درخواست | سناریوی انتقال دائمی در صورت انتخاب مناسب فنی |
| 302 | انتقال موقت | تغییر موقت مقصد، در شرایط واقعاً موقت |
| 404 | صفحه پیدا نشد | محصول یا URL دیگر وجود ندارد و مقصد مرتبطی تعیین نشده |
| 410 | منبع حذف شده است | حذف عمدی و دائمی یک آدرس بدون مقصد جایگزین |
| 500 | خطای داخلی سرور | نشانه مشکل واقعی اجرای برنامه، نه ابزار حذف محصول |
| 503 | عدم دسترسی موقت سرویس | اختلال موقت یا نگهداری برنامهریزیشده با شرایط فنی صحیح |
طبق مستندات رسمی گوگل درباره کدهای پاسخ HTTP، پاسخهای 404 و 410 به سیستمهای گوگل میگویند URL دیگر محتوای قابل ایندکس ندارد. گوگل برای هدف حذف صفحه از ایندکس، آنها را در یک گروه کلی از پاسخهای ناموجود در نظر میگیرد.
بنابراین لازم نیست برای تمام محصولات حذفشده حتماً 410 انتخاب کنید. اگر صفحه واقعاً وجود ندارد، 404 صحیح نیز قابل قبول است. انتخاب میان آنها باید با معنای واقعی وضعیت و ساختار سایت سازگار باشد.
نباید صرف مشاهده چند آدرس Soft 404 نتیجه گرفت گوگل کل فروشگاه را جریمه کرده یا همه رتبهها کاهش خواهند یافت. ابتدا باید مشخص شود کدام صفحات درگیر هستند و آیا آنها اساساً قرار بوده ایندکس شوند یا خیر.
اگر یک صفحه محصول مهم با محتوای ارزشمند بهاشتباه Soft 404 تشخیص داده شود، ممکن است از جستوجو حذف شود و ورودی مربوط به همان URL آسیب ببیند.
در مقابل، اگر چند آدرس ساختگی یا حذفشده با این وضعیت گزارش شدهاند، مسئله اصلی میتواند اصلاح پاسخ HTTP باشد، نه تلاش برای بازگرداندن همه آنها به نتایج گوگل.
همچنین تعداد زیاد صفحات Soft 404 ممکن است منابع خزش را بهطور غیرضروری درگیر کند. گوگل در راهنمای مدیریت بودجه خزش توصیه میکند صفحات Soft 404 شناسایی و اصلاح شوند؛ زیرا ممکن است مجدداً خزش شوند و منابع پردازش را مصرف کنند.
نتیجه مدیریتی: اهمیت خطا را با توجه به تعداد URLها، ورودی و فروش صفحات، علت مشترک آنها و اثرشان بر تجربه مشتری ارزیابی کنید؛ نه فقط با دیدن عدد بزرگ در سرچ کنسول.
یکی از رایجترین علتهای Soft 404 در فروشگاه اینترنتی این است که محصول از پایگاه داده حذف میشود، اما صفحه آدرس آن همچنان با کد HTTP 200 باز میشود.
فرض کنید محصولی با شناسه ۱۵۰ دیگر در فروشگاه وجود ندارد. سرور بهجای برگرداندن 404، قالب عمومی سایت را همراه با متن «محصول یافت نشد» نمایش میدهد.
از دید کاربر مشخص است که محصول حذف شده، اما پاسخ فنی سرور هنوز موفقیت درخواست را اعلام میکند.
راهکار: اگر محصول واقعاً حذف شده و جایگزین مرتبطی ندارد، پاسخ HTTP همان آدرس را به 404 یا در شرایط حذف دائمی، 410 تغییر دهید.
میتوانید برای صفحه 404 طراحی مناسبی داشته باشید؛ شامل پیام روشن، جستوجوی محصولات و لینک دستههای مرتبط. اما وجود این عناصر نباید کد پاسخ را به 200 تبدیل کند.
برای مثال، نمایش دکمه «بازگشت به فروشگاه» در صفحه خطا مفید است، ولی سرور باید همچنان 404 برگرداند.
گاهی محصول در سیستم وجود دارد، اما صفحه آن بدون نام، توضیح، تصویر یا مشخصات اصلی بارگذاری میشود. این مشکل ممکن است به قالب، پایگاه داده یا سرویس دریافت اطلاعات مربوط باشد.
برای مثال، در یک فروشگاه ممکن است نام محصول و قیمت از یک API دریافت شوند. اگر درخواست API ناموفق باشد و برنامه هیچ پیام مناسب یا مدیریت خطایی نداشته باشد، فقط هدر و فوتر باقی میمانند.
گوگل ممکن است چنین صفحهای را بدون محتوای اصلی تشخیص دهد و آن را Soft 404 در نظر بگیرد.
راهکار: قبل از هر تصمیم سئویی، علت خالی بودن محتوای صفحه را رفع کنید. اتصال پایگاه داده، پاسخ API، قالب محصول، منابع JavaScript و خطاهای سرور را بررسی کنید.
اگر محصول واقعی است و صفحه باید در نتایج گوگل حضور داشته باشد، هدف این است که محتوای اصلی دوباره بهدرستی نمایش داده شود و صفحه پس از رفع مشکل پاسخ موفق معتبر دریافت کند.
افزودن چند جمله عمومی فقط برای طولانیتر شدن صفحه، جایگزین برطرف کردن مشکل اصلی نیست.
یکی از اشتباهات مهم این است که هر محصول ناموجود را معادل یک صفحه 404 بدانیم. درحالیکه ممکن است کالا فقط موقتاً از انبار تمام شده باشد و در آینده دوباره عرضه شود.
فرض کنید یک کفش در سایز ۴۲ ناموجود شده، اما اطلاعات محصول، تصاویر و سایر سایزها هنوز در دسترساند. در این وضعیت، حذف کامل صفحه لزوماً تصمیم مناسبی نیست.
اگر محصول واقعی است و صفحه آن همچنان اطلاعات مفیدی دارد، میتوان صفحه را با پاسخ 200 حفظ کرد و وضعیت «ناموجود» را به شکل روشن نمایش داد. در صورت کاربرد، امکان اطلاعرسانی موجود شدن دوباره یا نمایش محصولات مشابه نیز میتواند مفید باشد.
گوگل در راهنمای مدیریت توقف موقت فروش آنلاین توصیه میکند برای محصولات موقتاً ناموجود، در صورت مناسب بودن شرایط، صفحه حفظ و وضعیت موجودی اعلام شود؛ نه اینکه صرفاً به دلیل اتمام موجودی از نتایج جستوجو حذف شود.
نکته مهم: ناموجود بودن یک محصول بهتنهایی خطای Soft 404 نیست. مشکل زمانی ایجاد میشود که صفحه عملاً محتوای محصول را از دست بدهد یا بهجای اطلاعات واقعی، فقط پیام کلی نبود محصول نمایش دهد.
اگر کالایی دیگر تولید نمیشود و احتمال بازگشت آن وجود ندارد، لازم است درباره حفظ، انتقال یا حذف صفحه تصمیم بگیرید.
ممکن است صفحه محصول هنوز اطلاعات فنی ارزشمند، لینکهای خارجی یا بازدیدکننده داشته باشد. در چنین شرایطی حفظ یک صفحه اطلاعاتی واقعی با اعلام توقف تولید میتواند برای کاربران مفید باشد؛ البته محتوای صفحه باید کامل و هدف آن روشن باشد.
اگر محصول جانشین مشخص و واقعاً معادلی دارد، ریدایرکت دائمی به آن مقصد میتواند مناسب باشد.
اما اگر هیچ جایگزین مرتبط یا محتوای مفیدی برای ادامه نگهداری وجود ندارد، پاسخ 404 یا 410 منطقیتر است.
تصمیم را براساس وضعیت واقعی بگیرید: توقف تولید بهتنهایی الزام نمیکند همه صفحات فوراً ریدایرکت شوند. همچنین وجود رتبه قبلی در گوگل دلیل کافی برای هدایت کاربر به محصول نامرتبط نیست.
برخی فروشگاهها برای جلوگیری از مشاهده صفحه خطا، تمام آدرسهای حذفشده را به صفحه اصلی هدایت میکنند.
برای مثال، کاربری روی نتیجه جستوجوی «کفش مدل A سایز ۴۲» کلیک میکند، اما به صفحه اصلی فروشگاه میرسد. این تغییر مقصد با انتظار کاربر ارتباط مستقیمی ندارد.
گوگل در راهنمای رسمی انتقال URLها هشدار میدهد ریدایرکت تعداد زیادی آدرس به مقصدی نامرتبط مانند صفحه اصلی، ممکن است بهعنوان Soft 404 تفسیر شود.
راهکار: اگر محصول واقعاً منتقل شده یا معادل مشخصی دارد، آدرس قدیمی را با 301 به صفحه متناظر هدایت کنید. اگر جایگزین مرتبط وجود ندارد، پاسخ 404 یا 410 بدهید.
ریدایرکت به صفحه دستهبندی نیز فقط زمانی مناسب است که از نظر نیاز کاربر و محتوای مقصد واقعاً قابل دفاع باشد. نباید هر محصول حذفشده را به نزدیکترین دسته عمومی منتقل کرد.
مشکل فقط انتقال به صفحه اصلی نیست. گاهی محصولی حذف میشود و فروشنده آن را به کالایی با نام نزدیک اما مشخصات متفاوت هدایت میکند.
برای مثال، نسخه ۲۵۶ گیگابایتی یک دستگاه حذف شده و آدرس آن به نسخه ۱۲۸ گیگابایتی منتقل میشود، بدون اینکه تفاوت اصلی برای مشتری روشن باشد.
در این حالت، حتی اگر مقصد از نظر موضوع کلی مرتبط باشد، ممکن است نیاز جستوجوی کاربر را بهدرستی پاسخ ندهد.
راهکار: پیش از ریدایرکت، برند، مدل، ظرفیت، اندازه و ویژگی تعیینکننده را مقایسه کنید. اگر محصول جدید جانشین واقعی نسخه قبلی نیست، بهتر است صفحه قدیمی با اطلاعات معتبر حفظ شود یا برحسب شرایط پاسخ مناسب حذف ارائه کند.
همچنین نباید ریدایرکت را صرفاً برای حفظ یک URL دارای کلیک اجرا کنید. انتقال اشتباه ممکن است هم تجربه مشتری و هم درک گوگل از ارتباط صفحات را مختل کند.

در بعضی سایتهای مدرن، بخش مهمی از اطلاعات محصول پس از بارگذاری صفحه و با جاوااسکریپت دریافت و نمایش داده میشود. اگر این فرایند برای Googlebot درست انجام نشود، ممکن است صفحه بدون اطلاعات اصلی دیده شود.
برای مثال، سرور فایل اولیه HTML را با پاسخ 200 ارسال میکند، اما عنوان، قیمت و مشخصات محصول فقط پس از اجرای چند درخواست JavaScript نمایش داده میشوند. اگر یکی از فایلها یا درخواستهای ضروری با خطا مواجه شود، محتوای محصول ممکن است هنگام رندر وجود نداشته باشد.
در راهنمای رسمی JavaScript SEO گوگل، درباره Soft 404 در برنامههای تکصفحهای یا SPA توضیح داده شده است.
راهکار فنی برای صفحات معتبر: از دسترسپذیری منابع، پاسخ صحیح API، مدیریت خطا و نمایش محتوای اصلی در خروجی قابل رندر اطمینان حاصل کنید. در معماریهای مناسب میتوان از رندر سمت سرور یا روشهای سازگار دیگر استفاده کرد.
راهکار فنی برای URL نامعتبر: بهتر است سرور پاسخ واقعی 404 برگرداند. در بعضی معماریهای کاملاً مبتنی بر رندر سمت کاربر، گوگل راهکارهایی مانند هدایت به صفحه دارای پاسخ 404 یا افزودن noindex به صفحه خطای واقعی را نیز توضیح داده است؛ اما این راهکارها نباید بهصورت عمومی جایگزین پاسخ صحیح سرور در تمام URLها شوند.
گاهی صفحه محصول فقط شامل نام کالا، قیمت و چند عنصر عمومی سایت است. این وضعیت لزوماً در همه موارد Soft 404 محسوب نمیشود؛ زیرا کمبود محتوای مفید، تشخیص محتوای تکراری و Soft 404 موضوعات کاملاً یکسانی نیستند.
بااینحال، صفحهای که توضیح اصلی ندارد، تصویر آن بارگذاری نمیشود و اطلاعات بسیار محدودی ارائه میکند، ممکن است در برخی شرایط برای گوگل تقریباً خالی یا نامعتبر به نظر برسد.
راهکار: ابتدا ببینید آیا صفحه واقعاً محصول قابل فروش و اطلاعات معتبر دارد. سپس نام دقیق، مدل، مشخصات فنی، تصاویر، وضعیت موجودی، قیمت و توضیح کاربردی را متناسب با نوع محصول تکمیل کنید.
نباید تصور کرد با افزودن حداقل ۳۰۰ یا ۵۰۰ کلمه، Soft 404 بهصورت خودکار رفع میشود. گوگل برای رفع این خطا تعداد کلمه ثابت تعیین نکرده است. مشکل باید بر اساس محتوای واقعی و شیوه نمایش صفحه برطرف شود.
برای طراحی اصولی صفحه، راهنمای صفحه محصول حرفهای را مطالعه کنید.
در بعضی فروشگاهها، صفحه محصول از چند سرویس مختلف اطلاعات دریافت میکند. ممکن است اطلاعات اولیه از پایگاه داده، قیمت از سرویس قیمتگذاری و موجودی از انبار دریافت شود.
اگر یکی از این سرویسها دچار اختلال شود، برنامه ممکن است بدون مدیریت صحیح خطا یک صفحه ناقص یا خالی با کد 200 تولید کند.
برای مثال، وقتی اتصال پایگاه داده قطع میشود، بهتر نیست سیستم بدون اطلاعات محصول فقط صفحهای سفید با کد موفقیت نمایش دهد.
راهکار: وضعیت APIها، گزارش خطاهای برنامه، پاسخ سرور و محتوای HTML نهایی را بررسی کنید. اگر سرویس موقتاً با اختلال واقعی روبهرو شده است، رفتار فنی باید مطابق ماهیت خطا طراحی شود.
نباید برای خطای موقت سرور، پاسخ 404 دائمی تولید کنید؛ زیرا محصول حذف نشده است. همچنین نمایش دائمی 200 روی صفحه خراب، مسئله را پنهان میکند.
پاسخهای 5xx تکرارشونده نیز خودشان مشکلات مهمی برای خزش ایجاد میکنند. بنابراین مدیریت خطا باید با هدف حفظ دسترسی واقعی و پایداری فروشگاه انجام شود، نه صرفاً تغییر ظاهری کد پاسخ.
بعد از تغییر دامنه، فروشگاهساز یا آدرس محصولات، ممکن است برخی URLهای قدیمی به مقصد اشتباه منتقل شوند.
فرض کنید محصولی در آدرس /products/old-model وجود داشته و اکنون آدرس آن به /products/new-model تغییر کرده است. اگر آدرس قدیمی همچنان با پاسخ 200 و صفحه خالی باز شود، گوگل ممکن است Soft 404 تشخیص دهد.
راهکار درست، ایجاد ریدایرکت دائمی از آدرس قدیمی به صفحه متناظر جدید است؛ مشروط بر اینکه محصول واقعاً منتقل شده باشد.
اگر URL قدیمی هیچ محصول معتبری نداشته و مقصد مرتبطی نیز ندارد، 404 یا 410 مناسبتر است.
توصیه: هنگام مهاجرت فروشگاه، جدول تطبیق آدرسهای قدیمی و جدید تهیه کنید. صفحات محصولات، دستهبندیها، مقالهها و نسخههای دارای تنوع را جدا بررسی کنید.
تغییر دامنه بدون نگاشت صحیح URLها میتواند باعث افزایش خطاهای دسترسی و اختلال در انتقال ورودیهای قبلی گوگل شود.
در بسیاری از فروشگاهها، جستوجوی داخلی و فیلترهای محصولات URLهای جدید تولید میکنند. برای مثال، کاربر ممکن است دسته کفش را با فیلتر رنگ، سایز و قیمت محدود کند.
اگر ترکیب انتخابشده هیچ محصولی نداشته باشد، ممکن است صفحهای با پیام «نتیجهای یافت نشد» ایجاد شود. گوگل در راهنمای رسمی خود، صفحات جستوجوی داخلی خالی را از نمونههای احتمالی Soft 404 معرفی کرده است.
اما نباید تمام صفحات بدون نتیجه را صرفاً برای رفع گزارش به 200 با متن ساختگی تبدیل کرد.
راهکار: مشخص کنید آیا این URL اساساً باید در نتایج گوگل ایندکس شود یا فقط یک حالت تعاملی برای کاربر است. سپس بر اساس ساختار سایت، پاسخ فنی و سیاست ایندکسپذیری آن را طراحی کنید.
برای URLهای واقعاً نامعتبر، پاسخ 404 میتواند مناسب باشد. برای حالتهای فیلتر پویا که بهصورت صفحه کاربردی نگهداری میشوند، ممکن است سیاست کنترل ایندکس متفاوت باشد.
از ثبت تعداد زیادی URL بیارزش و بدون نتیجه در Sitemap خودداری کنید. همچنین برای حل مشکل، همه فیلترها را بدون تحلیل در robots.txt مسدود نکنید؛ زیرا این کار ممکن است مانع مشاهده دستورهای ایندکس یا تشخیص وضعیت واقعی توسط گوگل شود.
گاهی مدیر فروشگاه هر صفحهای را که ایندکس نشده Soft 404 مینامد. درحالیکه گوگل وضعیتهای متفاوتی مانند Crawled - currently not indexed، Duplicate without user-selected canonical و Soft 404 را جدا گزارش میکند.
یک محصول ممکن است کاملاً قابل دسترسی باشد و محتوای واقعی داشته باشد، اما گوگل بهدلیل تکراری بودن یا عوامل دیگر آن را ایندکس نکند. این وضعیت لزوماً Soft 404 نیست.
از سوی دیگر، اگر یک صفحه تقریباً بدون محتوای اصلی باشد و فقط عناصر عمومی قالب را نشان دهد، احتمال تشخیص Soft 404 وجود دارد.
| وضعیت | مسئله اصلی | اولین بررسی |
|---|---|---|
| Soft 404 | محتوا شبیه صفحه ناموجود یا خالی است | پاسخ HTTP و خروجی رندرشده |
| Not found (404) | سرور اعلام میکند URL وجود ندارد | عمدی بودن حذف یا اشتباه بودن آدرس |
| Crawled - currently not indexed | گوگل صفحه را خزش کرده ولی فعلاً ایندکس نکرده است | محتوا، وضعیت ایندکس و سایر سیگنالها |
| Duplicate | گوگل صفحه را نسخه تکراری URL دیگری میداند | Canonical و ارتباط نسخهها |
| Blocked by robots.txt | خزش URL با دستور robots محدود شده است | قواعد robots و هدف واقعی صفحه |
| Server error (5xx) | سرویس در ارائه پاسخ با خطا مواجه شده است | سلامت سرور، برنامه و لاگها |
نتیجه: روش رفع مشکل باید متناسب با همان وضعیت باشد. اصلاح Canonical لزوماً Soft 404 را حل نمیکند و افزایش تعداد کلمات نیز الزاماً مشکل Duplicate یا خطای سرور را برطرف نخواهد کرد.
برای بررسی خطا، ابتدا وارد Google Search Console شوید و Property صحیح فروشگاه را انتخاب کنید.
طبق راهنمای رسمی گزارش Page Indexing، برای بررسی Soft 404 بهتر است تست زنده اجرا و نحوه مشاهده صفحه توسط گوگل کنترل شود.
تفاوت مهم: نتیجه اولیه URL Inspection میتواند مربوط به آخرین نسخه شناختهشده توسط گوگل باشد. در مقابل، Test Live URL برای بررسی وضعیت فعلی صفحه اجرا میشود. بنابراین ممکن است مشکل را امروز اصلاح کرده باشید اما گزارش اصلی همچنان وضعیت خزش قبلی را نشان دهد.
این اختلاف لزوماً به معنی ناموفق بودن اصلاح نیست. باید ابتدا مطمئن شوید تست زنده مشکل را تأیید یا رد میکند و سپس روند خزش مجدد را دنبال کنید.
وقتی URL محصولی با Soft 404 گزارش شده است، فقط به عبارت نهایی وضعیت توجه نکنید. برای یافتن علت واقعی، چند بخش را بررسی کنید.
| بخش بررسی | سؤال اصلی |
|---|---|
| Page fetch | آیا گوگل موفق به دریافت صفحه شده است؟ |
| HTTP response | سرور چه وضعیت واقعی برگردانده است؟ |
| Rendered HTML | آیا نام، مشخصات و محتوای محصول وجود دارند؟ |
| Screenshot | صفحه از دید رندر گوگل چه شکلی دارد؟ |
| Resources | آیا فایلهای اصلی JavaScript و CSS دریافت شدهاند؟ |
| Indexing allowed | آیا محدودیت ایندکس جداگانه وجود دارد؟ |
| Canonical | آیا نسخه اصلی آدرس درست معرفی شده است؟ |
| Last crawl | آخرین بررسی گوگل به چه زمانی مربوط است؟ |
برای مثال، اگر مرورگر شما محصول را کامل نمایش میدهد ولی تصویر رندرشده در تست گوگل فقط یک صفحه سفید است، بهتر است مسیر بارگذاری جاوااسکریپت و دادههای محصول بررسی شود.
اگر گوگل پیام «محصول یافت نشد» را میبیند، باید تشخیص دهید آن پیام واقعی است یا به علت خطای موقت سرویس ظاهر شده است.
همچنین اگر صفحه در نسخه موبایل مشکل دارد، نباید صرف سالم بودن نمایش دسکتاپ نتیجه گرفت گوگل نیز محتوای درست را دریافت میکند.
یکی از روشهای مهم عیبیابی، مشاهده پاسخ HTTP سرور است. این کار کمک میکند مشخص شود URL واقعاً 200، 301، 404 یا کد دیگری برمیگرداند.
در سیستمهای دارای ابزار خط فرمان میتوان از دستور curl استفاده کرد. برای نمونه:
curl -I https://example.com/products/model-123
این دستور با درخواست HEAD سربرگهای پاسخ را بررسی میکند. اما باید توجه داشت که بعضی سرورها پاسخ HEAD و GET را متفاوت مدیریت میکنند.
برای بررسی وضعیت پاسخ درخواست GET میتوانید از دستور زیر استفاده کنید:
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/products/model-123
اگر خروجی 200 باشد، سرور درخواست را موفق اعلام کرده است. اگر همان صفحه در مرورگر فقط پیام پیدا نشدن محصول نشان دهد، باید احتمال Soft 404 را بررسی کنید.
اگر خروجی 404 باشد، سرور اعلام میکند صفحه وجود ندارد. اگر این نتیجه برای محصول واقعی و فعال باشد، مشکل باید اصلاح شود.
برای بررسی ریدایرکت میتوانید ابتدا بدون دنبال کردن مقصد، وضعیت و هدر Location را مشاهده کنید. استفاده از گزینه -L ریدایرکتها را دنبال میکند؛ بنابراین باید میان کد اولیه و کد مقصد نهایی تفاوت بگذارید.
نکته: این دستورات فقط پاسخ فنی را نشان میدهند و بهتنهایی ثابت نمیکنند گوگل صفحه را Soft 404 تشخیص داده است. برای تشخیص کامل باید محتوای قابل مشاهده توسط گوگل و گزارش سرچ کنسول نیز بررسی شوند.
بعد از بررسی پاسخ سرور، باید محتوای واقعی صفحه را کنترل کنید. اگر URL محصول با پاسخ 200 باز میشود، اما عنوان و اطلاعات کالا وجود ندارند، پاسخ موفق لزوماً نشاندهنده سلامت صفحه نیست.
در مرورگر میتوانید محتوای صفحه و ابزارهای توسعهدهنده را بررسی کنید. برای فروشگاههایی که اطلاعات محصول را از API دریافت میکنند، بخش Network مرورگر میتواند خطاهای درخواستها را نشان دهد.
همچنین باید مطمئن شوید عبارتهای خطا مانند «محصول یافت نشد»، «اطلاعات بارگذاری نشد» یا «امکان دریافت محصول وجود ندارد» بهاشتباه در محتوای اصلی محصول فعال نمایش داده نمیشوند.
گاهی متن خطا در قالب صفحه وجود دارد ولی بهصورت مخفی استفاده میشود. صرف وجود چنین متنهایی در کد لزوماً به معنی Soft 404 نیست؛ مهم محتوایی است که گوگل در نهایت پردازش و تفسیر میکند.
اقدام پیشنهادی: یک محصول سالم و یک محصول دارای Soft 404 را از نظر HTML رندرشده، درخواستهای شبکه و پاسخ سرور مقایسه کنید. اختلافهای مشترک میتوانند علت مشکل را مشخص کنند.
استفاده از noindex میتواند به گوگل اعلام کند یک صفحه نباید در نتایج جستوجو حضور داشته باشد. اما این دستور، راهحل عمومی تمام خطاهای Soft 404 نیست.
اگر صفحه محصول واقعی است و میخواهید در گوگل ایندکس شود، افزودن noindex برخلاف هدف شما خواهد بود.
اگر URL واقعاً حذف شده است، پاسخ صحیح 404 یا 410 معمولاً راه روشنتری برای اعلام نبود منبع محسوب میشود.
برای بعضی برنامههای تکصفحهای که امکان ارائه کد HTTP مناسب در مسیرهای پویا وجود ندارد، گوگل در راهنمای JavaScript SEO از روش noindex روی صفحات خطای واقعی نیز نام میبرد. اما این راهکار مربوط به محدودیتهای مشخص معماری است.
نتیجه: قبل از استفاده از noindex، مشخص کنید آیا میخواهید یک صفحه موجود را از نتایج کنار بگذارید یا میخواهید نبود واقعی یک محصول را به سرور و گوگل اعلام کنید. این دو هدف یکسان نیستند.
Canonical به موتور جستوجو کمک میکند نسخه اصلی محتوای مشابه یا تکراری را تشخیص دهد. اما اگر صفحه محصول خالی است یا بهجای اطلاعات کالا پیام خطا نشان میدهد، تغییر Canonical بهتنهایی مشکل را حل نمیکند.
برای مثال، اگر صفحه یک کفش با کد 200 باز میشود ولی هیچ اطلاعاتی ندارد، تنظیم canonical به آدرس خودش باعث ایجاد محتوای واقعی نخواهد شد.
در مقابل، اگر محصول چند URL معتبر و مشابه دارد، باید ساختار نسخه اصلی مطابق اصول سئو بررسی شود.
راهکار: ابتدا وضعیت وجود محصول و محتوای آن را اصلاح کنید. سپس در صورت نیاز به مدیریت نسخههای تکراری، canonical مناسب را تعیین کنید.
همچنین اگر URL قدیمی به آدرس دیگری منتقل شده است، بهتر است ریدایرکت سروری مناسب در نظر گرفته شود. Canonical بهتنهایی جایگزین ریدایرکت دائمی برای تغییر آدرس واقعی محصول نیست.
گاهی پیشنهاد میشود برای حل Soft 404 فقط توضیحات بیشتری به صفحه اضافه کنید. این راهکار ممکن است در یک صفحه واقعی با محتوای بسیار ناکافی مفید باشد، اما برای تمام موارد درست نیست.
اگر محصول حذف شده است، نوشتن چند پاراگراف عمومی روی صفحه ناموجود نباید صرفاً برای گرفتن کد 200 انجام شود.
اگر صفحه باید محصول واقعی را نمایش دهد ولی بهدلیل خطای API خالی شده است، افزودن متن ثابت بدون رفع اختلال نیز مسئله اصلی را حل نمیکند.
اما اگر محصول معتبر است و صفحه اطلاعات ضروری ندارد، تکمیل مشخصات، تصاویر و توضیحات واقعی میتواند کیفیت صفحه را بهتر کند.
اصل مهم: بهجای تلاش برای افزایش مصنوعی تعداد کلمات، اطلاعاتی ارائه کنید که به انتخاب و خرید واقعی مشتری کمک میکنند.
برای مثال، در صفحه یک محصول متغیر باید مشخصات مدل، رنگ، اندازه، موجودی، قیمت و تصویر نسخه انتخابشده روشن باشند.
در فروشگاههایی که محصولات با چند رنگ، سایز یا ظرفیت عرضه میشوند، ممکن است برخی ترکیبها موجود یا حتی قابل تولید نباشند.
برای مثال، یک لباس در رنگ مشکی و سایزهای M و L عرضه میشود، اما یک URL قدیمی برای ترکیب «مشکی، XXL» نیز در سایت وجود دارد.
اگر این ترکیب اصلاً محصول معتبری نیست و صفحه آن فقط پیام خطا دارد، باید ساختار پاسخ و URL بررسی شود.
اما اگر ترکیب XXL محصول معتبری است که موقتاً موجودی آن صفر شده، میتوان اطلاعات همان تنوع را حفظ و ناموجود بودن را بهدرستی نمایش داد.
نکته: وضعیت هر تنوع باید از موجودی کلی مدل تفکیک شود. همچنین آدرسهای تنوع باید به اطلاعات واقعی همان انتخاب برسند، نه به صفحهای که قیمت و تصویر نسخه متفاوتی را نمایش میدهد.
برای مدیریت این موارد، راهنمای محصولات متغیر و چندقیمتی را مطالعه کنید.
اگر صفحه یک محصول معتبر است ولی موجودی آن تمام شده، در صورت استفاده از داده ساختاریافته Product، وضعیت موجودی باید با اطلاعات قابل مشاهده صفحه سازگار باشد.
گوگل در مستندات رسمی Product Structured Data مقدارهایی مانند InStock، OutOfStock، PreOrder و Discontinued را برای توصیف وضعیت عرضه کالا معرفی میکند.
برای مثال، اگر محصول موقتاً ناموجود است، در یک ساختار معتبر میتوان وضعیت https://schema.org/OutOfStock را مطابق واقعیت اعلام کرد.
اما باید میان ناموجود بودن، پیشسفارش و توقف تولید تفاوت وجود داشته باشد. همچنین نباید محصولی که واقعاً قابل خرید نیست با وضعیت InStock معرفی شود.
هشدار: افزودن اسکیما بهتنهایی خطای Soft 404 ناشی از صفحه خالی، محتوای خراب یا ریدایرکت اشتباه را رفع نمیکند. ابتدا محتوای صفحه و پاسخ HTTP باید درست باشند.
نقشه سایت XML به گوگل کمک میکند URLهای مهم و قابل خزش فروشگاه را شناسایی کند. بهتر است URLهایی در Sitemap قرار گیرند که واقعاً برای ایندکس شدن در نظر گرفته شدهاند.
اگر صفحه محصول معتبر است، اطلاعات مفیدی دارد و فقط موقتاً ناموجود شده، ممکن است همچنان مناسب حضور در Sitemap باشد.
اما اگر یک آدرس حذف شده و پاسخ 404 یا 410 میدهد، نباید بهعنوان URL اصلی و قابل ایندکس در نقشه سایت معرفی شود.
همچنین URLهای دارای ریدایرکت دائمی بهتر است در Sitemap اصلی جدید با مقصد نهایی جایگزین شوند.
نکته مهم: حذف یک URL از نقشه سایت بهتنهایی باعث حذف قطعی آن از گوگل نمیشود. اگر صفحه دیگر وجود ندارد، پاسخ HTTP مناسب نیز باید ارائه شود.
پس از اصلاح خطا، نقشه سایت و لینکهای داخلی را بررسی کنید تا به آدرسهای قدیمی و نامعتبر اشاره نکنند.
برای جلوگیری از تصمیم اشتباه، بهتر است نوع مشکل را قبل از اجرای تغییر مشخص کنید.
| وضعیت واقعی محصول | پاسخ پیشنهادی | اقدام اصلی |
|---|---|---|
| محصول موجود و صفحه سالم | 200 | حفظ محتوای واقعی و کنترل ایندکس |
| محصول موجود اما صفحه خالی است | پس از رفع خطا، 200 معتبر | اصلاح قالب، API و رندر محتوا |
| محصول موقتاً ناموجود است | 200، اگر صفحه اطلاعات مفید دارد | نمایش موجودی واقعی و گزینههای مناسب |
| محصول دائماً به URL جدید منتقل شده | 301 یا 308 | انتقال به صفحه متناظر |
| محصول حذف شده و جانشین واقعاً مرتبط دارد | 301 در صورت تصمیم به انتقال دائمی | بررسی همارزی مقصد |
| محصول حذف شده و جایگزین ندارد | 404 یا 410 | اعلام نبود واقعی صفحه |
| URL محصول هرگز معتبر نبوده | 404 | اصلاح لینکهای اشتباه در صورت وجود |
| صفحه خطای موقت سرور دارد | پاسخ واقعی متناسب با اختلال | رفع مشکل سرور و بازیابی سرویس |
| URL فیلتر بدون نتیجه و فاقد هدف ایندکس | وابسته به معماری و هدف URL | طراحی سیاست پاسخ و ایندکسپذیری |
این جدول راهنمای اولیه است و برای همه معماریها حکم فنی یکسان ارائه نمیکند. بهخصوص در فروشگاههای SPA، مسیرهای فیلتر و سیستمهای دارای چند URL برای یک محصول، ممکن است بررسی جزئیتری لازم باشد.
مهمترین اصل: وضعیت واقعی محصول باید با محتوای صفحه و نوع پاسخ سرور هماهنگ باشد.
فرض کنید فروشگاهی ۱۰۰۰ محصول ثبت کرده و در گزارش سرچ کنسول، ۸۰ آدرس دارای Soft 404 مشاهده میکند.
پس از بررسی اولیه مشخص میشود ۳۰ آدرس مربوط به محصولات حذفشده هستند، ۲۰ آدرس بهدلیل خطای قالب بدون محتوای اصلی نمایش داده میشوند، ۱۵ آدرس مربوط به محصولات موقتاً ناموجود هستند که اطلاعات آنها حذف شده و ۱۵ آدرس نیز از مسیرهای قدیمی به صفحه اصلی ریدایرکت میشوند.
این اعداد کاملاً فرضیاند و فقط برای نمایش روش تحلیل استفاده میشوند.
| گروه | تعداد فرضی | اقدام |
|---|---|---|
| محصولات واقعاً حذفشده | ۳۰ | 404 یا 410، مگر وجود جانشین مرتبط |
| صفحات خراب بهدلیل قالب | ۲۰ | اصلاح فنی و بازگرداندن محتوای محصول |
| محصولات موقتاً ناموجود | ۱۵ | حفظ اطلاعات واقعی و نمایش وضعیت ناموجود |
| ریدایرکتهای نامرتبط | ۱۵ | تعیین مقصد مرتبط یا پاسخ حذف صحیح |
در این مثال، اگر مدیر سایت همه ۸۰ URL را به صفحه اصلی ریدایرکت کند، مشکل واقعی را حل نکرده است.
اگر برای همه آدرسها پاسخ 404 قرار دهد نیز ممکن است ۳۵ صفحه محصول معتبر را بیدلیل از دسترس خارج کند.
راهکار درست، تفکیک علتها و اعمال تغییر متناسب با هر گروه است. پس از اصلاح نیز باید نمونههایی از هر گروه با تست زنده و پاسخ سرور بررسی شوند.
پس از انجام اصلاح، ابتدا وضعیت فعلی صفحه را مستقل از گزارش قبلی گوگل بررسی کنید.
اگر محصول فعال است، باید صفحه با محتوای واقعی و پاسخ موفق مناسب در دسترس باشد. اگر حذف شده، باید پاسخ 404 یا 410 بدهد. اگر منتقل شده، باید ریدایرکت به مقصد متناظر برقرار باشد.
سپس برای URLهای مهم از URL Inspection و Test Live URL استفاده کنید.
اگر مشکل از نظر فنی برطرف شده است، میتوانید برای تعداد محدودی از صفحات مهم درخواست بررسی مجدد بدهید. همچنین در صورت وجود نمونههای کافی و اصلاح واقعی علت مشترک، قابلیت Validate Fix در گزارش مربوط میتواند برای پیگیری اعتبارسنجی استفاده شود.
نکته: اعتبارسنجی یا درخواست ایندکس، جایگزین رفع مشکل نیست. همچنین گوگل تضمین نمیکند هر URL اصلاحشده فوراً در نتایج ظاهر شود.
اگر یک URL عمداً حذف شده و اکنون 404 صحیح برمیگرداند، موفقیت فنی به معنی ایندکس شدن دوباره آن نیست؛ بلکه برعکس، انتظار داریم گوگل متوجه نبود صفحه شود.
در مقابل، برای صفحه محصول معتبری که قبلاً بهاشتباه Soft 404 شناخته شده، هدف این است که گوگل محتوای سالم آن را در خزش بعدی ببیند و امکان بررسی ایندکس فراهم شود.
خیر. درخواست دستی ایندکس برای همه آدرسها معمولاً راهکار اصلی نیست و بهخصوص برای URLهایی که واقعاً حذف شدهاند منطقی نیست.
اگر ۵۰۰ آدرس محصول حذفشده دارید، ابتدا باید پاسخ سرور آنها درست باشد. ارسال درخواست ایندکس برای صفحاتی که قرار نیست دیگر وجود داشته باشند، کمکی به بازگشت محتوای واقعی نمیکند.
برای صفحات معتبر و ارزشمند، بعد از اصلاح محتوا و مشکل فنی میتوان از URL Inspection برای تعداد محدودی از URLها استفاده کرد.
برای تعداد زیاد صفحات فعال، اصلاح نقشه سایت، لینکهای داخلی و سلامت ساختار خزش اهمیت دارد.
اصل مهم: ابتدا علت را اصلاح کنید، سپس وضعیت خزش و ایندکس را پیگیری کنید. تکرار درخواست ایندکس بدون تغییر واقعی صفحه، تضمینی برای رفع Soft 404 ایجاد نمیکند.
فهرست نمونه URLهای Soft 404 را از سرچ کنسول بررسی یا استخراج کنید. سپس مشخص کنید چه تعداد از آنها محصول، دستهبندی، جستوجوی داخلی یا مسیر قدیمی هستند.
از هر گروه چند نمونه انتخاب کنید و پاسخ سرور را بررسی کنید. همزمان محتوای واقعی صفحه و نمایش آن برای کاربر را کنترل کنید.
مشخص کنید خطا ناشی از حذف محصول، قالب، API، تغییر URL، موجودی، ریدایرکت یا جاوااسکریپت است. گروهبندی علتها میتواند از اصلاح تکتک URLها بدون رفع ریشه مشکل جلوگیری کند.
صفحات محصولاتی را که واقعاً باید وجود داشته باشند اصلاح کنید. اطلاعات محصول، تصاویر، قیمت و موجودی باید درست بارگذاری شوند.
برای محصولات حذفشده بدون مقصد مرتبط، پاسخ 404 یا 410 تعیین کنید. ریدایرکتهای اشتباه را اصلاح و آدرسهای قدیمی دارای جانشین واقعی را به مقصد متناظر منتقل کنید.
لینکهای داخلی به URLهای نامعتبر را اصلاح کنید. نقشه سایت باید با مجموعه صفحات اصلی و قابل ایندکس هماهنگ باشد.
برای نمونههایی از هر گروه، تست HTTP و URL Inspection را انجام دهید. سپس نتیجه اصلاح، علت و نیاز به پیگیری بعدی را ثبت کنید.
این برنامه یک الگوی عملی اولیه است. اگر مشکل از معماری نرمافزار یا تعداد زیادی صفحه وابسته به جاوااسکریپت باشد، رفع کامل آن ممکن است نیازمند توسعه و آزمایش گستردهتر باشد.

برای کاهش خطاهای فنی صفحات محصول، داشتن ساختاری منظم برای اطلاعات کالا، وضعیت موجودی و آدرسهای فروشگاهی اهمیت دارد. مایتارنما یک سایتساز اختصاصی است که امکانات معرفیشدهای مانند مدیریت محصولات، دستهبندیها، محصولات متغیر و چندقیمتی، گزارش موجودی، ثبت سفارش، درگاه پرداخت، وبلاگ و ساختار مناسب برای فعالیتهای سئو دارد.
این امکانات میتوانند به مدیر فروشگاه کمک کنند اطلاعات محصول و وضعیت فروش آن را در یک محیط مشخص مدیریت کند.
بااینحال باید میان داشتن ساختار فروشگاهی و تضمین رفع خودکار تمام خطاهای Soft 404 تفاوت گذاشت. پاسخ صحیح 404 و 410، مدیریت ریدایرکتهای اختصاصی، نحوه رندر صفحات و کنترل خروجی HTTP به معماری فنی سامانه وابسته هستند.
اگر برای فروشگاه شما کنترل دقیق وضعیت HTTP، ریدایرکت محصولات حذفشده یا بررسی خروجی صفحات در گوگل ضروری است، بهتر است قابلیتهای فنی مربوط را با پشتیبانی بررسی کنید.
در تست رایگان ۱۰روزه مایتارنما میتوانید چند محصول نمونه ثبت کنید، صفحه محصول، موجودی، تنوعها و مسیر خرید را آزمایش کنید و درباره مدیریت URLها و وضعیت محصولات ناموجود سؤال بپرسید.
همچنین برای بررسی ویژگیهای فنی فروشگاه پیش از انتشار، چکلیست تست رایگان فروشگاهساز را مطالعه کنید.
یعنی گوگل صفحه را از نظر محتوایی شبیه صفحه ناموجود، خالی یا خطادار تشخیص داده، درحالیکه پاسخ فنی متناسب با نبود محتوا دریافت نکرده است. این وضعیت در گزارش Page Indexing نمایش داده میشود.
404 یک کد پاسخ واقعی سرور است. Soft 404 تشخیص گوگل درباره صفحهای است که معمولاً با پاسخ موفق یا انتقال نامرتبط ارائه شده اما محتوای آن شبیه صفحه ناموجود است.
مشاهده این وضعیت بهتنهایی به معنی جریمه کل سایت نیست. اما صفحات مهمی که Soft 404 تشخیص داده میشوند ممکن است از نتایج جستوجو کنار گذاشته شوند و تعداد زیاد صفحات خطادار نیز میتواند منابع خزش را درگیر کند.
نه لزوماً. اگر محصول موقتاً ناموجود است و صفحه اطلاعات واقعی و مفیدی دارد، میتوان صفحه را با پاسخ 200 حفظ و موجودی را بهدرستی اعلام کرد. اگر کالا برای همیشه حذف شده و جایگزین ندارد، 404 یا 410 مناسبتر است.
هر دو برای اعلام نبود صفحه قابل استفادهاند. 404 یعنی منبع پیدا نشده و 410 به حذف آن اشاره میکند. گوگل هر دو را در گروه پاسخهای ناموجود در نظر میگیرد؛ بنابراین انتخاب باید با معنای واقعی وضعیت و سیاست فنی سایت هماهنگ باشد.
خیر. گوگل هشدار میدهد ریدایرکتهای نامرتبط میتوانند Soft 404 ایجاد کنند. فقط زمانی ریدایرکت کنید که مقصد واقعاً همان محصول یا جانشین مرتبط آن باشد.
در بعضی صفحات معتبر که محتوای اصلی ناقص است، تکمیل اطلاعات واقعی ممکن است مفید باشد. اما اگر محصول حذف شده یا صفحه بهدلیل خطای فنی خالی است، افزودن متن عمومی مشکل اصلی را حل نمیکند.
میتوانید پاسخ سرور را با ابزارهایی مانند curl یا ابزارهای بررسی HTTP مشاهده کنید. برای تشخیص Soft 404 باید در کنار کد پاسخ، محتوای صفحه و وضعیت گزارششده در Google Search Console را نیز بررسی کنید.
ممکن است مشکل مربوط به خزش قبلی، خطای موقت سرور، بارگذاری نشدن منابع، اختلال جاوااسکریپت یا تفاوت رندر صفحه باشد. نتیجه آخرین خزش را با Test Live URL مقایسه کنید.
خیر، این کار راهکار عمومی نیست. اگر صفحه واقعی باید ایندکس شود، noindex برخلاف هدف است. اگر محصول حذف شده، پاسخ صحیح 404 یا 410 معمولاً مناسبتر است. در بعضی معماریهای SPA راهکارهای دیگری نیز وجود دارند.
اگر مشکل اصلی خالی بودن محتوا یا پیام خطا باشد، خیر. Canonical برای مدیریت نسخه اصلی صفحات مشابه کاربرد دارد و جایگزین محتوای واقعی یا پاسخ درست سرور نیست.
ممکن است ترکیب فیلتر هیچ محصولی نداشته باشد و صفحه با پاسخ 200 فقط پیام نبود نتیجه نمایش دهد. باید هدف آن URL، پاسخ مناسب و سیاست ایندکسپذیری آن بررسی شود.
از گزارش Pages در بخش Indexing، وضعیت Soft 404 را انتخاب کنید. سپس URL نمونه را با URL Inspection و Test Live URL بررسی و در صورت دسترسی، تصویر و محتوای رندرشده را مشاهده کنید.
زمان ثابتی وجود ندارد. گوگل باید URL را دوباره خزش و پردازش کند. ممکن است تست زنده سالم باشد اما گزارش اصلی تا زمان پردازش جدید همچنان وضعیت قبلی را نمایش دهد.
خیر. ابتدا علت فنی را برطرف کنید. درخواست ایندکس برای تعداد محدودی از صفحات معتبر و مهم میتواند مفید باشد؛ اما برای صفحات واقعاً حذفشده یا تعداد زیادی URL نامعتبر ضروری نیست.
خیر. دلایلی مانند محتوای تکراری، noindex، محدودیت خزش، خطای سرور یا وضعیت Crawled - currently not indexed نیز ممکن است وجود داشته باشند. باید علت دقیق را در گزارش سرچ کنسول بررسی کرد.
پاسخ سؤال خطای Soft 404 در صفحات محصول چیست و چگونه برطرف میشود؟ به یک تغییر ساده در تنظیمات سئو محدود نیست. این خطا زمانی گزارش میشود که گوگل صفحهای را شبیه محتوای ناموجود یا خالی تشخیص دهد، درحالیکه پاسخ فنی متناسبی دریافت نکرده است.
برای رفع آن باید ابتدا مشخص شود محصول واقعاً وجود دارد، موقتاً ناموجود است، برای همیشه حذف شده، به آدرس جدید منتقل شده یا بهدلیل مشکل قالب و جاوااسکریپت درست نمایش داده نمیشود.
اگر صفحه واقعی و ارزشمند است، باید محتوای آن سالم و قابل دسترسی باشد. اگر آدرس برای همیشه حذف شده و مقصد مرتبطی ندارد، پاسخ 404 یا 410 مناسب است. اگر محصول منتقل شده، ریدایرکت دائمی به صفحه متناظر میتواند ارتباط آدرس قدیمی و جدید را حفظ کند.
همچنین باید از هدایت همه آدرسهای حذفشده به صفحه اصلی، افزودن متن ساختگی، استفاده بیدلیل از noindex و تکرار درخواست ایندکس بدون رفع علت اصلی خودداری کرد.
در پایان، گزارش Page Indexing و ابزار URL Inspection کمک میکنند نتیجه اصلاح را بررسی کنید؛ اما حذف یک خطا از گزارش به معنی افزایش قطعی رتبه نیست و ایندکس صفحات معتبر نیز تضمین نمیشود.
اصل کلیدی سئوی فنی فروشگاهی این است: اگر محصول وجود دارد، اطلاعات واقعی آن را با پاسخ درست نمایش دهید؛ اگر منتقل شده، مسیر مرتبط ارائه کنید؛ و اگر دیگر وجود ندارد، نبود آن را صادقانه با کد HTTP مناسب اعلام کنید.
اگر قصد دارید فروشگاه اینترنتی خود را با مدیریت منظم محصولات، موجودی و صفحات فروشگاهی راهاندازی کنید، میتوانید امکانات سایتساز مایتارنما و دوره تست رایگان ۱۰روزه آن را بررسی کنید. پیش از انتشار گسترده محصولات نیز بهتر است رفتار صفحات فعال، ناموجود و حذفشده را آزمایش کنید تا مشکلات فنی قابل پیشگیری، مانع جذب مشتری از گوگل نشوند.
برای طراحی سایت اختصاصی کسبوکارتان، همین حالا مشاوره رایگان دریافت کنید.
نام و شماره را بگذارید تا با شما تماس بگیریم.
دیگر محتوا های مرتبط را بخوانید