क्लाउड / सिस्टम
मेरी पुरानी WordPress वेबसाइट ने अपना काम निभाया था। कई वर्षों में उसमें लेख, तस्वीरें और पेशेवर जीवन के हिस्से जमा हो गए थे। लेकिन निजी साइट के लिए डेटाबेस वाले content-management system का रखरखाव करना ऐसा लगने लगा था जैसे टेबल लैंप जलाने के लिए इंजन चालू रखना।
मैं कुछ तेज, चलाने में आसान और ज्यादा व्यक्तिगत चाहता था। साथ ही देखना चाहता था कि AI coding partner इस migration में कितनी मदद कर सकता है। कोई काल्पनिक “वेबसाइट बदलें” बटन दबाकर नहीं, बल्कि मेरे साथ असली इंजीनियरिंग फैसलों पर काम करके।
नतीजा यही साइट है जिसे आप अभी पढ़ रहे हैं: अपने हिसाब से बनाया गया cloud-native पोर्टफ़ोलियो, जो Amazon S3 और CloudFront से static files के रूप में मिलता है। पुराने लेख उपलब्ध हैं और नई साइट में फोटोग्राफी, प्रमाणपत्र, ट्रेनिंग डेटा, छोटे गेम और मेरे काम का अधिक पूरा परिचय जुड़ा है।
सफलता WordPress की जगह AI लगाने में नहीं थी। सफलता उस कंटेंट को बचाने में थी जो जरूरी था, और उस मशीनरी को हटाने में जिसकी अब जरूरत नहीं थी।
पहले साफ करें कि “AI-based” से मतलब क्या है
Production वेबसाइट को पेज दिखाने के लिए language model की जरूरत नहीं है। उससे latency, जटिलता और dependency बढ़ेगी, सामान्य विज़िटर को कोई फायदा नहीं मिलेगा। यह static site है और यही इसकी खूबी है।
AI इंजीनियरिंग प्रक्रिया का हिस्सा था। उसने पुराना material जांचने, information architecture सुझाने, लेखन तैयार करने और सुधारने, कोड बनाने और refactor करने, असंगतियां खोजने, responsive behavior बेहतर करने और दोहराए जाने वाले काम को scripts में बदलने में मदद की। Product owner मैं ही रहा: material चुना, धारणाएं सुधारीं, दृश्य नतीजे परखे और production बदलाव मंजूर किए।
इसलिए “AI-assisted” सही वर्णन है। AI का इस्तेमाल साइट बनाने और संभालने में हुआ; विज़िटर तक पहुंचने वाला सिस्टम सरल रहता है।
1. नया डिज़ाइन बनाने से पहले सूची बनाएं
Migration की शुरुआत प्रमाण से होनी चाहिए, नए रंगों से नहीं। प्रस्तुति बदलने से पहले मैंने WordPress posts, pages, categories और media references इकट्ठे किए। मूल कंटेंट structured JSON में export किया और संबंधित फ़ाइलें स्थानीय archive में कॉपी कीं।
इससे दो जरूरी सुरक्षा उपाय बने:
- मशीन से पढ़ा जा सकने वाला content archive, जिसे live site बार-बार scrape किए बिना बदला जा सके;
- मूल तस्वीरों, दस्तावेज़ों और प्रमाणपत्रों की सुरक्षित media library।
मैंने URLs, titles, publication dates, internal links और उस कंटेंट की भी समीक्षा की जो गलती से सार्वजनिक नहीं होना चाहिए। पूरा backup और सार्वजनिक वेबसाइट एक ही चीज नहीं हैं: export में drafts, पुरानी फ़ाइलें, निजी जानकारी और credentials हो सकते हैं। बचाना और प्रकाशित करना अलग फैसले रहने चाहिए।
2. कंटेंट को WordPress से अलग करें
WordPress की सबसे कीमती चीज theme, plugins या database schema नहीं था। वह कंटेंट था। Posts JSON में आ गए और media सामान्य file tree में रख दिया गया, तो presentation layer बदली जा सकने वाली बन गई।
होमपेज पर JavaScript चुने हुए लेखों का डेटा पढ़कर Field Notes cards बनाती है। हर लेख का अपना static HTML page भी है। इससे structured content का लचीलापन मिलता है और search engines तथा सीधे लिंक से आने वाले पाठकों के लिए सामान्य, crawl किए जा सकने वाले URLs भी बने रहते हैं।
“पहले बचाएं, फिर चुनें” के इस तरीके ने migration की आम गलती रोकी: पुराने इतिहास को सिर्फ इसलिए छोड़ देना कि नए डिज़ाइन में उसके लिए साफ जगह नहीं है। पहले archive बचा; संपादकीय फैसले बाद में हुए।
3. नई साइट व्यक्ति के इर्द-गिर्द बनाएं, CMS के नहीं
WordPress स्वाभाविक रूप से साइट को posts की श्रृंखला जैसा बनाता है। मेरी नई साइट का केंद्र अलग होना था: परिचय, पेशेवर काम, करियर की यात्रा, प्रमाणपत्र, तस्वीरें, ट्रेनिंग की प्रगति, तकनीकी नोट्स और थोड़ा मनोरंजन।
हमने यह संरचना सीधे semantic HTML, CSS और JavaScript में बनाई। कोई सामान्य theme हजारों तरह की साइटों को संतुष्ट करने की कोशिश नहीं कर रही। Navigation, typography, mobile menu, तस्वीरों की framing और interactive details इसी एक पोर्टफ़ोलियो के लिए हैं।
नया डिज़ाइन कई दौर में बना। मैं स्थानीय preview देखकर कह सकता था कि terminal मेरी बांह ढक रहा है, portrait कटा हुआ लग रहा है या heading गलत जगह टूट रही है, और implementation तुरंत बदली जा सकती थी। यही छोटा feedback loop AI सहयोग में खास उपयोगी था: दृश्य फैसला मेरा रहा, उसे काम करने वाली CSS में बदलना बहुत तेज हो गया।
4. पुराने URLs और search visibility को production data मानें
नया होमपेज शानदार हो लेकिन वर्षों का खोजे जा सकने वाला material गायब हो जाए, तो redesign सफल नहीं है। हर चुने हुए नोट को अलग URL, स्पष्ट title, meta description और canonical address मिला। पेजों में sharing के लिए Open Graph और Twitter metadata तथा Schema.org structured data भी है, जो कंटेंट को technical article बताता है और मुझे उसके लेखक से जोड़ता है।
Sitemap में मुख्य पेज और संग्रह के नोट्स दोनों हैं। साइट मुझे लगातार “Bernd Kuhlen” के नाम से पहचानती है और “Bernhard Kuhlen” वैकल्पिक नाम है। Robots को crawling के साफ निर्देश मिलते हैं; लोग और search engines interactive homepage चलाए बिना भी सामान्य links खोल सकते हैं।
पुराने permalink पर backlinks या search history हो तो उसे चालू रहना चाहिए या स्थायी redirect से नए पते पर जाना चाहिए। URL mapping migration plan का हिस्सा है, launch के बाद की सफाई नहीं।
5. इन्फ्रास्ट्रक्चर को सरल और अनुमान लगाने योग्य रखें
अंतिम फ़ाइलें private, encrypted और versioned S3 bucket में रखी हैं। सार्वजनिक entry point CloudFront है, जो Origin Access Control से bucket खोलता है। इसलिए storage खुद सार्वजनिक वेबसाइट की तरह उजागर नहीं है। HTTPS अनिवार्य है, आधुनिक TLS जरूरी है और response-headers policy मुख्य browser security headers देती है।
इन्फ्रास्ट्रक्चर सिर्फ AWS console में क्लिक करके नहीं बनाया गया; उसका वर्णन CloudFormation में है। Migration के उस शुरुआती दौर में deployment script stack अपडेट करती थी, सार्वजनिक फ़ाइलों की स्पष्ट allowlist synchronize करती थी और CloudFront cache invalidation करती थी। इससे release दोहराने योग्य बनी और आगे के बदलावों का implementation समीक्षा किया जा सका। संपादकीय अपडेट, 30 अक्टूबर 2026: अब हमारी नीति बिल्कुल अलग है—कोई cache invalidation नहीं की जाती। सार्वजनिक वेबसाइट सामग्री की CDN और browser TTL 3600 सेकंड है; हम पुराने cache की अवधि स्वाभाविक रूप से खत्म होने देते हैं।
Static hosting अनुरोध के रास्ते से WordPress database, PHP runtime, theme updates और plugin patching हटा देती है। इससे संचालन की जिम्मेदारी खत्म नहीं होती; वह एक छोटी और ज्यादा साफ दिखने वाली समस्या बन जाती है।
6. पहले preview, फिर बदलाव लागू करें
पूरे काम के दौरान साइट स्थानीय container में Nginx के पीछे चली। इस preview environment में desktop और phone layout जांचना, पुराने दस्तावेज़ खोलना, गेम खेलना और training charts देखना संभव था, इससे पहले कि कुछ production में जाए।
सुरक्षित बदलाव की योजना में ये चीजें होनी चाहिए:
- कंटेंट में बदलाव रोकना या अंतिम export की स्पष्ट सीमा तय करना;
- डेटाबेस और media का पूरा backup;
- जरूरी URLs की local और staging जांच;
- बदलाव से पहले तैयार DNS records और certificates;
- पुराने origin पर लौटने का रास्ता;
- release के बाद development मशीन से बाहर की जांच।
S3 versioning और Infrastructure as Code वापस संभलने में मदद करते हैं, लेकिन सोच-समझकर बनी rollback प्रक्रिया की जगह नहीं लेते।
7. एप्लिकेशन सर्वर हटाने के बाद ऑब्ज़र्वेबिलिटी जोड़ें
Static website भी टूट सकती है, bots ला सकती है या अनपेक्षित ट्रैफ़िक पा सकती है। CloudFront access logs में requests, status codes, user agents और edge locations दर्ज होते हैं। उन्हीं से CloudWatch dashboard पहुंच की मात्रा और HTTP status समूह दिखाता है। लॉग हमेशा जमा करने के बजाय तय retention अवधि रखी गई है।
भौगोलिक दृश्य बताते हैं कि ट्रैफ़िक कहां से आता दिख रहा है। लेकिन edge location या IP से निकले देश या शहर को सत्यापित व्यक्ति नहीं मानना चाहिए। संचालन का डेटा अनुरोधों के सवालों का जवाब देता है; पहचान शायद ही साबित करता है।
इस ऑब्ज़र्वेबिलिटी से एक उपयोगी baseline भी बनती है। किसी के टूटे लिंक की शिकायत करने का इंतजार करने के बजाय मैं error trends और मांगे जा रहे पाथ देख सकता हूं।
8. Migration से वे चीजें बनाएं जिन्हें WordPress ने बढ़ावा नहीं दिया
पारंपरिक blog theme की सीमा हटने के बाद मेरी असली रुचियां दिखाने वाली सुविधाएं जोड़ना आसान हुआ। Apple Health exports से दिन, हफ्ते और महीने के समेकित training views बने। प्रमाणपत्रों का अलग, आसानी से देखा जा सकने वाला archive बना। निजी तस्वीरों को captions मिले। दो छोटे गेम—Snake और Galaga—Fun section में आ गए।
ये सब अब भी static assets और client-side code के रूप में मिलते हैं। अहम बदलाव भारी platform जोड़ना नहीं था; ऐसी संरचना बनाना था जिसमें छोटी, काम की सुविधाएं साथ रह सकें।
AI ने क्या अच्छा किया और कहां निगरानी जरूरी थी
AI बार-बार की जांच, बदलावों के सुझाव, शुरुआती implementation, भाषा की जांच और कई फ़ाइलों में विस्तृत feedback लागू करने में खास असरदार था। वह content record, article page, sitemap और deployment package के आपसी संबंध ध्यान में रख सकता था।
फिर भी सत्यापन जरूरी था। सही लगने वाला link गलत हो सकता है। तकनीकी रूप से सही layout असली phone पर अजीब दिख सकता है। Generated copy सामान्य लग सकती है या सिस्टम की वास्तविक क्षमता से ज्यादा दावा कर सकती है। Infrastructure commands का असर किसी पैराग्राफ की टाइपो से कहीं आगे जा सकता है।
सबसे उपयोगी workflow बातचीत वाला लेकिन अनुशासित था: असली सिस्टम देखें, सीमित बदलाव करें, preview करें, test करें और उसके बाद प्रकाशित करें। AI ने इस चक्र को तेज किया; खत्म नहीं किया।
दोहराई जा सकने वाली migration checklist
- WordPress database, uploads और configuration का backup लें।
- Posts, pages, taxonomies, dates, authors और media references export करें।
- कंटेंट को सार्वजनिक, निजी, पुराना या अनिश्चित श्रेणियों में बांटें।
- URLs की सूची और redirect map बनाएं।
- असली जरूरतें पूरी करने वाला सबसे सरल target architecture चुनें।
- छोटा design system और दोबारा इस्तेमाल किए जा सकने वाले content templates बनाएं।
- जिस material को खोज में बने रहना है उसके लिए अलग semantic pages बनाएं।
- Metadata, canonical URLs, structured data, robots rules और sitemap जोड़ें।
- Accessibility, responsive layouts, links, documents और error pages जांचें।
- इन्फ्रास्ट्रक्चर और deployment को code के रूप में लिखें।
- Backup, monitoring और परखे हुए rollback रास्ते के साथ बदलाव लागू करें।
- नई साइट भरोसेमंद साबित होने तक archive रखें।
इस चुनाव की कीमत
हर WordPress installation की जगह static site अपने-आप सही नहीं होती। कई गैर-तकनीकी संपादकों, जटिल workflows, comments या बार-बार बदलते server-side data वाले newsroom को परिपक्व CMS या static front end वाले headless CMS से अब भी फायदा हो सकता है।
कोड से संभाले जाने वाले निजी पोर्टफ़ोलियो के लिए संतुलन अलग है। मैंने browser में posts edit करने की सुविधा के बदले छोटा attack surface, अनुमान लगाने योग्य delivery, versioned बदलाव और पूरे अनुभव पर नियंत्रण चुना। AI ने code-based workflow की परेशानी इतनी कम कर दी कि यह सौदा मुझे अच्छा लगा।
मुख्य सीख
पुरानी WordPress साइट फेंकी नहीं गई। उसे सावधानी से अलग किया गया: कंटेंट बचाया, उपयोगी हिस्सों को सामने लाया, प्रस्तुति दोबारा बनाई और इन्फ्रास्ट्रक्चर सरल किया।
Migration से मेरी यही दोहराने लायक सीख है। यह पूछकर शुरू न करें कि कौन-सा AI product WordPress की जगह ले। पहले पूछें कि क्या बचना जरूरी है, साइट को वास्तव में क्या करना है और कौन-सी जटिलता हट सकती है। फिर AI को सक्षम इंजीनियरिंग साथी की तरह इस्तेमाल करें—जिज्ञासु, तेज और मददगार, लेकिन हमेशा असली फ़ाइलों, वास्तविक tests और मानवीय फैसले के साथ।