دلوین خیری مقدم
دلوین خیری مقدم، نویسنده و کارشناس سئوی فنی و وردپرس ویژنپرایم سوئیت است؛ عضو تیم زیرساختی که سایت خودِ این «سیستمعامل رشد کسبوکار وردپرسی» را روی رندر سمت سرور (SSR) برد. نه سال است با وردپرس کار میکند: مهاجرت، سرعت، امنیت و دادههای ساختاریافته. متنهایش از دل کار میدانی میآید؛ ترمینال باز، لاگ کنار دست و اعدادی که پیش از نوشتن دوباره اندازهگیری شدهاند.
مسیر حرفهای
شروع کارش پشتیبانی فنی سایتهای وردپرسی بود؛ همانجا فهمید بیشتر بحرانهای «سایت بالا نمیآید» ریشه در مهاجرت بد، افزونهٔ ناسازگار یا پشتیبانگیری خیالی دارد. سالهای بعد را میان دو کار تقسیم کرد: مهندسی وردپرس (مهاجرت، کش، سرور، سختسازی امنیتی) و سئوی فنی (معماری اطلاعات، خزشپذیری، Schema، سرعت). بخشی از آن سالها هم به فروشگاههای ووکامرسی پرتراکنش گذشت؛ جایی که هر خطای فنی مستقیم به فروش وصل است. در مهاجرتهای بزرگ یاد گرفت سئوی فنی بدون دسترسی مهندسی فقط توصیه روی کاغذ است؛ برای اجرا باید خودت سراغ Nginx، PHP-FPM و لایههای کش بروی.
به ویژنپرایم سوئیت آمد تا کاری که برای مشتریها میشود، روی سایت خودِ محصول هم اجرا شود. نتیجهٔ این کار تیمی با برچسب «کار ثبتشدهٔ سوئیت» ثبت شده: فعالسازی SSR، رشد حجم HTML صفحهٔ اصلی از ۳٫۴ کیلوبایت به ۷۴٫۷ کیلوبایت و افت TTFB از ۰٫۱۸۵ ثانیه به ۰٫۱۰۷ ثانیه. او همچنین بخشی از پروژهٔ رشد ارگانیکی بود که با همین برچسب ثبت شده است: دهبرابر شدن ترافیک سایت liuna در سه ماه و رسیدن ۲۸۶ صفحهٔ محصول به صفحهٔ اول گوگل، بدون حتی یک بکلینک خریداریشده. سهم او در این پروژه، بخش فنی بود: معماری لینک داخلی، مدیریت بودجهٔ خزش و دادهٔ ساختاریافتهٔ صفحات محصول.
روش کار
هر ممیزی از ابزارهای استاندارد شروع میشود: PageSpeed Insights و Lighthouse برای Core Web Vitals و متریکهای میدانی، Google Search Console برای رفتار خزش و ایندکس. عادت امضادار او «خامبینی» است: با curl خروجی HTML سمت سرور را میگیرد و چک میکند محتوای اصلی واقعاً در پاسخ اولیه هست یا بعداً با جاوااسکریپت تزریق میشود؛ گزارش ابزار ممکن است خوشبین باشد، HTML خام دروغ نمیگوید. پس از هر تغییر فنی، همان تست تکرار میشود تا تفاوت عددی و قابلارجاع باشد. زمانبندی ممیزی هم تصادفی نیست؛ پس از هر آپدیت بزرگ الگوریتم، همان چکلیست از اول اجرا میشود.
دادهٔ ساختاریافته برایش تزئین نیست؛ لایهٔ گفتوگوی صفحات با موتور جستوجوست. Schema فقط جایی گذاشته میشود که دادهٔ واقعی پشتش باشد و وضعیت آن تا تأیید در Search Console پیگیری میشود. چکلیست امنیت برای هر انتشار اجرا میشود: نسخهٔ PHP، مجوز فایلها، محدودسازی تلاشهای ورود، پشتیبانگیری آزمایششده — نه پشتیبانگیری روی کاغذ — و ثبت لاگ. تفکر بودجهٔ خزش هم ساده است: صفحهای که ارزش خزش ندارد، جای آن در نقشهٔ سایت نیست. در مهاجرتها هم قاعدهٔ ثابت دارد: پشتیبان کامل پیش از هر تغییر، اجرا روی نسخهٔ آزمایشی و تعویض DNS فقط پس از تأیید مقایسهای.
تخصص، مأموریت و مرزهای کار فنی
خوشههای «سئو ۳۶۰ فنی»، «وردپرس»، «عمودیهای صنعت» و «اثبات و داده» زیر قلم اوست. قاعدهٔ تحریریهایاش در خوشهٔ اثبات و داده محکم است: عدد بدون برچسب منبع منتشر نمیشود؛ اعداد کارهای ثبتشده با برچسب «کار ثبتشدهٔ سوئیت» میآیند و هر عدد دیگر یا منبع عمومی دارد یا اصلاً نوشته نمیشود. در خوشهٔ وردپرس، مقالهها را طوری مینویسد که مدیر سایت بتواند مرحلهبهمرحله اجرا کند: دستور دقیق، خروجی مورد انتظار و مسیر برگشت اگر نتیجه عکس شد. آشناییاش با نگاه تستمحور از چرخهٔ انتشار خود سوئیت میآید؛ جایی که بیش از ۹۰۰ تست خودکار در هر انتشار اجرا میشود و فرهنگ «اول اندازهگیری، بعد ادعا» به قلم او هم منتقل شده است.
محدودیتها را صریح میگوید. اول: سئوی فنی سقف را بالا میبرد اما جای محتوا را نمیگیرد؛ سرعت خوب و Schema درست، محتوای بیارزش را ارزشمند نمیکند، فقط اجازه میدهد محتوای ارزشمند دیده شود. دوم: ضعف اعتبار دامنه با فنیکاری حل نمیشود؛ اگر رقابت یک حوزه به بکلینک طبیعی و زمان نیاز دارد، هیچ تنظیم سروری میانبر نمیسازد. سوم: TTFB پایین بهتنهایی فروش نمیآورد؛ مسیر بعد از کلیک — پیشنهاد روشن، قیمت شفاف، پشتیبانی پاسخگو — بیرون از قلمرو فنی است و انکارش نمیکند.
قضاوت شخصیاش دربارهٔ آیندهٔ سئوی فنی: با بلوغ رندر و فهم موتورهای جستوجو، مزیتهای فنی پایه بهتدریج فرضِ پیشفرض میشوند و رقابت به لایهٔ دادهٔ ساختاریافتهٔ واقعی و کیفیت تجربهٔ پس از کلیک منتقل میشود؛ وقتی همهٔ سایتها سریع باشند، سرعت دیگر مزیت نیست و آنچه میماند کیفیت داده و تجربهٔ کاربر است. برای همین در مقالههایش پس از «چطور فنی درست کنیم» به این سؤال میپردازد: «بعد از این، چه چیزی واقعاً تفاوت میسازد؟»