۲۵۹۱ بایت کد خالی؛ دلیل نامرئی شدن فروشگاه‌های مدرن برای هوش مصنوعی

تصور کنید تمام تلاش‌های شما برای سئو و جذب مشتری، در برابر قدرتمندترین موتورهای هوش مصنوعی جهان به ۲۵۹۱ بایت کد بی‌معنی تبدیل شود. این دقیقاً اتفاقی است که برای یک فروشگاه لوازم حیوانات خانگی در بالی رخ داد؛ سایتی که برای انسان‌ها و ابزارهای سئو بی‌نقص بود، اما برای عامل‌های هوش مصنوعی عملاً وجود نداشت. در واقع، وقتی موتورهای پیشرفته AI سعی کردند این سایت را بخزند، تنها با یک تکه کد کوچک روبرو شدند که باعث شد این کسب‌وکار برای ایجنت‌های اکتشاف AI کاملاً نامرئی شود.

این شکست فنی، شکافی عمیق در توسعه وب مدرن را برملا می‌کند. اکثر فروشگاه‌های کوچک در سال ۲۰۲۶ از معماری‌های مشابهی استفاده می‌کنند: یک اپلیکیشن تک‌صفحه‌ای (SPA) با Vite و React در بخش فرانت‌اند و یک API با Django در بک‌اند. این ساختار برای نمایش محتوا، کاملاً به مرورگر وابسته است تا ابتدا جاوااسکریپت را اجرا کند و سپس محتوا را روی صفحه بنشاند. در این مدل، تا زمانی که کد JS اجرا نشود، هیچ متنی برای خواندن وجود ندارد.

ابزارهای استاندارد سئو مانند Screaming Frog، Sitebulb و اکثر سرویس‌های SaaS تحلیل سایت، از مرورگرهای بدون سر (Headless Browsers) استفاده می‌کنند که منتظر می‌مانند تا اپلیکیشن Mount شود و جاوااسکریپت اجرا گردد. آن‌ها DOM نهایی را می‌خوانند و گزارش می‌دهند که سایت سالم و دارای ساختاری مناسب است. اما عامل‌های بازیابی (Retrieval Agents) — از جمله GPTBot، OAI-SearchBot، ClaudeBot و PerplexityBot — جاوااسکریپت را اجرا نمی‌کنند. این ربات‌ها برای بهینه‌سازی هزینه و افزایش سرعت در سطح وسیعی از وب طراحی شده‌اند؛ بنابراین آن‌ها فقط سند HTML خام را دریافت کرده و بلافاصله به سراغ لینک بعدی می‌روند.

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

شکست خاموش رندرینگ سمت کاربر (Client-Side Rendering)

به نقل از گزارش منتشر شده توسط 2pizza.team، پاسخ خام سرور این فروشگاه تنها یک پوسته خالی از اپلیکیشن تک‌صفحه‌ای بود. در این ۲۵۹۱ بایت، فقط یک تگ عنوان (Title)، یک div ریشه (Root) و یک تگ اسکریپت وجود داشت. هیچ اثری از محتوای محصولات، اطلاعات ارسال، آدرس‌ها یا ساعات کاری نبود. هر کلمه‌ای که در صفحه «درباره ما» نوشته شده بود، پشت یک بسته جاوااسکریپت پنهان شده بود که باید ابتدا اجرا می‌شد تا محتوا ظاهر شود.

از آنجا که سایت برای تمام لینک‌ها کد وضعیت HTTP 200 (موفق) برمی‌گرداند و فایل robots.txt اجازه دسترسی به تمام ایجنت‌ها را می‌داد، تمام چراغ‌های هشدار ابزارهای نظارتی سبز بودند. هیچ زنجیره ریدایرکتی وجود نداشت، تگ‌های noindex دیده نمی‌شد و هیچ خطای سروری ثبت نشده بود. شکست در سکوت کامل رخ داد؛ هیچ صفحه خطایی یا هشدار کنسولی در استک فنی وجود نداشت تا مالک سایت را متوجه شود که محتوای او برای هوش مصنوعی مفقود شده است.

شکاف بین رندرینگ و دریافت خام

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

در عمل، یک امتیاز کامل در ممیزی سئو (SEO Audit) هیچ چیزی درباره‌ی قابلیت رؤیت در AI برای یک سایت رندرینگ سمت کاربر به شما نمی‌گوید. تنها بررسی که اهمیت دارد، بدنه پاسخ خام (Raw Response Body) پیش از اجرای هرگونه جاوااسکریپت است. یک سایت می‌تواند در گوگل که قابلیت رندرینگ دارد رتبه قابل قبولی داشته باشد، اما در پاسخ‌های هوش مصنوعی که عمدتاً رندر نمی‌کنند، کاملاً غایب باشد.

