موجودہ سائٹ کو اے آئی بلڈر میں منتقل کرنا: غلطی کرنے کے تین طریقے

ہر ہفتے کوئی نہ کوئی موجودہ سائٹ — جس پر ٹریفک ہو، بیک لنکس ہوں، اور گوگل کے چند سالوں کا اعتماد ہو — کو AI بلڈر میں منتقل کرنا چاہتا ہے۔ کوئی نیا آئیڈیا نہیں، کوئی پروٹو ٹائپ نہیں۔ ایک ایسا موجودہ کاروبار جس کے پاس کھونے کے لیے کچھ ہو۔ یہ خالی پرامپٹ سے شروع کرنے سے مختلف کام ہے، اور جو تکلیف میں نے دیکھی ہے اس کی زیادہ تر وجہ اسے اسی جیسے کام کے طور پر برتنا ہے۔

ایسے تین طریقے ہیں جن میں یہ کام اتنی بار غلط ہوتا ہے کہ میں سبجیکٹ لائن سے آگے پڑھے بغیر ہی سپورٹ ٹکٹ کا اندازہ لگا سکتا ہوں۔ صحیح طریقہ کوئی چالاکی نہیں ہے۔ یہ صرف وہ چیز ہے جس تک آپ پہنچ جاتے ہیں جب آپ یہ تین کام کرنا چھوڑ دیتے ہیں۔

غلطی نمبر ایک: پرانا مواد ڈال کر یہ امید کرنا کہ ساخت خود بخود ٹھیک ہو جائے گی

یہ جبلت سمجھ میں آتی ہے۔ آپ کے پاس ایک سائٹ ہے، اس پر الفاظ ہیں، تو آپ الفاظ چیٹ میں پیسٹ کر دیتے ہیں اور بلڈر سے کہتے ہیں کہ "اسے بہتر بنا دو"۔ جو نتیجہ نکلتا ہے وہ عموماً ایسی سائٹ ہوتی ہے جو نئی نظر آتی ہے مگر پرانی پڑھی جاتی ہے — وہی طویل سروس پیراگراف، وہی تین ہیڈنگز جو پندرہ کا کام کر رہی ہیں، اب بس ایک بہتر ٹیمپلیٹ میں لپیٹی ہوئی۔ بلڈر نے وہی کیا جو آپ نے مانگا۔ آپ نے اسے دوبارہ سجانے کو کہا تھا، دوبارہ سوچنے کو نہیں۔

نقصان تقریباً چھ ہفتے بعد سامنے آتا ہے، جب نئی سائٹ کی رینکنگ بالکل وہیں ہوتی ہے جہاں پرانی سائٹ کی تھی، یا اس سے کچھ کم۔ کچھ بھی بہتر نہیں ہوا کیونکہ اصل معلوماتی ساخت میں کچھ تبدیل نہیں ہوا — وہی ایک فلیٹ صفحہ ایسی سروس کے لیے جو تین صفحوں پر مشتمل ہونی چاہیے تھی، وہی غائب FAQ مواد جس پر ایک حریف کی سائٹ ایک سال سے رینک کر رہی ہے۔ غلط تعداد میں کمروں والے گھر پر رنگ کی نئی تہہ لگانے سے کمروں کی غلط تعداد ٹھیک نہیں ہو جاتی۔

میرا ایک کلائنٹ تھا جس کا "سروسز" صفحہ 4,000 الفاظ پر مشتمل تھا اور گیارہ مختلف پیشکشوں کا احاطہ کرتا تھا۔ وہ اسے جوں کا توں منتقل کرنا چاہتی تھی کیونکہ "یہ ہمیشہ کام کرتا رہا ہے"۔ حقیقت میں یہ کام نہیں کر رہا تھا — یہ کسی خاص چیز کے لیے رینک نہیں کرتا تھا کیونکہ یہ ایک ساتھ سب کچھ کے بارے میں تھا۔ اسے وفاداری سے منتقل کرنا صرف اسی غیر رینک کرنے والے صفحے کا زیادہ خوبصورت ورژن بناتا۔

یہاں جو چیز واقعی کام کرتی ہے وہ ہے منتقلی کو تعمیر سے پہلے آڈٹ کے طور پر برتنا۔ پرانا مواد ڈالیں، مگر پہلے مواد کی فہرست (content inventory) طلب کریں: کون سے صفحات موجود ہیں، ہر ایک اصل میں کس کے لیے رینک کرنے کی کوشش کر رہا ہے، کہاں دو موضوعات ایک URL میں ٹھونسے گئے ہیں اور کہاں ایک موضوع پانچ صفحات پر پتلا پھیلا ہوا ہے۔ یہ فہرست ہی منصوبہ بن جاتی ہے۔ پرانی سائٹ ایک ماخذ ہے، ٹیمپلیٹ نہیں۔

غلطی نمبر دو: یہ بھول جانا کہ URLs ہی وہ چیز ہیں جن پر گوگل واقعی اعتماد کرتا ہے

یہ مہنگی والی غلطی ہے۔ سائٹ کی وہ منتقلی جو پرانے راستوں کو نئے راستوں سے میپ کیے بغیر URL ساخت تبدیل کرتی ہے — چاہے نیا مواد واقعی بہتر ہی کیوں نہ ہو — برسوں کی جمع شدہ اہمیت (signal) ضائع کر دیتی ہے۔ بیک لنکس ایک 404 کی طرف اشارہ کرتے رہتے ہیں۔ گوگل کو ان صفحات کو دوبارہ کرال کر کے دوبارہ اعتماد کمانا پڑتا ہے جن پر وہ پہلے ہی مختلف پتے کے تحت اعتماد کر چکا تھا۔ پرانے بک مارکس اور ای میل دستخطوں سے آنے والا براہ راست ٹریفک بند گلی میں پہنچ جاتا ہے۔

