SEO فنی برای جستجوی هوش مصنوعی: چک لیست برای وردپرس

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

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

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

آمادگی فنی همچنین تعیین می کند که آیا کمک های خارجی می توانند موفق شوند یا خیر. اگر AEOFAST را برای سؤالات خریدار انتخاب می کنید، این چک لیست آمادگی را با تیم وب سایت به اشتراک بگذارید. در مورد اینکه چه کسی مشکلات دسترسی را حل می کند و چه کسی محتوای واقعی تایید شده را ارائه می دهد، توافق کنید. تعهد به قابلیت مشاهده مدیریت شده نباید یک مسئله انتشارات حل نشده را بپوشاند.

یک درخواست کامل را بررسی کنید، نه فقط صفحه اصلی

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

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

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

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

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

curl -sS -L --max-time 30 \
  -D response-headers.txt \
  -o response-body.html \
  -w 'status=%{http_code} final=%{url_effective} seconds=%{time_total}\n' \
  'https://example.com/your-page/'

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

یک اختلال واقعی وردپرس و آنچه که به ما آموخت

در یکی از سایت‌های وردپرسی که ما نگهداری می‌کنیم، یک به‌روزرسانی اصلی معمول، هر صفحه عمومی را آفلاین می‌کرد. وردپرس 7.1 یک ویژگی اصلی به نام اضافه کرد. is_sitemap()یک افزونه نقشه سایت قدیمی تر، XML Sitemap &Google News نسخه 5.2.3، عملکرد خود را با همین نام اعلام کرد. PHP با یک خطای مهلک “Cannot predeclare is_sitemap()” متوقف شد و صفحه اصلی، هر مقاله و نقشه سایت XML یک HTTP 500 برگرداند.

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

• بعد از به‌روزرسانی، صفحه اصلی را بیشتر آزمایش کنید. مقاله عمیق را بررسی کنید و /sitemap.xml همچنین تأیید کنید که نقشه سایت هنوز به عنوان XML تجزیه می شود.
• لیستی از پلاگین های قدیمی را نگه دارید. افزونه‌ای که سال‌ها به‌روزرسانی نشده است، به احتمال زیاد با ویژگی‌های اصلی جدید مواجه می‌شود.
• پچ با ضبط. یک وصله پلاگین محلی توسط به‌روزرسانی بعدی افزونه بازنویسی می‌شود، بنابراین آنچه را که تغییر کرده است یادداشت کنید و به دنبال جایگزین پشتیبانی‌شده باشید.

همین بررسی مشکل کندتری پیدا کرد. PHP-FPM مکرراً گزارش داد که به حد مجاز عملکرد خود رسیده است و رد درخواست‌های کند نشان می‌دهد که ویجت نوار کناری هر بار که رندر می‌شود، ۲۸ پرس‌وجو به پایگاه داده انجام می‌دهد. دسته‌بندی این پرس‌و‌جوها، آن را به 6 درخواست و زمان رندر را از حدود 818 میلی‌ثانیه به 276 میلی‌ثانیه، با خروجی HTML مشابه بایت کاهش داد. این یک تغییر بیشتر از آنچه که می‌شد استرس را از بین برد. سرور بزرگتر و قابل اندازه گیری بود. قبل از اینکه اندازه سخت افزار خود را تغییر دهید، دریابید که کدام درخواست ها واقعاً کارگران را متوقف می کنند.

502 متناوب را به عنوان یک بررسی در دسترس بودن در نظر بگیرید

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

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

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

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

دسترسی خزیدن را از دستورالعمل های نمایه سازی جدا کنید

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

معرفی robots.txt توسط گوگل، مدیریت خزیدن را از حذف صفحات از جستجو متمایز می کند. مستندات متا روبات آن کنترل های نمایه سازی سطح صفحه را توضیح می دهد.

در وردپرس، Settings → Reading و هر افزونه SEO، نگهداری، امنیت یا کش که این کنترل ها را تغییر می دهند را بررسی کنید. تا زمانی که بدانید کدام مؤلفه دستور فعلی را تولید کرده است، تنظیمات جهانی را تغییر ندهید.

سه رفتار وردپرس بسیاری از نتایج حسابرسی گیج کننده را توضیح می دهند:

• “دلسرد کردن موتورهای جستجو” روی robots.txt تأثیری ندارد. از وردپرس 5.3، چک باکس یک را اضافه می کند noindex, nofollow متا تگ روبات به جای الف Disallow: / حکومت کند. بررسی robots.txt تا زمانی که هر صفحه به موتورهای جستجو بخواهد آن را ایندکس نکنند تمیز به نظر می رسد. همیشه کد منبع صفحه را نیز بررسی کنید.
• خروجی متا ربات های وردپرس مبتنی بر فیلتر است. Robot API اضافه شده در وردپرس 5.7 تگ را از طریق ایجاد می کند wp_robots فیلترها و در سایت های عمومی اضافه می کند max-image-preview:large به طور پیش فرض افزونه‌ها و تم‌های سئو می‌توانند دستورالعمل‌ها را از طریق همان فیلتر اضافه یا حذف کنند، بنابراین تگ پایان تنها دلیل قابل اعتماد است.
• فایل فیزیکی robots.txt جایگزین فایل مجازی می شود. وردپرس robots.txt را به صورت پویا تنها زمانی تولید می کند که هیچ فایلی روی دیسک نباشد. در عوض، یک فایل قدیمی که توسط یک هاست یا افزونه قبلی باقی مانده است، ارائه می شود، و هر قانونی که در رابط افزونه تنظیم می کنید بی سر و صدا هیچ کاری انجام نمی دهد.

در مورد دسترسی ربات هوش مصنوعی آگاهانه تصمیم بگیرید