تله محتوای تکراری (Duplicate Content)

تحلیل‌ها نشان داد که این سایت در تله «محتوای تکراری» نیز افتاده بود که وضعیتی حتی وخیم‌تر بود: ۱۱۰ لینک موجود در نقشه سایت (Sitemap)، از نظر بایت‌های خام دقیقاً یکسان بودند. چون اپلیکیشن تک‌صفحه‌ای برای هر مسیری یک پوسته (Shell) یکسان می‌فرستاد، صفحه کاتالوگ، هر دسته‌بندی و هر کارت محصول، از دیدگاه یک خزنده، دقیقاً همان سند صفحه اصلی بود.

• متادیتای یکسان: تمام ۱۱۰ صفحه، یک عنوان و یک توضیحات (Description) کاملاً مشابه داشتند.
• فقدان ساختار: هیچ تگ h1 در HTML خام وجود نداشت.
• سیگنال‌های متناقض: تگ‌های Canonical به آدرس‌های متفاوتی اشاره می‌کردند که به سیستم‌های AI سیگنال می‌داد این صفحات صرفاً قالب‌های تکراری (Boilerplate) هستند.

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

چرا ابزارهای رندرینگ این مشکل را نمی‌بینند؟

این یافته‌ای است که یک ابزار رندرینگ به دلیل ساختار فنی‌اش نمی‌تواند تولید کند. در یک مرورگر بدون سر، هر یک از آن ۱۱۰ لینک، روتر را فعال کرده، داده‌های مربوط به خود را فراخوانی می‌کند و صفحه‌ای متمایز با عنوان خاص خود را رسم می‌کند. ابزار سئو گزارش می‌دهد که ۱۱۰ صفحه منحصربه‌فرد با وضعیت سالم وجود دارد. تنها یک «دریافت خام» (Raw Fetch) است که نشان می‌دهد یک سند واحد ۱۱۰ بار تکرار شده است.

تأثیر واقعی بر درآمد

تأثیر این موضوع بر درآمد کاملاً ملموس بود. وقتی سایت با مجموعه‌ای از پرامپت‌های خرید واقعی — مانند «بهترین فروشگاه‌های آنلاین لوازم حیوانات در بالی با قابلیت ارسال» — تست شد، نام این برند حتی یک بار هم در پاسخ‌های بازیابی سه موتور مختلف ذکر نشد. پاسخ‌ها خالی نبودند، بلکه از رقبای محلی، لیست‌های بازار در Shopee، اپلیکیشن‌های ارسال مانند Grab و Gojek و راهنمای کلی مهاجران در بالی جمع‌آوری شده بودند.

این رقبا لزوماً به دلیل داشتن محصولات بهتر برنده نشدند، بلکه به این دلیل پیروز شدند که HTML قابل خواندن را به خزنده‌هایی ارائه می‌دادند که قادر به اجرای جاوااسکریپت نبودند. وقتی مستقیماً نام برند از ChatGPT پرسیده شد، مدل صراحتاً اعلام کرد که سایت مذکور سمت کاربر (Client-side) رندر می‌شود و جزئیات «درباره ما» و «تماس با ما» در سمت مدل بارگذاری نشده است. همچنین گزارش داد که هیچ ردپای مستقلی از این کسب‌وکار در هیچ جای دیگر وب پیدا نکرده است.

اهمیت سوابق موجودیت (Entity Records)

ممیزی همچنین فاش کرد که این کسب‌وکار فاقد ثبت در Google Maps است. برای یک سرویس ارسال محلی، این یک شکست بحرانی است. ثبت در نقشه، همان «سند شناسایی موجودیت» است که نتایج نقشه، Local Packها، سایت‌های تجمیع‌کننده و پاسخ‌های پایین‌دستی AI برای تأیید واقعی بودن کسب‌وکار و صحت مکان فعالیت آن به آن تکیه می‌کنند. اصلاح HTML به مدل چیزی برای خواندن می‌دهد، اما ثبت در نقشه به مدل «دلیلی برای باور کردن» وجود این کسب‌وکار می‌دهد.

راهکار فنی دو لایه

برای حل این مشکل بدون انتقال سایت به یک فریم‌ورک جدید — که محدودیت اصلی مشتری بود — تیم فنی یک استراتژی دو لایه را اجرا کرد:

لایه اول: تزریق محتوای واقعی در پوسته. توضیحات واقعی کسب‌وکار، مناطق ارسال، جزئیات تماس و داده‌های ساختاریافته JSON-LD (شامل موجودیت Organization و PetStore به همراه مناطق تحت پوشش) مستقیماً داخل فایل index.html قرار گرفتند. این کار تضمین می‌کند که اولین بایت‌های پاسخ سرور حاوی داده‌های معنادار باشد.

