اگه چند سالی هست با سیستم‌های مدیریت محتوا سروکار دارید، احتمالاً این صحنه برایتان آشناست: یه مشکل ساده سئویی پیدا می‌کنید، تیکت می‌زنید و جواب می‌آید که باید دولوپر روش کار کند. سالی میلز، مشاور سئوی استرالیایی و مدیر Sally Mills Consulting، بعد از سال‌ها تجربه به‌عنوان سئوی داخلی، مشاور و دولوپر وب به این جمع‌بندی رسیده که اکثر CMS ها هنوز پایه‌ای‌ترین چیزها را ندارند و صنعت سئو مدام همان تیکت‌های قدیمی را دوباره می‌فرستد. او فهرستی از حداقل‌های لازم برای سئو در CMS نوشته که با نگاه وبمستر ایرانی مرورش می‌کنیم.
حداقل‌هایی که هر CMS برای سئو باید داشته باشد
میلز می‌گه هر هفته به سیستم‌های شناخته‌شده‌ای برمی‌خوره که چیزی ندارند که او حسابش می‌کنه استاندارد پایه. نمونه‌هایش عجیب‌اند: امسال روی سه سیستم مختلف تیم‌ها برای پیاده‌سازی تگ کانونیکال مجبور شده‌اند دولوپر بگیرند، روی Webflow جدول‌های HTML رو دستی داخل صفحه کد زده چون ادیتور جدول نداره، و روی وردپرس بدون افزونه خبری نیست از ویرایش robots.txt یا noindex کردن تکی صفحات. فهرست کامل خواسته‌های او یازده آیتم داره که مهم‌ترین‌هایش را ادامه مرور می‌کنیم.
تگ کانونیکال ۱۷ ساله شد و هنوز پیش‌فرض نیست
تگ کانونیکال را گوگل، یاهو و مایکروسافت با هم در فوریه ۲۰۰۹ معرفی کردند؛ گزارش نیویورک تایمز همان روزها این همکاری رو پوشش داد. بدون کانونیکال درست، موتورها نسخه غلط صفحه رو ایندکس می‌کنن و محتوای تکراری تولید می‌شه؛ مستندات رسمی گوگل هم درباره تلفیق آدرس‌های تکراری همین رو شفاف گفته. با این حال میلز امسال روی سایت‌های وردپرسی و SilverStripe و Webflow دیده که کانونیکال پیش‌فرض روشن نبوده. تام استفانو هم نشان داده Squarespace زیردسته‌های محصول رو به دسته اصلی کانونیکال می‌کنه؛ یعنی صفحات زیردسته عملاً شانس ایندکس ندارند. جمع‌بندی ساده است: وجود این تگ رو نباید به دمو فروشنده اعتماد کرد؛ روی سایت تستی چکش کنید.
ربات‌های هوش مصنوعی جاوااسکریپت اجرا نمی‌کنن
ربات گوگل یا همان گوگل‌بات هر صفحه با کد ۲۰۰ رو برای رندر صف می‌کنه و این کار بعد از خزش اولیه انجام می‌شه و گاهی طول می‌کشه. اما نکته امسال اینجاست: اکثر کرالرهای هوش مصنوعی اصلاً جاوااسکریپت اجرا نمی‌کنن. مطالعه ورسل روی لاگ‌های واقعی نشان داده GPTBot و ClaudeBot و PerplexityBot و بقیه بزرگ‌ها فایل JS رو دانلود می‌کنن ولی اجراش نمی‌کنن؛ یعنی محتوایی که فقط بعد از اجرای جاوااسکریپت ظاهر می‌شه برایشان وجود نداره. جمع‌بندی میلز صریحه: اگه محتوای شما فقط با جاوااسکریپت ساخته می‌شه، فرض رو بر این بگذارید که ربات‌ها نمی‌بیننش. ما هم بحث دسترسی ربات‌ها رو قبلاً با ماجرای بلاک خاموشی در لاگ سرور باز کردیم.
فایل robots.txt و نقشه سایت حق شماست نه لطف سازنده
آمار وب‌آلمانک ۲۰۲۵ می‌گه ۸۴.۹ درصد سایت‌ها برای robots.txt کد ۲۰۰ برمی‌گردونند؛ یعنی حدود ۱۵ درصد هنوز اصلاً این فایل رو ندارن. این فایل نباید گروگان ساختار CMS باشه. خواسته میلز ساده‌ست: هر سیستم باید robots.txt قابل ویرایش بده و کنترل نقشه سایت هم داشته باشه. مثال واقعی‌اش شاپیفایه که برای بازارهای اضافی نقشه سایت رو خودکار می‌سازه و اجازه حذف URL رو نمی‌ده؛ صفحه رسمی شاپیفای هم این رو صریح نوشته. وردپرس هم بدون افزونه یا دسترسی به فایل‌های سرور ویرایش robots.txt رو ممکن نمی‌کنه؛ هرچند با همین فایل می‌شه بستن محتوا از ربات‌های آموزش هوش مصنوعی رو در یک قدم اجرا کرد.
صفحه خطا و ریدایرکت‌ها جایی است که CMS ها لیز می‌خورند
تله‌ای که بیشتر سیستم‌ها رو می‌اندازه همینه: قالب ۴۰۴ که به‌جای کد ۴۰۴ کد ۲۰۰ برمی‌گردونه. صفحه می‌گه پیدا نشد ولی سرور می‌گه همه‌چیز مرتبه و نتیجه‌اش ایندکس شدن صفحات خطاست؛ میلز این رو روی چند CMS دیده. درستش اینه که صفحات خطا از داخل سیستم قابل شخصی‌سازی باشن و کد درست برگردونن؛ شخصی‌سازی صفحه 404 در وردپرس هم دقیقاً همین کار رو می‌کنه. مدیر ریدایرکت هم باید انتخاب کد (۳۰۱ و ۳۰۲ و ۳۰۷ و ۳۰۸ و ۴۱۰)، پشتیبانی رجکس و مهم‌تر از همه گارد ضدحلقه داشته باشه. خودش تعریف کرده: یه کاراکتر پایپ اضافه در قانون رجکس کل سایت رو پایین آورد؛ اگر سیستم قبل از ذخیره قانون رو روی چند نمونه URL تست می‌کرد، این اتفاق نمی‌افتاد. درباره ریدایرکت‌ها قبلاً مفصل صحبت کردیم؛ تاثیر ریدایرکت بر سئو همون مطلبه که ساختار ۳۰۱ و ۳۰۲ رو باز می‌کنه.
وردپرس کجای این چک‌لیست ایستاده؟
وردپرس عنوان صفحه رو پیش‌فرض می‌ده ولی متا دیسکریپشن و تگ‌های Open Graph رو نه؛ برای همین اکثر کاربرها سراغ یه افزونه سئو وردپرس می‌رن که همه این پایه‌ها رو جبران کنه. فهرست مطالب خودکار هم همین وضع رو داره؛ حتی وردپرس برایش به افزونه‌ای مثل رنک مث نیاز داره، همون قابلیتی که گوگل با سیتلینک جواش رو می‌ده.
در عوض وردپرس یه برگ برنده داره که میلز هم روش تأکید می‌کنه: اتصال از طریق API و CLI و MCP. او کمتر مستقیم داخل CMS کار می‌کنه و محتوای بعضی سایت‌هایش رو با Claude Code آپدیت می‌کنه. اگه محیط وردپرس خودتون رو مدیریت می‌کنید، اتصال ایجنت رو تست کنید؛ فقط اول گارد و فرایند تست بگذارید که یهو چیزی خراب نشه.
بهینه‌سازی تصویر پایه است نه لوکس
تا امروز میلز هیچ CMSی پیدا نکرده که بهینه‌سازی تصویر رو درست انجام بده. خواسته‌هاش مشخصه: یه آدرس تمیز و ثابت برای هر تصویر، تبدیل خودکار به WebP یا AVIF هنگام آپلود، درج width و height برای جلوگیری از پرش صفحه، لیدی‌لود همه تصاویر به‌جز تصویر اول، امکان تصویر OG سفارشی برای هر صفحه و اجازه تنظیم max-image-preview:large. مشکل واقعی وقتیه که هر بهینه‌سازی یه URL جدید بسازه؛ توی یه سیستم سازمانی هر تصویر چند آدرس مختلف پیدا می‌کرد و برای سرچ تصویری یعنی آشوب تکراری‌ها. وردپرس این طرف ابزارهای خوبی داره؛ اگه سرعت و بهینه‌سازی براتون جدیه، افزونه WP Rocket کارهای کش و تصویر رو جمع می‌کنه.
برای چه سایت‌هایی این چک‌لیست جدی‌تر است؟
جواب میلز به سؤال همیشگی «کدام CMS بهتره؟» همون جواب کلاسیک سئوئه: بستگی داره. ولی راهنمای عملی‌اش اینه: ببینید کدوم تیکت‌ها هر ماه تکرار می‌شن و همون‌جا رو با ابزار و اسکریپت اتومات کنید. برای سایت‌های خبری بزرگ و فروشگاه‌های پرصفحه، نبود این یازده پایه یعنی ساعت‌ها کار دستی در هر هفته. جمع‌بندی برای وبمستر ایرانی روشنه: CMS ایده‌آل وجود نداره، ولی این فهرست رو می‌شه چک‌لیست خرید و ارتقای جدی گرفت و قبل از هر انتخاب همین یازده مورد رو روی سایت تستی چک کرد؛ هزینه چند ساعت تست خیلی ارزون‌تر از سال‌ها تیکت زدنه.
