আমার একটি SEO প্রজেক্টে Yandex 12,500টি পৃষ্ঠা ইনডেক্স করেছিল। শুধু এই সংখ্যাটি দেখলে সাইটটি সুস্থই মনে হতো। কিন্তু রাশিয়া থেকে আসল ট্রাফিক ছিল প্রায় শূন্য।
এই বড় SEO প্রজেক্টটি আমি frontend developer হিসেবে নিজের skill আরও উন্নত করার জন্যও তৈরি করছিলাম।
প্রথমে আমি SEO দিকেই সমস্যাটি খুঁজছিলাম। Troubleshooting করার পরে আরও মৌলিক একটি সমস্যা পেলাম: নেটওয়ার্ক পাথ। সাইটটি Cloudflare-এর পিছনে ছিল এবং রাশিয়া থেকে নির্ভরযোগ্যভাবে অ্যাক্সেস করা যাচ্ছিল না। আমি রাশিয়ার বাইরে থাকতাম, তাই নিজের কাজের পরিবেশ থেকে এই সমস্যাটি প্রায় দেখা যেত না।
এই ঘটনা আমাকে তিনটি সিগন্যাল আলাদা করে দেখতে শিখিয়েছে, যেগুলো খুব সহজে একই জিনিস মনে হয়: indexing, reachability এবং traffic। এগুলো এক নয়। একটি পৃষ্ঠা index-এ থাকতে পারে, অথচ নির্দিষ্ট নেটওয়ার্কের বাস্তব ব্যবহারকারীরা সেটি পুরোপুরি লোড করতে না-ও পারেন।
আমি সত্যিই কী নিশ্চিত করতে পারি
আমার নিজের অভিজ্ঞতার তথ্যগুলো সরল। আমি Cloudflare-এর পিছনে একটি বড় SEO প্রজেক্ট চালাচ্ছিলাম। Yandex 12,500টি পৃষ্ঠা ইনডেক্স করেছিল, কিন্তু রাশিয়া থেকে ট্রাফিক ছিল প্রায় নেই। আমি তদন্ত করে সমস্যাটিকে নেটওয়ার্ক লেয়ার পর্যন্ত সীমিত করি। এরপর Cloudflare proxy পুরোপুরি বন্ধ করে নিজের VDS-এ Nginx দিয়ে প্রয়োজনীয় কাজগুলো করি: caching, compression এবং basic security।
এই পরিবর্তনের পর রাশিয়া থেকে অ্যাক্সেস সঙ্গে সঙ্গে ফিরে আসে। এই কেস থেকে সবচেয়ে শক্তভাবে যে ফলটি বলতে পারি তা হলো: delivery path বদলালে reachability ফিরে এসেছিল।
একইভাবে গুরুত্বপূর্ণ হলো, এই কেস কী প্রমাণ করে না। কত visit হারিয়েছিলাম, রাশিয়ার ঠিক কোন কোন network প্রভাবিত হয়েছিল, বা পরে organic traffic ঠিক কতটা ফিরে এসেছিল—এসব এই case থেকে নির্ভুলভাবে বলা যায় না। আমার পর্যবেক্ষণ ছিল accessibility এবং প্রায় শূন্য traffic নিয়ে, controlled SEO experiment নিয়ে নয়।
পাবলিক প্রমাণ আমার প্রথম ব্যাখ্যার চেয়ে বেশি নির্ভুল
শুরুতে আমি ঘটনাটিকে এমনভাবে লিখেছিলাম যেন Roskomnadzor Cloudflare-এর নির্দিষ্ট কিছু IP range ব্লক করেছে। আমি যে প্রমাণ সমর্থন করতে পারি, তার তুলনায় এই ভাষা অতিরিক্ত নির্দিষ্ট।
Cloudflare 26 জুন 2025-এ নিজস্ব রিপোর্ট প্রকাশ করে জানায় যে 9 জুন 2025 থেকে রাশিয়ায় Cloudflare-protected service-এ সংযোগ করা ব্যবহারকারীরা রাশিয়ান ISP-এর throttling-এর মুখে পড়ছিলেন। Cloudflare-এর internal analysis অনুযায়ী, প্রভাবিত কিছু connection-এ web resource-এর প্রথম 16 KB পর্যন্ত লোড হচ্ছিল, যা অনেক page-এর স্বাভাবিক browsing নষ্ট করার জন্য যথেষ্ট। বিস্তারিত রাশিয়ার connectivity restriction নিয়ে Cloudflare-এর রিপোর্টে আছে।
এই বর্ণনা আমার দেখা failure pattern-এর সঙ্গে মেলে, কিন্তু প্রতিটি ISP-তে exact mechanism কী ছিল তা প্রমাণ করে না এবং আমার পুরো traffic drop-কে সরাসরি Roskomnadzor-এর ফল বলার সুযোগ দেয় না। আরও সঠিকভাবে বলা যায়: আমার সাইটের Cloudflare-proxied delivery path রাশিয়া থেকে নির্ভরযোগ্যভাবে ব্যবহার করা যাচ্ছিল না, এবং সেই proxy bypass করার পর আমার ক্ষেত্রে access ফিরে আসে।
12,500টি indexed পৃষ্ঠা থাকা মানেই সাইট healthy ছিল না
এটাই ছিল সেই conceptual পার্থক্য যেটিকে আমি কম গুরুত্ব দিয়েছিলাম। Index-এ 12,500টি পৃষ্ঠা দেখে আমি সেটাকে overall accessibility-এর signal ভাবছিলাম। কিন্তু search-engine crawling এবং end-user connectivity আলাদা system।
Search engine হয়তো URL আগে crawl করেছে, অন্য network path দিয়ে পৌঁছেছে, বা কিছু user পুরো response না পেলেও page-টিকে index-এ রেখেছে। তাই indexed URL প্রমাণ করে না যে নির্দিষ্ট কোনো রাশিয়ান ISP-এর user আজ page-টি খুলতে পারবে। আমার ক্ষেত্রে দুটি তথ্য একই সময় সত্য ছিল: Yandex-এ 12,500টি পৃষ্ঠা ছিল, কিন্তু রাশিয়া থেকে বাস্তব user traffic তবু প্রায় শূন্য।
Indexing reachability নয়। Reachability traffic নয়।
আমি কী পরিবর্তন করেছি
- Cloudflare proxy পুরোপুরি বন্ধ করেছি। HTTP/HTTPS traffic আমার infrastructure-এ পৌঁছানোর আগে আর Cloudflare দিয়ে যেতে হচ্ছিল না।
- প্রয়োজনীয় function Nginx-এ নিয়েছি। নিজের VDS-এ caching, compression এবং basic security control নিজে configure করেছি।
বিষয়টি এমন নয় যে Nginx, Cloudflare-এর চেয়ে “ভালো”। আমি এমন একটি network dependency সরিয়েছি যা আমার জন্য গুরুত্বপূর্ণ market-এ problem হয়ে উঠেছিল।
Access ফিরেছে, কিন্তু responsibility-ও ফিরেছে
Reverse proxy bypass করা free upgrade নয়। Cloudflare-এর বর্তমান documentation অনুযায়ী DNS-only user-কে origin-এ সরাসরি পাঠায় এবং HTTP/HTTPS traffic আর Cloudflare proxy দিয়ে যায় না। ফলে caching এবং বিভিন্ন protection-এর মতো proxy-based সুবিধা origin-এর সামনে থাকে না, এবং origin IP প্রকাশিত হতে পারে। দেখুন official Proxy status documentation।
Nginx আমার কিছু প্রয়োজন মেটাতে পারে: local cache, compression, request handling এবং basic filtering। কিন্তু Cloudflare-এর global network, managed DDoS capacity বা সব security feature স্বয়ংক্রিয়ভাবে reproduce করে না। তাই migration ছিল trade-off: delivery path-এর ওপর বেশি direct control-এর বিনিময়ে বেশি operational responsibility।
এই project-এ trade-offটি যৌক্তিক ছিল, কারণ জরুরি সমস্যা ছিল রাশিয়া থেকে access। তার মানে এই নয় যে VDS + Nginx সবার জন্য সবচেয়ে নিরাপদ architecture।
আজ একই সমস্যা হলে আমি কীভাবে diagnose করতাম
Traffic যদি একটি দেশ বা network region-এ হঠাৎ পড়ে যায়, আমি title বা content rewrite করা দিয়ে শুরু করতাম না। আগে layer আলাদা করতাম:
- Target country থেকে এবং একাধিক ISP দিয়ে page fetch করা যায় কি?
- Client কি শুধু HTTP 200 নয়, পুরো response body পাচ্ছে?
- Controlled test-এ CDN বা reverse proxy bypass করলে behavior বদলায় কি?
- URL কি crawl এবং index হচ্ছে?
- Reachability confirm করার পরেই: impressions, clicks এবং sessions সত্যিই বদলাচ্ছে কি?
Practical lesson হলো, যে market গুরুত্বপূর্ণ সেখান থেকেই measurement করতে হবে। অন্য দেশ থেকে test origin alive দেখাতে পারে, অথচ regional connectivity failure পুরোপুরি miss করতে পারে।
এই ঘটনা থেকে আমার শিক্ষা
শুরুতে এটি SEO mystery মনে হচ্ছিল: 12,500টি indexed page, কিন্তু রাশিয়া থেকে প্রায় কোনো traffic নেই। দরকারি উত্তরটি stack-এর আরও নিচে ছিল।
Cloudflare proxy সরিয়ে নিজের VDS-এ Nginx দিয়ে প্রয়োজনীয় function পুনর্গঠন করার পর রাশিয়া থেকে access সঙ্গে সঙ্গে ফিরে আসে। এই result আমি facts দিয়ে defend করতে পারি। কিন্তু এটিকে Google বা Yandex ranking effect-এর proof, regulator-level exact blocking mechanism-এর proof, বা “সবাইকে Cloudflare ছাড়তে হবে” এমন universal rule বানাতে পারি না।
এই case-এর পর আমার rule সহজ: কোনো market গুরুত্বপূর্ণ হলে reachability সেই market থেকেই measure করুন। Index-এ page count বাস্তব user পুরো page পেতে পারছে কি না, সেটা বলে না।