https://virgool.io/feed/@miladseo.digital میلاد محمدی نوری؛ متخصص سئو تکنیکال. اینجا از حل چالش‌های فنی سئو، سرعت و ایندکس، و تجربه‌های اجرایی پروژه‌های واقعی می‌نویسم. https://www.miladseo.digital/ fa 2026-04-14 08:52:21 https://files.virgool.io/upload/users/4522178/avatar/1SVGda.png?height=120&width=120 https://virgool.io/@miladseo.digital https://virgool.io/@miladseo.digital/seo-recovery-xvo7kccpngak بازیابی سئو پس از قطعی اینترنت؛ چرا افت رتبه همیشه جریمه نیست؟اختلال اینترنت و سئو؛ داستانی که با «داون شدن ساده سایت» فرق دارددر قطع طولانی اینترنت بین‌الملل، خیلی‌ها تصور می‌کنند کافی است اتصال برگردد تا رتبه‌ها هم خودبه‌خود سر جایشان قرار بگیرند. اما ماجرا خیلی پیچیده‌تر از این است. اختلال اینترنت فقط دسترسی را نمی‌گیرد؛ بلکه رابطه بین گوگل، زیرساخت فنی سایت و رفتار کاربر را هم‌زمان به‌هم می‌ریزد و همین می‌تواند باعث افت سنگین رتبه یا حتی حذف بعضی آدرس‌ها از نتایج شود.در ایران این موضوع به شکل ویژه‌ای خودش را نشان می‌دهد؛ چون معمولا سایت‌ها یا روی سرور خارج میزبانی می‌شوند یا روی سرور داخل. همین تفاوت ظاهرا ساده، در یک بحران مشترک دو نتیجه کاملا متفاوت می‌سازد؛ از سایت‌هایی که فقط تعاملشان افت می‌کند تا سایت‌هایی که عملا از دید گوگل ناپدید می‌شوند.دو تجربه متفاوت: وقتی اینترنت قطع شد چه بر سر سایت آمد؟برای اینکه بفهمیم بعد از وصل شدن اینترنت چه‌طور باید رتبه‌ها را برگردانیم، باید بدانیم در زمان قطعی دقیقا چه اتفاقی افتاده. در قطع اخیر، تقریبا تمام سایت‌ها در یکی از دو سناریوی زیر قرار گرفتند.سناریو اول: سرور خارج، گوگل آنلاین بود اما کاربر ایرانی نهدر این حالت، سایت روی سرور خارج از ایران است. کاربران داخل کشور عملا نه می‌توانند سراغ گوگل بروند، نه به‌سادگی به سایت برسند، اما از نگاه گوگل، سرور همچنان در دسترس است و ربات می‌تواند سایت را Crawl کند. به همین خاطر:سیگنال‌های فنی مثل خزش و ایندکس به‌طور کلی حفظ می‌شود.مشکل اصلی از سمت رفتار کاربر است؛ چون جستجو، کلیک و تعامل تقریبا متوقف می‌شود.اینجا دردسر اصلی «رفتاری» و «تقاضا محور» است، نه زیرساختی. یعنی ریکاوری بعد از وصل شدن اینترنت، بیشتر شبیه روشن‌کردن دوباره موتور ترافیک و برگرداندن کاربران است تا رفع یک مشکل فنی جدی.سناریو دوم: سرور داخل، نه کاربر می‌رسید نه گوگلدر سناریوی دوم، سایت روی سرور داخلی است و مسیر بین‌الملل قطع می‌شود. نتیجه این است که:هم کاربر ایرانی و هم گوگل به مشکل می‌خورند.برای Googlebot، مسیر به سرور شما یا با Timeout تمام می‌شود یا اصلا برقرار نمی‌شود.خزش روی بخش بزرگی از آدرس‌ها کند یا متوقف می‌شود و بخشی از صفحات از ایندکس می‌افتند یا مثل Soft 404 دیده می‌شوند.اینجا دیگر فقط با افت تعامل طرف نیستیم؛ بودجه خزش و خود ایندکس آسیب می‌بیند. بنابراین وقتی اینترنت برمی‌گردد، بعضی سایت‌های سرور داخل با افت رتبه‌های چند ده پله‌ای یا ناپدید شدن بخش بزرگی از صفحات مواجه‌اند و بدون برنامه‌ریزی فنی مرحله‌به‌مرحله، برگشتن برایشان بسیار سخت‌تر است.قطع نت دقیقا چه چیز را در سئو به‌هم می‌ریزد؟اگر از زاویه سئو نگاه کنیم، «قطع اینترنت» یعنی چند لایه مختلف هم‌زمان از تعادل خارج می‌شود:خزش روی بخش‌هایی از سایت متوقف یا بسیار کند می‌شود.زمان پاسخ سرور بالا می‌رود یا اصلا پاسخی داده نمی‌شود.تقاضای جستجو کاهش پیدا می‌کند و CTR افت می‌کند.تصویر گوگل از پایداری سایت مخدوش می‌شود و ممکن است بعضی URLها را کم‌ارزش یا شبیه Soft 404 ببیند.به همین دلیل است که بعد از وصل شدن اینترنت، دو سایتی که از بیرون ظاهرا شرایط مشابهی دارند، می‌توانند نتایج کاملا متفاوتی بگیرند؛ یکی فقط کمی نوسان رتبه را تجربه می‌کند، دیگری باید برای دیده‌شدن از صفر شروع کند.بعد از وصل شدن اینترنت، بازگشت رتبه چگونه اتفاق می‌افتد؟با باز شدن مسیر بین‌الملل، گوگل دوباره به سایت برمی‌گردد، اما این به معنای بازگشت خودکار به همان جای قبلی نیست. سایت وارد مرحله‌ای می‌شود که می‌توان آن را «بازارزیابی الگوریتمی» نامید؛ یعنی گوگل دوباره سوال‌هایی مثل این‌ها را بررسی می‌کند:آیا سایت از نظر فنی پایدار و قابل اعتماد است؟محتوای فعلی، هنوز نسبت به رقبا انتخاب بهتری برای کاربر است؟رفتار کاربران بعد از کلیک، نشانه رضایت است یا نارضایتی؟در این فاز، نوع تصمیم‌های شما تعیین‌کننده است. اگر در روزهای اول بعد از وصل شدن نت، سراغ تغییرات سنگین مثل جابه‌جایی ساختار، حذف انبوه محتوا یا لینک‌سازی عجولانه بروید، سیگنال‌های متناقضی به الگوریتم می‌فرستید و روند ریکاوری را طولانی‌تر می‌کنید. در مقابل، اگر با یک ترتیب منطقی جلو بروید – اول پایدارسازی فنی، بعد احیای Crawl و Index، و در نهایت بازسازی محتوا و رفتار کاربر – شانس برگشت به رتبه‌های قبل یا نزدیک به آن بسیار بیشتر است.Recovery در عمل: وقتی اینترنت برگشته، از کجا شروع کنیم؟نقطه شروع ریکاوری کاملا به این بستگی دارد که در کدام سناریو بودید.اگر در سناریو A بودید (سرور خارج)در این حالت، دسترسی گوگل در طول بحران قطع نشده، پس تمرکز اصلی ریکاوری روی کاربر است، نه روی زیرساخت. قدم‌های منطقی می‌تواند این‌ها باشد:یک بار سلامت فنی و وضعیت ایندکس صفحات کلیدی را چک کنید تا مطمئن شوید مشکل زیرساختی جدی ندارید.برای لندینگ‌ها و صفحه‌های مهم، کمی نوسازی محتوا انجام دهید تا هم برای کاربر و هم برای الگوریتم «تازه» به‌نظر برسند.در روزهای اول، کمپین‌های بازگشت کاربر (ایمیل، پوش، شبکه‌های اجتماعی و…) را روی صفحات مهم متمرکز کنید تا دوباره جستجو، کلیک و تعامل شکل بگیرد.به‌جای یک جهش کوتاه‌مدت، بهتر است برای چند هفته برنامه‌ای بچینید که سیگنال‌های تعاملی به‌تدریج و پایدار برگردند و در این مدت از تغییرات بزرگ در ساختار سایت اجتناب کنید.اگر در سناریو B بودید (سرور داخل)در سناریوی دوم، هم گوگل را از دست داده‌اید هم کاربر را؛ بنابراین ریکاوری باید چندفاز داشته باشد:پایدارسازی فنیاول مطمئن شوید سایت واقعا از خارج ایران هم در دسترس است، خطاهای ۵xx و Timeout و نوسان شدید سرعت رفع شده و اگر قرار است زیرساخت را عوض کنید، این تغییر با حداقل جابه‌جایی و فقط یک‌بار انجام شود.احیای Crawl و IndexURLهایی که دی‌ایندکس شده‌اند یا وضعیت مشکوک پیدا کرده‌اند را شناسایی کنید، یک لیست کوتاه از صفحات هسته (لندینگ‌های اصلی، دسته‌های مهم، محصولات کلیدی) بسازید، لینک داخلی به آن‌ها را تقویت کنید و برای تعداد محدودی از مهم‌ترین آدرس‌ها درخواست ایندکس مجدد بفرستید.ترمیم محتوا و رفتار کاربرصفحات کلیدی‌ای را که هم افت رتبه داشته‌اند و هم محتوایشان قدیمی شده، به‌روز کنید، سناریوی بازگشت کاربر را با کمپین‌ها و پیشنهادها طراحی کنید و چند هفته رفتار کلیک و نمایش را زیر نظر بگیرید تا ببینید کدام صفحات به ریکاوری نزدیک شده‌اند و کدام هنوز نیاز به کار دارند.چرا معماری و زیرساخت، تصمیم سئویی است؟تجربه همین قطعی اخیر نشان داد که «جای سرور» و «نوع معماری» فقط یک انتخاب فنی یا مالی نیست؛ بلکه یک تصمیم استراتژیک سئو است. سرور داخل بدون CDN، سرور خارج بدون توجه به تجربه کاربر ایرانی، مدل‌های Hybrid و معماری مبتنی بر CDN، هر کدام در بحران رفتار متفاوتی از خودشان نشان می‌دهند.اگر از همین الان بدانید در هر کدام از این مدل‌ها دقیقا چه ریسک‌هایی وجود دارد و در سناریوهای A و B چه فازهایی از ریکاوری را باید طی کنید، در قطع بعدی اینترنت، به‌جای واکنش احساسی می‌توانید با یک Playbook آماده و یک چک‌لیست مشخص جلو بروید.نسخه کامل مقالهاین مطلب نسخه خلاصه و تحلیلی از یک وایت‌پیپر جامع است.نسخه کامل، همراه با بررسی فنی، سناریوهای مختلف و راهنمای مرحله‌به‌مرحله بازیابی سئو، در سایت منتشر شده است:👉 نسخه کامل مقاله:https://www.miladseo.digital/fa/blog/seo-recovery/ میلاد محمدی نوری میلاد محمدی نوری Sun, 15 Feb 2026 15:36:30 +0330 https://virgool.io/@miladseo.digital/seo-resilience-internet-outage-s70zfq3y6uso جلوگیری از افت رتبه سایت در زمان قطعی اینترنت بین‌المللقطعی یا اختلال اینترنت بین‌الملل معمولاً با یک نگرانی شروع می‌شود: «نکنه رتبه‌هامون بریزه؟» اما مسئله واقعی اغلب یک پله پایه‌ای‌تر است؛ اینکه آیا Googlebot اصلاً می‌تواند سایت را قابل‌اتکا ببیند، HTML را دریافت کند، منابع حیاتی را لود کند و سیگنال سلامت سرور را بگیرد یا نه.اگر معماری سایت طوری طراحی نشده باشد که در زمان اختلال هم HTML صفحات مهم قابل سرو باشد، افت رتبه معمولاً به شکل «آهسته، تجمعی و دیرقابل‌تشخیص» رخ می‌دهد؛ یعنی ممکن است امروز چیزی نبینی، اما چند هفته بعد با کاهش Crawl، دیر ایندکس شدن، و افت تدریجی مواجه شوی. من میلاد محمدی نوری هستم و در این راهنما از تجربه ها و راهکار ها برای این مشکل میگم.چرا قطعی اینترنت به سئو ضربه می‌زند؟ (واقعیت پشت پرده)سئو در عمل روی سه ستون می‌ایستد:دسترسی‌پذیری: Crawl و Fetch پایدارقابل‌فهم بودن: Render/Parse درست (خصوصاً برای سایت‌های JS-heavy)اعتمادپذیری: ثبات پاسخ‌ها و کاهش خطاهای تکرارشوندهدر اختلال بین‌المللی، ستون اول و دوم مستقیم ضربه می‌خورند (Timeout، DNS fail، منابع لود نمی‌شوند) و ستون سوم هم با تکرار خطاهای 5xx5xx و کندی، آسیب می‌بیند. نکته مهم این است که موتور جست‌وجو مثل کاربر واقعی «بی‌نهایت تلاش» نمی‌کند؛ وقتی دریافت محتوا پرهزینه یا نامطمئن شود، سیستم خزیدن به‌صورت سیستماتیک نرخ Crawl را پایین می‌آورد و اولویت URLها را تغییر می‌دهد.چرا این مشکل برای سرورهای داخل ایران شدیدتر است؟وقتی Origin داخل ایران است، مسیر دسترسی گوگل (که عمدتاً از دیتاسنترهای خارج درخواست می‌زند) ممکن است با موارد زیر بدتر شود:تعداد Hop بیشتر و نوسان مسیرافزایش RTT و ناپایداری TLS/Handshakeنوسان در DNS resolutionمحدودیت یا قطع مسیرهای بین‌المللی به‌صورت مقطعینتیجه‌اش این است که ممکن است کاربران داخلی سایت را «کاملاً سالم» ببینند، اما Googlebot از بیرون با Timeout یا 502/503/504502/503/504 مواجه شود.«سئو را Pause می‌کنیم» چرا ایده خطرناکی است؟سئو دکمه توقف ندارد. وقتی دسترسی خزنده قطع شود، این اتفاق‌ها می‌افتد:کاهش سیگنال تازه‌سازی محتواکاهش کشف صفحات جدیدبالا رفتن ریسک خروج تدریجی URLها از چرخه Crawl و حتی ایندکسافت اعتماد زیرساختی (به‌خصوص اگر خطاها تکرار شوند)پس هدف اصلی در بحران اینترنتی این نیست که «تولید محتوا را زیاد کنیم»؛ هدف این است که کاری کنیم گوگل همچنان بتواند سایت را به شکل پایدار ببیند.رفتار Crawl Budget در زمان اختلال (به زبان ساده)Crawl Budget ترکیبی از دو بخش است:Crawl Capacity Limit: سقفی که گوگل بر اساس توان پاسخگویی سرور تعیین می‌کندCrawl Demand: میزان تمایل گوگل به خزیدن (اهمیت، تازگی، محبوبیت)در اختلال، معمولاً اول Capacity از نگاه گوگل سقوط می‌کند چون:Average Response Time بالا می‌رودخطاهای 5xx5xx زیاد می‌شودTimeout یا connection reset اتفاق می‌افتدرندر ناقص می‌شود چون JS/CSS حیاتی لود نمی‌شودبعد از آن، Demand هم افت می‌کند چون گوگل نتیجه می‌گیرد «خزیدن هزینه دارد و احتمال موفقیت پایین است».هدف بقای سئو در بحران: چه چیزهایی باید همیشه در دسترس باشند؟اگر بخواهم یک «حداقل بسته حیاتی» تعریف کنم، این‌ها باید حتی در بدترین شرایط هم قابل دریافت باشند:هدف بقای سئو در بحران: چه چیزهایی باید همیشه در دسترس باشند؟HTML صفحات حیاتی (Home، Category، Pillar، Product/Service)فایل robots.txtrobots.txtsitemapهای اصلیCSS/JS حیاتی (یا نسخه HTML-first که بدون JS هم مفهوم بدهد)پاسخ‌های درست برای Canonical و Redirectهایعنی باید «محتوای حیاتی» را تا حد ممکن از وابستگی کامل به اتصال بین‌المللی Origin جدا کنی.زیرساخت پیشنهادی برای تاب‌آوری سئو (اجرایی و قابل پیاده‌سازی)1) Reverse Proxy / Edge به‌عنوان سپر سئوReverse proxy (مثل Cloudflare یا هر لایه Edge مشابه) فقط ابزار سرعت نیست؛ ابزار حفظ دسترسی HTML در زمان اختلال است. مشکل خیلی از سایت‌ها این است که CDN فقط تصاویر و استاتیک‌ها را کش می‌کند، اما HTML همچنان از Origin می‌آید؛ و وقتی Origin از بیرون ناپایدار شود، گوگل HTML را از دست می‌دهد.کارهایی که باید انجام دهی:کش کردن HTML برای صفحات حیاتی با TTL منطقیفعال کردن serve-stale یا stale-if-error (اگر سرویس پشتیبانی کند)تعریف Rule برای اینکه در 5xx5xx یا timeout، نسخه کش‌شده سرو شود2) Static HTML Fallback برای صفحات حیاتییکی از بهترین الگوها در بحران: وقتی Origin Down شد، Edge یک نسخه استاتیک از صفحات مهم را نشان دهد.مزیت‌ها:گوگل همچنان HTML قابل فهم می‌گیردلینک‌های داخلی و ساختار سایت حفظ می‌شودسیگنال «سایت زنده است» باقی می‌ماندروش اجرا می‌تواند ساده باشد: روزانه یا هر چند ساعت، Snapshot از صفحات کلیدی بگیری (SSG یا Pre-render)، روی Storage/Edge نگه داری، و Rule بزنی که اگر Origin خطا داد، fallback فعال شود.3) Hybrid Hosting یا Origin ثانویه خارج از کشور (Failover واقعی)اگر کسب‌وکار به ورودی ارگانیک وابسته است، داشتن Origin ثانویه بین‌المللی واقعاً ارزش دارد. دو مدل رایج:Origin اصلی ایران + Origin ثانویه خارج (برای زمان بحران)Split Hosting: HTML/SSR در لایه پایدارتر، API/DB داخل ایراننکته مهم: ثانویه را «برای SEO» طراحی کن، نه لزوماً برای کل تراکنش‌ها. یعنی ممکن است بخش‌های تراکنشی را محدود کنی، اما صفحات ورودی ارگانیک (لندینگ‌ها، مقالات، دسته‌ها) را کامل سرو کنی.4) DNS Failover واقعی (نه نمایشی)Failover واقعی یعنی:Health check از چند نقطه جغرافیایی (خارج هم حتماً)TTL کنترل‌شده (مثلاً 6060 تا 300300 ثانیه)جلوگیری از Split-brain (دو مبدا همزمان نسخه‌های متفاوت ندهند)تنظیمات Technical SEO که در بحران نجاتت می‌دهند1) کد وضعیت درست: 503503 برای اختلال موقت + Retry-Afterاگر موقتاً سرویس مختل است، بهترین سیگنال به گوگل:وضعیت 503503هدر Retry−AfterRetry−After (مثلاً 36003600 ثانیه)صفحه خطای سبک و استاتیک (نه یک صفحه JS سنگین)این کار به گوگل می‌گوید «مشکل موقت است، بعداً دوباره تلاش کن» و از تولید سیگنال‌های اشتباه جلوگیری می‌کند.2) از Soft 404 دوری کن (خیلی جدی)Soft 404 یعنی صفحه عملاً خالی/خطا است اما با 200200 برمی‌گردد. در بحران این اتفاق زیاد می‌افتد چون بعضی فریم‌ورک‌ها خطا را با 200200 رندر می‌کنند.چرا بد است؟گوگل فکر می‌کند صفحه وجود دارد اما بی‌کیفیت استCrawl Budget را می‌سوزاندروند بازیابی را کند می‌کند3) robots.txt و noindex را دستکاری نکندو اشتباه رایج در بحران:بستن robots.txt برای کاهش فشارگذاشتن noindex سراسریاین‌ها معمولاً اثر معکوس دارند و برگشت از آن‌ها زمان‌بر است. اگر مشکل دسترسی داری، راه‌حل باید زیرساختی باشد، نه «بستن درِ سایت به روی گوگل».4) Canonical و URL را ثابت نگه داردر دوره ناپایداری، ثبات سیگنال حیاتی است:canonical باید ثابت بماندساختار URL را تغییر ندهریدایرکت‌های عمومی و کور (مثل همه چیز به صفحه اصلی) نزنمانیتورینگ و لاگ: سریع‌ترین راه تشخیص ضربه به سئوSearch Console مفید است اما با تأخیر. لاگ سرور همان لحظه نشان می‌دهد چه خبر است.چه چیزهایی را در لاگ پایش کن؟افت ناگهانی درخواست‌های Googlebotافزایش 5xx5xx و timeout برای خزنده‌هابالا رفتن TTFB برای درخواست‌های خزندهوضعیت دریافت robots.txtrobots.txt و sitemap (باید همیشه 200200 باشند)افزایش 499/504499/504 (در Nginx معمولاً نشانه قطع ارتباط/timeout است)Crawl Stats در GSC را چطور بخوانیم؟در گزارش Crawl Stats به این‌ها دقت کن:Average response timeتعداد درخواست‌های روزانهافزایش خطاهای سرور یا DNSاگر Average response time بالا رفت و تعداد crawl افت کرد، معمولاً گوگل ظرفیت خزیدن را کم کرده است.وقتی Crawl کم می‌شود، لینک‌سازی داخلی تعیین‌کننده می‌شودوقتی گوگل کمتر می‌خزد، معماری لینک داخلی مشخص می‌کند چه صفحاتی دیده شوند.کارهای عملی:Pillarها و صفحات درآمدزا را در 22 تا 33 کلیک از Home نگه دارلینک‌های کلیدی را HTML-first قرار بده (نه پشت تب/اکاردئون وابسته به JS)Breadcrumb و ساختار دسته‌بندی را ساده و قابل خزیدن کنصفحات کم‌ارزش را از مسیرهای اصلی دور کن (نه اینکه در بحران noindex اضافه کنی)چه کارهایی را در زمان بحران انجام ندهیم؟مهاجرت عجولانه همزمان با اختلال (هاست/دامنه/CMS/URL)فعال کردن WAF ruleهایی که Googlebot را challenge می‌کندریدایرکت دسته‌جمعی همه URLها به صفحه اصلیتغییرات انبوه canonical، hreflang یا ساختار URLاین‌ها ریسک خطا را چند برابر می‌کنند، آن هم زمانی که توان «تشخیص دقیق اثر تغییرات» پایین آمده است.بعد از وصل شدن اینترنت: چطور سریع‌تر ریکاوری کنیم؟Crawl Stats را چک کن: آیا زمان پاسخ و تعداد crawl به حالت عادی برگشته؟خطاهای Coverage را با اولویت robots/DNS/5xx5xx/404404 رفع کنsitemapها را با lastmodlastmod واقعی به‌روزرسانی کنلینک داخلی به صفحات حیاتی را تقویت کن تا Demand برگرددبرای 2020 تا 200200 URL حیاتی از Request Indexing استفاده کن (نه برای کل سایت)نکته مهم: بعد از بحران، وسوسه انتشار یا تغییرات زیاد طبیعی است، اما فشار ناگهانی می‌تواند دوباره 5xx5xx بسازد و گوگل را دوباره محتاط کند. بازگشت را فازبندی کن.چک‌لیست سریع (برای مدیر سئو و تیم فنی)مانیتورینگ چندمنطقه‌ای خارج از ایران داریلاگ Googlebot را جداگانه پایش می‌کنی و برای افت درخواست‌ها آلارم داریEdge/CDN می‌تواند HTML صفحات حیاتی را سرو کندبرای 5xx/timeout5xx/timeout، fallback استاتیک یا serve-stale داریدر اختلال موقت 503503 + Retry−AfterRetry−After می‌دهیSoft 404 نزدیک صفر استrobots/noindex را در بحران دستکاری نمی‌کنیcanonical و URL ثابت هستند میلاد محمدی نوری میلاد محمدی نوری Tue, 06 Jan 2026 13:32:54 +0330 https://virgool.io/@miladseo.digital/about-milad-mohammadi-nouri-t8jyk1orf7wd میلاد محمدی نوری هستم؛ متخصص سئو با تمرکز اصلی روی سئو تکنیکال. مسیر کاری‌ام از جایی جدی شد که فهمیدم خیلی از «مشکل‌های سئو» فقط با تولید محتوا حل نمی‌شوند؛ ریشه‌شان در ساختار سایت، نحوه رندر شدن صفحات، خزش و ایندکس، و تصمیم‌هایی است که داخل کد و معماری اطلاعات گرفته می‌شود.کار من معمولاً از همین نقطه شروع می‌شود: پیدا کردن گلوگاه‌های فنی که جلوی رشد ارگانیک را می‌گیرند و تبدیل‌کردنشان به یک برنامه اجرایی مشخص. یعنی به‌جای توصیه‌های کلی، با تسک‌های دقیق و قابل پیاده‌سازی جلو می‌روم؛ تسک‌هایی که تیم فنی، تیم محتوا و مدیر محصول بتوانند با هم اجرا کنند و نتیجه‌اش در داده‌ها قابل اندازه‌گیری باشد.چرا «تکنیکال» برایم مهم است؟تکنیکال برای من فقط چند مورد مثل سرعت یا اسکیما نیست. تکنیکال یعنی اینکه موتور جستجو واقعاً بتواند سایت را درست ببیند، بفهمد و ارزش‌گذاری کند. خیلی وقت‌ها یک سایت از بیرون «خوبه»، ولی زیر پوستش مشکلاتی دارد مثل:صفحات مهم که درست ایندکس نمی‌شوند یا دیر ایندکس می‌شوند.بودجه خزش هدر می‌رود و گوگل وقتش را روی صفحات بی‌ارزش صرف می‌کند.رندر جاوااسکریپت، داده‌های مهم را از چشم خزنده پنهان می‌کند.لینک‌سازی داخلی و معماری اطلاعات طوری چیده شده که مسیر رتبه‌گرفتن سخت می‌شود.مهاجرت، ریدایرکت‌ها یا تغییرات فنی، باعث افت‌های ناگهانی می‌شود.این‌ها همان جاهایی است که «سئو» تبدیل می‌شود به یک کار مهندسی: باید عیب‌یابی کرد، اولویت‌بندی کرد، تست گرفت و نتیجه را با عدد سنجید.اینجا توی ویرگول قرار است چه چیزی بنویسم؟ویرگول را انتخاب کردم چون جای خوبی برای نوشتن تجربه‌های واقعی و قابل اجراست. موضوعاتی که بیشتر درباره‌شان می‌نویسم:سئو تکنیکال به زبان ساده اما دقیق (از Crawl/Index تا Render)سرعت، Core Web Vitals و تصمیم‌های درست برای بهبودشانمعماری سایت، ساختار URL، لینک‌سازی داخلی و نقشه راه رشدسئو در سایت‌های کدنویسی‌محور و چالش‌های Front-end/JSتحلیل داده و اینکه چطور «حس خوب» را به «عدد قابل دفاع» تبدیل کنیمهدفم این است که هر نوشته، یک نکته مشخص و قابل اجرا داشته باشد؛ چیزی که همان روز بتوانید روی سایت خودتان یا پروژه‌تان امتحان کنید.اگر دنبال همکاری هستیدبهترین پروژه‌هایی که با آن‌ها ارتباط می‌گیرم پروژه‌هایی هستند که می‌خواهند سئو را اصولی، بلندمدت و شفاف جلو ببرند؛ نه پروژه‌هایی که دنبال راه‌حل‌های کوتاه‌مدت و پرریسک هستند. اگر یک سایت دارید که حس می‌کنید «پتانسیل دارد ولی رشد نمی‌کند»، معمولاً ریشه‌اش یا در تکنیکال است یا در استراتژی و اولویت‌بندی. میلاد محمدی نوری میلاد محمدی نوری Thu, 25 Dec 2025 01:24:50 +0330