میں نے لوگوں کو یہ بات صرف لانچ کے بعد نوٹس کرتے دیکھا ہے، جب اینالیٹکس ڈیش بورڈ اضافے کے بجائے گراوٹ دکھاتا ہے۔ اس وقت تک کا حل بعد میں شامل کیے گئے ری ڈائریکٹس ہوتے ہیں، جو کچھ نقصان تو بحال کر دیتے ہیں مگر پورا نہیں — "URL منتقل ہو گیا" اور "کسی نے نوٹس کیا اور اسے ٹھیک کیا" کے درمیان کا فرق ہفتوں کی اس اہمیت میں ماپا جاتا ہے جو واپس نہیں آتی۔

اس میں کچھ بھی غیر معمولی نہیں۔ یہ صرف دو کالموں پر مشتمل ایک اسپریڈشیٹ ہے، جو بلڈر کو چھونے سے پہلے بنائی جاتی ہے۔ یہ صرف وہ قدم ہے جسے لوگ چھوڑ دیتے ہیں کیونکہ یہ بورنگ ہے اور تعمیر خود مزیدار حصہ ہے۔

غلطی نمبر تین: بغیر واپسی کے راستے کے یکبارگی تبدیلی

تیسری ناکامی مواد یا URLs کے بارے میں بالکل نہیں ہے — یہ اس بارے میں ہے کہ تبدیلی اصل میں کیسے ہوتی ہے۔ کوئی شخص نئی سائٹ بناتا ہے، پیش نظارہ میں جو دیکھتا ہے وہ پسند آتا ہے، اور اسی سہ پہر ڈومین کو اس کی طرف موڑ دیتا ہے۔ نہ کوئی اسٹیجنگ دورانیہ، نہ حقیقی ٹریفک کے تحت شانہ بشانہ موازنہ، نہ کوئی منصوبہ اگر کچھ خراب ہو جو پیش نظارہ نے نہ پکڑا ہو — ایک رابطہ فارم جو خاموشی سے ناکام ہو رہا ہو، ایک چیک آؤٹ فلو جو ٹیسٹنگ میں کام کرتا ہو مگر حقیقی ادائیگی کے حجم کے تحت رک جائے، ایک صفحہ جو ڈیسک ٹاپ پر ٹھیک نظر آئے مگر عین اسی فون پر ٹوٹ جائے جو آپ کے آدھے گاہک استعمال کرتے ہیں۔

یہاں کا نقصان سب سے زیادہ بلند آواز والی قسم کا ہوتا ہے کیونکہ یہ فوری ہوتا ہے۔ سپورٹ ان باکسز بھر جاتے ہیں۔ کوئی ہر دس منٹ بعد اینالیٹکس ری فریش کرکے گراف کو غلط سمت جاتا دیکھ رہا ہوتا ہے، اور واپس پلٹنے کا مطلب ہے دوبارہ DNS کو ری پوائنٹ کرنا، جسے خود پھیلنے میں وقت لگتا ہے، یعنی برا تجربہ اس فیصلے کے بعد بھی جاری رہتا ہے کہ اسے واپس پلٹا جا چکا ہے۔

حل غیر شاندار ہے: کٹ اوور سے ایک دو دن پہلے DNS TTL کم کر دیں تاکہ ضرورت پڑنے پر رول بیک تیزی سے پھیل جائے، نئی سائٹ کو پہلے پریویو یا سٹیجنگ سب ڈومین پر چلائیں اور اسے بالکل اسی طرح استعمال کریں جیسے کوئی کسٹمر کرے گا، اور کٹ اوور کے بعد کم از کم دو ہفتوں تک پرانی سائٹ کی ہوسٹنگ کو لائیو اور برقرار رکھیں، نئی سائٹ کے آتے ہی اسے ختم نہ کریں۔ آخری حصہ چند ڈالر کی ہوسٹنگ لاگت پر ایک حقیقی انشورنس ہے۔ لوگ اسے چھوڑ دیتے ہیں کیونکہ پرانا پلان کینسل کرنا ایک لوپ بند کرنے جیسا محسوس ہوتا ہے، اور لوپ بند کرنا ترقی جیسا لگتا ہے۔

درست طریقہ اصل میں کیسا نظر آتا ہے

مجموعی طور پر، اس میں سے کوئی بھی چیز غلط طریقوں سے زیادہ کام نہیں ہے — یہ وہی مقدار کا کام ہے بس ایک مختلف ترتیب میں۔ دوبارہ بنانے سے پہلے آڈٹ کریں۔ لانچ سے پہلے URLs کا نقشہ بنائیں۔ کٹ اوور سے پہلے سٹیج کریں، اور کٹ اوور کے بعد کچھ ہفتوں تک واپسی کا راستہ رکھیں۔ جو سائٹ آخر میں سامنے آتی ہے وہ صرف نئی نظر نہیں آتی۔ یہ وہ سب کچھ برقرار رکھتی ہے جو پرانی سائٹ نے پہلے ہی حاصل کر لیا تھا، جو کہ نئے سرے سے شروع کرنے کے بجائے مائیگریٹ کرنے کا پورا مقصد تھا۔