لایت‌هاوس گوگل استانداردهای جدیدی برای پیمایش عامل‌های هوش مصنوعی تعریف کرد

اگر توسعه‌دهنده‌ی یک وب‌سایت تجاری هستید، احتمالاً در گزارش جدید Lighthouse با یک پرچم قرمز در دسته‌بندی Agentic Browsing مواجه می‌شوید. این ارزیابی آزمایشی که در مه ۲۰۲۶ در نسخه ۱۳.۳ عرضه شد، تعیین می‌کند که آیا یک عامل هوش مصنوعی می‌تواند بدون شکست خوردن، صفحه شما را بفهمد و در آن عملیات انجام دهد یا خیر.

در حال حاضر این بخش نمره‌ای بین ۰ تا ۱۰۰ نمی‌دهد و فقط وضعیت هر مورد را «پاس» یا «فیل» اعلام می‌کند. با این حال، ویژگی‌های آزمایشی در Lighthouse معمولاً به استانداردهای پیش‌فرض تبدیل می‌شوند؛ یعنی به‌زودی مشتریان شما می‌پرسند چرا گزارش‌هایشان قرمز است. منطقی است که همین حالا و در حالی که هزینه پیاده‌سازی پایین است، این الزامات را یاد بگیرید.

این تغییر در حالی رخ می‌دهد که وب از مکانی برای «خواندن انسان‌ها» به مکانی برای «اجرای وظایف توسط عامل‌ها» تبدیل می‌شود. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، زیرساخت‌های قدیمی باید با نیازهای جدید سازگار شوند. سال‌ها بود که دسترسی‌پذیری (Accessibility) برای برخی توسعه‌دهندگان یک قابلیت «اضافی» بود، اما اکنون این موضوع به رابط کاربری اصلی برای هوش مصنوعی تبدیل شده است. اگر یک صفحه‌خوان (Screen Reader) نتواند سایت شما را پیمایش کند، احتمالاً یک عامل هوش مصنوعی هم نمی‌تواند.

چارچوب ارزیابی عامل‌ها

به نقل از مستندات گوگل، این ارزیابی شامل چهار بررسی مشخص است. اولین مورد، فایل llms.txt است. ریشهٔ دامنه شما باید یک فایل متنی ساده با فرمت Markdown در آدرس https://yourdomain.com/llms.txt داشته باشد.

برای پاس کردن این مرحله، فایل باید واقعاً کاربردی باشد. Lighthouse اگر فایل فاقد تگ H1 باشد، خیلی کوتاه باشد یا لینکی نداشته باشد، آن را رد می‌کند. یک نسخه حداقلی باید شامل موارد زیر باشد:

• یک H1 واحد (مثلاً # Acme Tools)
• یک خلاصه تک‌خطی از کسب‌وکار
• لینک‌های واقعی به صفحات اصلی مانند کاتالوگ محصولات، صفحه جست‌وجو یا بخش پشتیبانی

قرار دادن یک نقشه سایت (Sitemap) کامل در اینجا باعث شکست در ارزیابی می‌شود؛ عامل‌ها به یک نقشه دست‌چین شده از نقاط ورود نیاز دارند.

دسترسی‌پذیری و پایداری بصری

دومین مورد، درخت دسترسی‌پذیری (Accessibility Tree) است. این حیاتی‌ترین بخش است چون عامل‌ها از طریق این درخت صفحه شما را می‌خوانند. این بررسی تضمین می‌کند که هر عنصر تعاملی یک نام برنامه‌ریزی‌شده داشته باشد و روابط والد/فرزندی درست باشند.

برای موفقیت در این بخش، باید بهداشت دسترسی‌پذیری را رعایت کنید:

• از عناصر بومی HTML مانند <button> و <a> به‌جای تگ‌های <div> با هندلرهای کلیک استفاده کنید.
• برای دکمه‌هایی که فقط آیکون دارند، aria-label قرار دهید.
• مطمئن شوید هر <div> که نقش دکمه دارد، قابلیت فوکوس و نام داشته باشد.

سومین مورد، جابه‌جایی cumulative layout shift یا همان CLS است. اگرچه این یک معیار استاندارد وب است، اما برای عامل‌ها حیاتی است؛ زیرا آن‌ها اغلب بر اساس عکس‌های لحظه‌ای از صفحه، روی مختصات خاصی کلیک می‌کنند. اگر صفحه در حین انجام یک وظیفه تغییر شکل دهد، عامل درست مثل یک انسان دچار کلیک اشتباه می‌شود. پایداری لایوت یعنی اتوماسیون قابل‌اعتماد. برای پاس کردن این مرحله، فضای تصاویر را با width/height رزرو کنید و از تزریق محتوا به بالای محتوای موجود بپرهیزید.

پیاده‌سازی WebMCP

در نهایت، این ارزیابی WebMCP (Model Context Protocol) را معرفی می‌کند. این تنها بررسی است که صرفاً به وبِ عامل‌محور اختصاص دارد. این پروتکل تمام ابزارهای ثبت‌شده در صفحه را شناسایی کرده و اعتبار معنایی inputSchema آن‌ها را بررسی می‌کند.

ابزارها به دو روش قابل ارائه هستند:

• API اعلامی HTML
• روش دستوری از طریق navigator.modelContext.registerTool()

به عنوان مثال، یک ابزار جست‌وجوی محصول باید یک رشته (string) برای عبارت جست‌وجو و یک عدد برای حداکثر قیمت تعریف کند. اگر از فرم‌های حاشیه‌نویسی‌شده استفاده کنید، Lighthouse بررسی می‌کند که این حاشیه‌ها با طرحواره (Schema) مورد انتظار مطابقت داشته باشند.

طبق گزارش‌های فنی، توسعه‌دهندگان باید از تشخیص ویژگی (Feature Detection) استفاده کنند، چون navigator.modelContext در حال حاضر در مرحله آزمایش Chrome 149 است و WebKit رسماً با آن مخالفت کرده است. این رویکرد تضمین می‌کند که اگر استاندارد متوقف شد، چیزی از دست ندهید.

نکته کلیدی این است که این ابزارها باید پوشش‌های نازکی روی هندلرهای UI موجود باشند. ابزار search_products شما باید دقیقاً همان تابعی را صدا بزند که رابط کاربری جست‌وجوی شما استفاده می‌کند. اگر ابزار WebMCP عملی را انجام دهد که UI اصلی نمی‌تواند، یک «منبع حقیقت» دوم ایجاد می‌شود که در نهایت باعث تداخل و شکست سیستم می‌گردد؛ این دقیقاً همان نقد تکراری است که WebKit مطرح کرده است.

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

برای یک صاحب کسب‌وکار، این یعنی بدهی فنی ناشی از دسترسی‌پذیری ضعیف، دیگر فقط یک ریسک قانونی نیست، بلکه در اقتصادِ عامل‌محور، یک عامل کاهش نرخ تبدیل (Conversion Killer) است.

اگر می‌خواهید این روند را خودکار کنید، ابزارهایی مانند Latch (یک اسکریپت متن‌باز MIT) می‌توانند فرم‌های جست‌وجو و سبد خرید فعلی شما را به ابزارهای معتبر WebMCP تبدیل کنند. با این حال، برد بلندمدت در گرو پاک‌سازی HTML و پایدار کردن لایوت است.

گام بعدی شما

• همین امروز یک فایل /llms.txt دست‌چین شده ایجاد کنید تا نقطه شروع روشنی برای عامل‌ها فراهم کنید.
• عناصر تعاملی سایت را بررسی کنید تا مطمئن شوید در درخت دسترسی‌پذیری قرار دارند.
• اگر از Chrome 149 استفاده می‌کنید، قابلیت‌های WebMCP را در محیط آزمایش‌شده تست کنید.

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