این اقدام «پنهان‌کاری» (Cloaking) نیست، زیرا سرور تنها یک فایل index.html دارد و هم ربات و هم انسان دقیقاً همان بایت‌ها را دانلود می‌کنند. تنها تفاوت این است که مرورگر انسان پس از دریافت، جاوااسکریپت را اجرا می‌کند. برای موفقیت این روش، محتوای استاتیک باید صادقانه باشد و با آنچه اپلیکیشن رندر می‌کند مطابقت داشته باشد؛ در واقع این اصلاح به عنوان یک «بهبود پیش‌رونده» (Progressive Enhancement) تلقی می‌شود و نه یک ترفند سئو.

لایه دوم: پیش‌رندرینگ در زمان ساخت (Build-Time Prerendering). اسکریپتی اضافه شد که پس از فرآیند Build اجرا می‌شود. این اسکریپت API را فراخوانی کرده و برای کاتالوگ و هر کارت محصول، HTML استاتیک واقعی می‌نویسد.

• صفحات منحصربه‌فرد: هر صفحه تولید شده اکنون دارای عنوان، توضیحات و تگ h1 منحصربه‌فرد خود است.
• داده‌های خرید: داده‌های ساختاریافته محصول با فیلدهای خاصی که پاسخ‌های Shopping AI به آن‌ها نیاز دارند، گنجانده شد.
• اصلاح نقشه سایت: اسکریپت یک نقشه سایت واقعی در دایرکتوری dist می‌نویسد. این کار باگ دومی را حل کرد که در آن مسیر fallback اپلیکیشن SPA، درخواست‌های sitemap.xml را با همان پوسته HTML پاسخ می‌داد؛ به این معنی که خزنده‌ها اصلاً نقشه سایت واقعی دریافت نمی‌کردند.

اندازه‌گیری نتایج

تغییرات فنی منجر به افزایش قابل توجه داده‌های ارسالی شد. حجم صفحه اصلی از ۲۵۹۱ بایت پوسته خالی به ۶.۹ کیلوبایت HTML معنادار افزایش یافت. صفحات محصول اکنون به جای قالب تکراری صفحه اصلی، مارک‌آپ منحصربه‌فرد خود را ارائه می‌دهند و مسیر نقشه سایت به جای صفحه HTML، یک sitemap معتبر برمی‌گرداند. داده‌های Organization و PetStore به همراه مناطق ارسال اکنون پیش از اجرای هر اسکریپتی در دسترس هستند.

با این حال، تیم فنی اشاره می‌کند که تأثیر واقعی بر پاسخ‌های AI هنوز اندازه‌گیری نشده است. سیستم‌های AI دیدگاه خود را درباره یک سایت طبق برنامه زمانی خودشان به‌روز می‌کنند و بازه زمانی واقع‌بینانه برای اینکه یک خزش مجدد (Re-crawl) به تغییر در پاسخ‌ها منجر شود، تقریباً ۴ تا ۸ هفته است. هر کسی که ادعا کند تغییرات در یک هفته اعمال شده، احتمالاً در حال توصیف یک نتیجه «جستجوی زنده» (Live-search) است و نه بازیابی از حافظه مدل.

گام بعدی شما: چگونه سایت خود را در ۱۰ ثانیه چک کنید؟

اگر سایتی دارید که سمت کاربر رندر می‌شود، می‌توانید قابلیت رؤیت خود را با یک دستور ترمینال چک کنید تا ببینید یک خزنده غیررندرکننده چه چیزی دریافت می‌کند:

curl -A GPTBot https://yoursite.com | wc -c

اگر عدد خروجی در محدوده چند هزار بایت (عدد پایین) است، پاسخ را باز کنید و به دنبال جمله‌ای بگردید که یک مشتری بتواند آن را تشخیص دهد. اگر چنین جمله‌ای وجود ندارد، سایت شما احتمالاً برای AI نامرئی است و هیچ استراتژی محتوایی تا زمانی که بایت‌های خام اصلاح نشوند، شما را به پاسخ‌های AI نخواهد رساند.

برای کسانی که ترجیح می‌دهند از ترمینال استفاده نکنند، یک اسکن رایگان در مسیر /geo/scan در دسترس است تا گزارش دهد چهار خزنده اصلی AI چه چیزی دریافت می‌کنند. یک ممیزی کامل در /geo شامل خزش سراسری نقشه سایت و پنل تست پرامپت‌های خرید است.

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