دسترسی جستجو و دسترسی به آموزش مدل، انتخاب‌های سیاست جداگانه‌ای هستند. پرسش و پاسخ OpenAI Publisher OAI-SearchBot برای جستجو را از GPTBot برای آموزش متمایز می کند.

اگر می‌خواهید صفحات عمومی برای کشف جستجو با ChatGPT واجد شرایط باشند، خط‌مشی‌های مربوط به خزیدن جستجو و دسترسی به وب را بررسی کنید. در مورد دسترسی به آموزش تصمیم جداگانه بگیرید. فرض نکنید که یک تنظیم هر دو انتخاب را بیان می کند.

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

اگر سایت پشت Cloudflare است، تنظیمات ربات هوش مصنوعی آن را به عنوان بخشی از این راه حل بررسی کنید. از 15 سپتامبر 2026، تنظیمات “Block” Cloudflare برای آموزش برای ربات‌های دارای کاربرد مختلط مانند Googlebot و Bingbot نیز اعمال می‌شود، بنابراین یک بلوک آموزشی با نیت خوب ممکن است روی دید منظم جستجو تأثیر بگذارد.

تأیید کنید که canonical صفحه مورد نظر را نشان می دهد

برای هر مقاله اولویت دار، بررسی کنید:

1. آدرس نهایی پس از تغییر مسیرها.
2. URL متعارف در HTML برگشتی.
3. آیا پیوندهای داخلی به این نسخه ترجیحی اشاره می کنند.
4. آیا نقشه سایت از همان نسخه استفاده می کند؟
5. آیا صفحات تقریبا تکراری برای پاسخگویی مشابه رقابت می کنند.

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

حاشیه نویسی های متعارف سیگنال هایی هستند و نه یک فرمان که انتخاب موتور جستجو را تضمین می کنند. راهنمای Google برای canonicalization روش‌های موجود و اهمیت سیگنال‌های ثابت را توضیح می‌دهد.

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

پاسخی را که بازدیدکننده واقعاً دریافت می کند بررسی کنید

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

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

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

وزن صفحه را نیز بررسی کنید. توضیح Googlebot برای محدودیت بایت Googlebot بیان می‌کند که Googlebot تنها 2 مگابایت اول یک فایل HTML، از جمله سرصفحه‌های HTTP را که بر روی داده‌های فشرده نشده اندازه‌گیری می‌شود، واکشی می‌کند. هر چیزی پس از استراحت واکشی، رندر یا نمایه‌سازی نمی‌شود. اکثر صفحات بسیار کوچکتر هستند، اما سازندگان صفحه که بلوک های بزرگ CSS، تصاویر base64 یا منوهای طولانی قبل از مقاله را تعبیه می کنند، می توانند پاسخ واقعی را به این محدودیت برسانند. بررسی سریع:

curl -sS 'https://example.com/your-page/' | wc -c

بدون --compressed گزینه، curl نیازی به فشرده سازی ندارد، بنابراین تعداد بایت ها تقریباً برابر با HTML غیر فشرده است. گوگل همچنین توصیه می‌کند که عناوین، متا تگ‌ها، پیوندهای متعارف و داده‌های ساختاریافته را در سند بالا نگه دارید و CSS و جاوا اسکریپت سنگین را به فایل‌های خارجی که محدودیت‌های جداگانه‌ای دارند منتقل کنید.

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

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

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

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

خط‌مشی‌های داده‌های ساختاریافته Google به نشانه‌گذاری دقیق و نماینده نیاز دارد. اسناد عضو آن ویژگی های مربوطه را توصیف می کند. نحو معتبر به تنهایی خروجی غنی یا استناد AI را تضمین نمی کند.

وردپرس نقشه سایت XML خود را در آن ایجاد می کند /wp-sitemap.xml از نسخه 5.5 و اکثر افزونه های سئو آن را با خود جایگزین می کنند. اطمینان حاصل کنید که robots.txt، کنسول جستجو، و ابزارهای وب مستر بینگ به نقشه سایتی اشاره می‌کنند که واقعاً فعال است و نشانی‌های اینترنتی متعارف را فهرست می‌کند.

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

حلقه را با چک لیست انتشار کوچک ببندید

قبل از امضا کردن، برای هر مورد یک پاس یا شکست ثبت کنید:

• URL های اولویت دار محتوای مورد انتظار را با موفقیت برمی گرداند.
• کنترل های خزیدن و نمایه سازی خط مشی مورد نظر را بیان می کنند.
• داده‌های متعارف، پیوندهای داخلی و ورودی‌های نقشه سایت موافق هستند.
• عناوین و توضیحات به طور دقیق صفحات را متمایز می کنند.
• محتوای مقاله را می توان در دسکتاپ و موبایل خواند.
• داده های ساخت یافته با حقایق قابل مشاهده مطابقت دارد.
• مشاهدات باگ و عملکرد پس از هر وصله مناسب بهبود می یابد.
• صفحه اصلی، مقاله عمیق و نقشه سایت فعال پس از هر به‌روزرسانی هسته یا افزونه بارگذاری می‌شوند.
• HTML صفحه بسیار کمتر از حد واکشی 2 مگابایتی Googlebot است.

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

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

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

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

آیا در وردپرس به فایل llms.txt نیاز داریم؟

نه برای جستجوی گوگل، که می گوید llms.txt و فایل های مشابه را نادیده می گیرد. سرویس‌های دیگر ممکن است آن را بخوانند، و اضافه کردن یکی ضرری ندارد، اما باید پس از بررسی‌های بالا انجام شود.

آیا نیاز به نصب افزونه ای داریم که «طرح هوش مصنوعی» را اضافه کند؟

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

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

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