سئو در پروژه‌های نرم‌افزاری معمولاً آخر از همه می‌آید: سایت ساخته می‌شود، بعد کسی می‌پرسد «چرا در گوگل نیستیم؟» و آن‌وقت یک لیست توصیه تحویل تیم فنی می‌شود که نیمی از آن هرگز اجرا نمی‌شود، چون اجرای آن یعنی بازنویسی معماری.
بیشتر مشکلات سئوی فنی، تصمیم‌های معماری‌اند که دیر گرفته شده‌اند.
رندر سمت سرور یک تصمیم سئوست، نه یک تصمیم فنی
اگر صفحه‌ی شما در مرورگر با جاوااسکریپت ساخته می‌شود، گوگل برای دیدنش باید صفحه را اجرا کند. این کار انجام می‌شود، اما با تأخیر و بودجه‌ی محدود. صفحه‌ای که HTML کاملش را در همان پاسخ اول می‌دهد، سریع‌تر و مطمئن‌تر ایندکس می‌شود.
این تفاوت را نمی‌شود بعداً با افزونه درست کرد؛ یا از اول سمت سرور رندر می‌شود یا نمی‌شود.
ساختار آدرس را بعداً نمی‌شود عوض کرد
هر تغییر آدرس یعنی ریدایرکت، و هر ریدایرکت یعنی مقداری از اعتباری که جمع کرده‌اید هدر می‌رود. پس آدرس‌ها را از روز اول طوری بچینید که یک سال بعد هم منطقی باشند:
/services/web-development— نه/page?id=12/blog/<عنوان-معنادار>— نه/blog/2024/03/17/post- دسته‌بندی جدا از مقاله، تا هر دو مستقل رشد کنند
داده‌ی ساختاریافته فقط وقتی ارزش دارد که راست بگوید
اسکیمای FAQ روی صفحه‌ای که سوال و جواب ندارد، یا اسکیمای Product روی صفحه‌ای بدون قیمت، در بهترین حالت نادیده گرفته می‌شود و در بدترین حالت جریمه دارد. قاعده ساده است: هر چیزی که در JSON-LD ادعا می‌کنید باید روی همان صفحه دیده شود.
سایت چندزبانه: hreflang را درست بگذارید
اگر سایت فارسی و انگلیسی دارید، هر صفحه باید به نسخه‌ی دیگرش اشاره کند و
هر دو باید به x-default اشاره کنند. بدون این، گوگل دو نسخه را رقیب هم
می‌بیند و یکی را انتخاب می‌کند — معمولاً نه آنی که شما می‌خواهید.
سرعت: عدد آزمایشگاهی مهم نیست، عدد کاربر مهم است
امتیاز ۱۰۰ در Lighthouse روی لپ‌تاپ شما چیزی را ثابت نمی‌کند. چیزی که در رتبه اثر دارد Core Web Vitals واقعی کاربران است: LCP، INP و CLS روی موبایل و شبکه‌ی واقعی. بهینه‌سازی را از تصویر شاخص و فونت شروع کنید، نه از حذف چند کیلوبایت CSS.
جمع‌بندی
سئوی فنی چیزی نیست که بعد از تحویل اضافه شود؛ مجموعه‌ای از تصمیم‌های معماری است که هنگام ساخت گرفته می‌شوند. برای همین ما سئو را جدا از توسعه نمی‌فروشیم — کسی که سایت را می‌نویسد باید همان کسی باشد که این تصمیم‌ها را می‌گیرد.