तीन साल पहले एक क्लायंट ने मुझे गुरुवार की दोपहर को फोन किया, बिल्कुल घबराया हुआ। उन्होंने एक Drupal-से-WordPress माइग्रेशन को एक सस्ते डेवलपर की दुकान को सौंप दिया था, साइट शुक्रवार को लाइव हुई, और सोमवार तक उना ऑर्गेनिक ट्रैफिक 67% गिर गया। खत्म। छह साल का SEO इक्विटी, बस... उड़ गया। कोई रीडायरेक्ट नहीं। हजारों broken URLs। Google का crawl budget तबाह।Drupal-to-WordPress migration to a cheap dev shop, the site went live on a Friday, and by Monday their organic traffic had dropped 67%. Gone. Six years of SEO equity, just... evaporated. No redirects. Thousands of broken URLs. Google's crawl budget torched.
मुख्य बात: Drupal से WordPress माइग्रेशन CMS स्वैप से नहीं, बल्कि URL मैपिंग और टैक्सोनॉमी ट्रांसलेशन में विफल होते हैं; रैंकिंग बनाए रखने के लिए एक संपूर्ण रीडायरेक्ट मैप और मेटाडेटा को ट्रांसपोर्ट करके भेजें।Drupal to WordPress migrations fail on URL mapping and taxonomy translation, not the CMS swap; ship a complete redirect map and transport metadata to keep rankings.
मैंने इस तरह की खराबियों को कितनी बार ठीक किया है, इसका हिसाब लगाना भी नहीं चाहता। Seahawk Media में 12,000+ माइग्रेशन के बाद, मैं आपको आत्मविश्वास के साथ कह सकता हूँ: Drupal से WordPress तक की तकनीकी मूव वास्तव में आसान हिस्सा है। SEO को सुरक्षित रखना वह जगह है जहाँ सब कुछ गलत हो जाता है -- और जहाँ बिल्कुल भी गलत होने की जरूरत नहीं है।Seahawk Media, I can tell you with some confidence: the technical move from Drupal to WordPress is actually the easy part. The SEO preservation is where everything goes wrong -- and where it absolutely doesn't have to.
यह वह प्लेबुक है जो मैं फॉलो करता हूँ। हर बार।
---
Drupal-से-WordPress माइग्रेशन एक SEO खदान क्यों हैं
Drupal और WordPress URLs अलग तरीके से जेनरेट करते हैं। Drupal की डिफ़ॉल्ट पाथ सिस्टम, Pathauto जैसे मॉड्यूल के साथ, अक्सर ऐसी URL संरचनाएँ बनाती है जिनका WordPress के साथ कोई ओवरलैप नहीं होता। Drupal पर /content/our-services/web-design पर एक नोड WordPress पर /our-services/web-design या यहाँ तक कि /web-design बन सकता है, यह इस बात पर निर्भर करता है कि आप परमालिंक कैसे सेट करते हैं। ये अलग URLs हैं। Google उन्हें अलग पेज मानता है। रिडायरेक्ट के बिना, पुराना वाला मर जाता है।/content/our-services/web-design becomes/our-services/web-design or even/web-design on WordPress, depending on how you set permalinks. Those are different URLs. Google sees them as different pages. Without a redirect, the old one is dead.
और यह सिर्फ URLs के बारे में नहीं है। Drupal की टैक्सोनॉमी सिस्टम WordPress कैटेगरीज़ और टैग्स से मैप होती है -- लेकिन बिल्कुल परफेक्ट तरीके से नहीं। Drupal में Custom Content Types WordPress में Custom Post Types बन जाते हैं, और अगर आप माइग्रेशन से पहले उन CPTs को बिल्ड नहीं करते हैं, तो आपका कंटेंट बिल्कुल गलत जगह पर चला जाता है। मैंने एक Drupal-पावर्ड न्यूज़ साइट देखा है जहाँ 800 "article" नोड्स सभी standard WordPress Posts के तौर पर इंपोर्ट हो गए, उस कस्टम आर्काइव स्ट्रक्चर को ओवरराइट करते हुए जिस पर उनकी इंटरनल लिंकिंग निर्भर थी।
यहाँ वह चीज़ है जो ज़्यादातर devs miss करते हैं: migration से पहले WordPress में जो भी structural decision आप लेते हैं, वह directly उन redirects को प्रभावित करता है जिनकी आपको बाद में ज़रूरत होगी। पहले architecture को सही करें। Redirects एक patch हैं, एक plan नहीं।every structural decision you make in WordPress before the migration directly affects which redirects you'll need after it. Get the architecture right first. Redirects are a patch, not a plan.
---
स्टेप 1: प्री-माइग्रेशन ऑडिट -- माइग्रेट करने से पहले जानिए कि आप क्या माइग्रेट कर रहे हैं
Drupal इंस्टॉलेशन को तब तक न छुएँ जब तक आपके पास लाइव साइट का संपूर्ण क्रॉल न हो। मैं Screaming Frog का उपयोग करता हूँ जो 500,000 URLs तक क्रॉल करने के लिए सेट है (पेइड वर्जन)। सब कुछ एक्सपोर्ट करें: URLs, स्टेटस कोड, टाइटल टैग, मेटा विवरण, H1s, कैनोनिकल टैग, इनबाउंड इंटरनल लिंक, शब्द गिनती।Screaming Frog set to crawl up to 500,000 URLs (the paid version). Export everything: URLs, status codes, title tags, meta descriptions, H1s, canonical tags, inbound internal links, word counts.
अपने Google Search Console डेटा भी खींचें। पिछले 16 महीनों में क्लिक्स के आधार पर फिल्टर करें (3 नहीं, न ही 6-16, क्योंकि आप सीज़नल कंटेंट को कैच करना चाहते हैं)। हर वह URL एक्सपोर्ट करें जिसे कम से कम एक क्लिक मिला हो। ये आपके प्रोटेक्टेड URLs हैं। इनमें से किसी पर भी रैंकिंग खोएँ तो क्लाइंट को नोटिस हो जाएगा।protected URLs. Lose rankings on any of these and the client will notice.
मैं specifically क्या देख रहा हूँ:
- Drupal साइट पर पहले से मौजूद डुप्लिकेट कंटेंट (माइग्रेशन के बाद नहीं, पहले ठीक करें) already existing on the Drupal site (fix it before migrating, not after)
- 200 शब्दों से कम की Thin Content पेजेस जो कुछ भी रैंक नहीं करतीं -- इन्हें माइग्रेट करने की बजाय कंसोलिडेट या डिलीट किया जा सकता है under 200 words that rank for nothing -- these can be consolidated or deleted rather than migrated
- गैर-मानक URL पैटर्न जैसे /node/1234 URLs जो Drupal कभी-कभी उजागर करते हैं भले ही Pathauto सक्रिय हो like
/node/1234URLs that Drupal sometimes exposes even when Pathauto is active - Taxonomy आर्काइव पेजेस जो रैंक करती हैं -- /tags/, /category/, /topic/ पाथ्स जिनके पास actual Search Console impressions हैं that rank --
/tags/,/category/,/topic/paths that have actual Search Console impressions
वह आखिरी वाला लोगों को लगातार पकड़ता है। Drupal टैक्सोनॉमी टर्म पेज अक्सर लॉन्ग-टेल क्वेरी के लिए रैंक करते हैं। अगर आप समकक्ष WordPress टैक्सोनॉमी आर्काइव को फिर से नहीं बनाते और पुराने पाथ को रिडायरेक्ट नहीं करते, तो आपने अभी-अभी निष्क्रिय ट्रैफिक फेंक दिया है।and redirect the old paths, you've just thrown away passive traffic.
---
स्टेप 2: URL मैपिंग -- वह स्प्रेडशीट जो कोई बनाना नहीं चाहता
उबाऊ? हाँ। गैर-परक्राम्य? यह भी हाँ।
Google Sheets (या Airtable अगर आप पसंद करते हैं, मैंने दोनों का उपयोग किया है) में एक URL मैप बनाएँ। कॉलम A हर Drupal URL है। कॉलम B वह संबंधित WordPress URL है जिसमें यह रिजॉल्व होगा। कॉलम C एक स्टेटस है: exact match, redirect needed, consolidate, या delete।exact match,redirect needed,consolidate, or delete.
300-पेज साइट के लिए, इसमें आधा दिन लगता है। 8,000-पेज की साइट के लिए -- जिसे Seahawk ने 2021 में एक higher-education क्लाइंट के लिए हैंडल किया था -- तीन लोगों की एक टीम को लगभग चार कार्य दिन और एक बहुत ही उबाऊ शुक्रवार की शाम चाहिए। हर बार काम आता है।
कुछ नियम जिन्हें मैं अनुसरण करता हूँ:
- जहां संभव हो slugs को संरक्षित करें। यदि Drupal के पास /blog/how-to-fix-crawl-errors है, तो WordPress को भी यही slug उपयोग करने दें। अधिकांश समय आप कर सकते हैं। WordPress में Permalink सेटिंग्स WordPress Settings → Permalinks आपको किसी भी पैटर्न से मेल खाने देती है जो Drupal उपयोग कर रहा था।If Drupal has
/blog/how-to-fix-crawl-errors, make WordPress use the same slug. Most of the time you can. The permalink settings in WordPress Settings → Permalinks let you match whatever pattern Drupal was using. - कभी होमपेज पर रीडायरेक्ट मत करो। आलसी डेवलपर्स यही करते हैं। इससे लिंक इक्विटी खत्म हो जाती है और यूजर्स को भ्रम होता है। हर पुराने URL का एक खास डेस्टिनेशन होना चाहिए।Lazy devs do this. It kills link equity and confuses users. Every old URL gets a specific destination.
- Paginated URLs पर ध्यान दें। Drupal पैजिनेशन ?page=1 जैसा दिखता है। WordPress /page/2/ का उपयोग करता है। इन्हें मैप करें या उन्हें 404s के तौर पर छोड़ दें (जो आमतौर पर ठीक है -- पेजिनेटेड पेजेस शायद ही कभी सार्थक लिंक इक्विटी होल्ड करती हैं, लेकिन पहले GSC में कन्फर्म करें)।Drupal pagination looks like
?page=1. WordPress uses/page/2/. Map these or leave them as 404s (which is usually fine -- paginated pages rarely hold meaningful link equity, but confirm in GSC first). - क्वेरी स्ट्रिंग्स को अलग से दस्तावेज़ करें। /search?keys=wordpress जैसी चीजों को रीडायरेक्ट की जरूरत नहीं है। /events?date=2023-06 को शायद जरूरत हो, इस बात पर निर्भर करता है कि वे पेज रैंक करते हैं या नहीं।Things like
/search?keys=wordpressdon't need redirects./events?date=2023-06might, depending on whether those pages rank.
---
स्टेप 3: कंटेंट माइग्रेशन -- FG Drupal to WordPress और वास्तव में क्या होता है
FG Drupal to WordPress प्लगइन ज्यादातर माइग्रेशन में भारी सामान उठाता है। यह सीधे आपके Drupal डेटाबेस से कनेक्ट होता है, नोड्स, यूजर्स, टैक्सोनमी टर्म्स और मीडिया खींचता है। Drupal 7 के लिए, यह शानदार काम करता है। Drupal 9/10 के लिए, आपको प्रीमियम संस्करण की जरूरत है, जो आखिरी बार जब मैंने चेक किया तो लगभग €99 का था। मैनुअल माइग्रेशन की तुलना में हर पैसा खर्च करने लायक है।FG Drupal to WordPress plugin does the heavy lifting for most migrations. It connects directly to your Drupal database, pulls nodes, users, taxonomy terms, and media. For Drupal 7, it works brilliantly. For Drupal 9/10, you'll need the premium version, which is about €99 last time I checked. Worth every penny versus manual migration.
प्लगइन जो चीजें अच्छे से हैंडल करता है:
- नोड बॉडी कंटेंट (मीडिया पाथ सही तरीके से कॉन्फ़िगर करो तो एम्बेडेड इमेजेस सहित)
- टैक्सोनॉमी टर्म्स को WordPress कैटेगरीज/टैग्स में मैप किए हुए
- बेसिक कस्टम फील्ड्स अगर तुम प्रीमियम टियर पर हो
जो चीजें यह हैंडल नहीं करेगा और आपको मैनुअली ठीक करनी होंगी:
- Drupal Views -- ये कस्टम पेज लेआउट/क्वेरीज़ होती हैं। आप इन्हें WordPress में WPGridBuilder जैसे प्लगइन्स का उपयोग करके या सिर्फ कस्टम WP_Query लूप्स से फिर से बनाएंगे -- these are custom page layouts/queries. You'll rebuild these in WordPress using plugins like WPGridBuilder or just custom WP_Query loops
- Webforms -- इन्हें मैन्युअली Gravity Forms या WPForms से मैप करें; लॉजिक ट्रांसफर नहीं होती -- map these to Gravity Forms or WPForms manually; the logic doesn't transfer
- Complex field groups -- Drupal का Field API कुछ सच में अजीब डेटा स्ट्रक्चर सपोर्ट करता है। आपको इन्हें CSV में एक्सपोर्ट करना होगा और WP All Import के ज़रिए इम्पोर्ट करना होगा -- Drupal's Field API supports some genuinely weird data structures. You'll need to export these to CSV and import via WP All Import
- Block content regions -- Drupal की ब्लॉक सिस्टम WordPress विजेट्स/FSE ब्लॉक्स जैसी बिल्कुल नहीं है। यह एक माइग्रेशन टास्क नहीं, डिज़ाइन डिसीजन है -- Drupal's block system is nothing like WordPress widgets/FSE blocks. Design decision, not a migration task
FG Drupal to WordPress खत्म होने के बाद मैं हमेशा एक काम करता हूं: row count चलाना। Drupal में कितने nodes थे? WordPress में अब कितनी posts/CPT एंट्रीज हैं? ये मैच करनी चाहिए (सिवाय जो आपने जानबूझकर एक्सक्लूड किए हों)। 5,000-नोड साइट पर 3% डिस्क्रेपेंसी का मतलब 150 पेज मिसिंग हैं। उन्हें खोजें।
---
स्टेप 4: रीडायरेक्ट्स को इंप्लीमेंट करना बिना अपने सर्वर को तोड़े
एक बार URL मैप बन जाए और कंटेंट WordPress स्टेजिंग वातावरण पर लाइव हो जाए, तो रीडायरेक्ट्स का समय आ गया है। दो टूल्स: छोटी साइट्स के लिए Redirection प्लगइन (~1,000 रीडायरेक्ट्स से कम), और Apache पर बड़ी साइट्स के लिए .htaccess नियम, या Nginx पर nginx.conf ब्लॉक्स।Redirection plugin for smaller sites (under ~1,000 redirects) and.htaccess rules for anything larger on Apache, or nginx.conf blocks on Nginx.
यह स्प्लिट क्यों? Redirection प्लगइन रीडायरेक्ट्स को PHP के जरिए प्रोसेस करता है, जिसका मतलब है हर रीडायरेक्ट चेक के लिए एक सर्वर हिट। 5,000 रीडायरेक्ट्स के साथ 50,000 दैनिक पेजव्यूज़ पर, यह असली ओवरहेड है। सर्वर-लेवल रीडायरेक्ट्स एक ऑर्डर ऑफ मैग्नीट्यूड से तेज़ हैं।
बड़े माइग्रेशन के लिए, मैं Google Sheets से URL मैप एक्सपोर्ट करता हूँ, RewriteRule ब्लॉक्स जेनरेट करने के लिए एक त्वरित स्क्रिप्ट लिखता हूँ, और उन्हें गो-लाइव से पहले .htaccess में डालता हूँ। 20 मिनट लगते हैं। लॉन्च के बाद एक सुस्त साइट की डीबगिंग में घंटों की बचत करता है।RewriteRule blocks, and drop them into.htaccess before go-live. Takes 20 minutes. Saves hours of debugging a sluggish site post-launch.
एक चीज जो लोग नहीं सोचते: रीडायरेक्ट चेन्स। अगर Drupal के पास पहले से ही रीडायरेक्ट्स थे (कई परिपक्व Drupal साइट्स के पास हैं, Redirect मॉड्यूल के माध्यम से), तो आपको उन्हें खोजना होगा और चेन को कोलैप्स करना होगा। A → B → C को A → C बन जाना चाहिए। Google का अपना दस्तावेज़ काफी स्पष्ट है कि चेन्स PageRank ट्रांसफर को धीमा करते हैं, भले ही वे इसे खत्म न करें।redirect chains. If Drupal already had redirects in place (many mature Drupal sites do, via the Redirect module), you need to find those and collapse the chain. A → B → C needs to become A → C.Google's own documentation is pretty clear that chains slow down PageRank transfer, even if they don't eliminate it.
---
Step 5: Post-Launch -- The 72-Hour Window
मंगलवार या बुधवार को लाइव जाएं। कभी शुक्रवार नहीं। मैंने यह सीख 2018 में एक क्लायंट के साथ सीखा -- हमने एक 1,200-पेज माइग्रेशन शुक्रवार दोपहर को लॉन्च किया और शाम 6 बजे एक misconfigured permalink structure डिस्कवर किया। सोमवार तक Google ने पहले से ही broken URLs की एक बड़ी लहर क्रॉल और इंडेक्स कर दी थी।
पहले 72 घंटों में मैं जो मॉनिटर करता हूँ:
- GSC Coverage report -- 404s में स्पाइक के लिए देखें। कुछ तो expected हैं (पुरानी Drupal सिस्टम paths)। आपके money pages में स्पाइक नहीं है। -- watch for a spike in 404s. Some are expected (old Drupal system paths). A spike across your money pages is not.
- Screaming Frog re-crawl -- लॉन्च के अगली सुबह लाइव WordPress साइट को क्रॉल करें। URL count को अपने pre-migration baseline से तुलना करें। -- crawl the live WordPress site the morning after launch. Compare URL count to your pre-migration baseline.
- Redirect spot-checks -- मैन्युअली GSC से अपनी 20 highest-traffic Drupal URLs टेस्ट करें। इन्हें ब्राउज़र में पेस्ट करें। क्या वे सही जगह पर आते हैं? -- manually test your 20 highest-traffic Drupal URLs from GSC. Paste them into a browser. Do they land where they should?
- Canonical tags -- कन्फर्म करें कि WordPress हर पेज पर सही canonical output कर रहा है। Yoast और Rank Math दोनों यह automatically करते हैं, पर फिर भी चेक करें। -- confirm WordPress is outputting the right canonical on every page. Yoast and Rank Math both do this automatically, but check anyway.
- XML sitemap सबमिशन -- नया sitemap GSC में तुरंत सबमिट करें। Google को इसे खुद ढूंढने के लिए प्रतीक्षा न करें। -- submit the new sitemap in GSC immediately. Don't wait for Google to find it.
एक चीज़ जो मैं करता हूँ और ज्यादातर लोग छोड़ देते हैं: migration के बाद, पुरानी Drupal XML sitemap को भी GSC में जमा करें, अगर आपने पुराने domain या subdomain को잠시के लिए बनाए रखा है तो उसे point करते हुए। यह Google को बताता है कि कौन से पुराने URLs को crawl करना है, redirects को follow करना है, और अपने index को तेजी से update करना है।submit the old Drupal XML sitemap in GSC as well, after launch, pointing at the old domain or subdomain if you kept it up temporarily. This tells Google exactly which old URLs to crawl, follow the redirects, and update its index faster.
---
चरण 6: 30-दिन की SEO स्वास्थ्य जांच
एक migration go-live पर पूरी नहीं होती। Index को update होने में समय लगता है। 30-दिन के निशान पर मैं यह देखता हूँ:
- Ranking position में बदलाव -- migration से 30 दिन पहले और 30 दिन बाद के keyword positions की तुलना करने के लिए Ahrefs या Semrush का उपयोग करें। कुछ terms पर मामूली उतार-चढ़ाव (5-10 positions) की उम्मीद रखें। किसी primary keyword पर 30+ positions की गिरावट की जांच की जरूरत है। -- use Ahrefs or Semrush to compare keyword positions 30 days pre-migration vs. 30 days post. Expect minor fluctuation (5-10 positions) on some terms. A drop of 30+ positions on a primary keyword needs investigation.
- Backlink targets -- अगर आपके पास विशिष्ट Drupal URLs की ओर pointing external backlinks थे, तो जांचें कि वे URLs cleanly redirect हो रहे हैं। Ahrefs का Lost Backlinks report इसे सामने लाता है। Broken backlink targets वह link equity हैं जिसे आप सक्रिय रूप से खो रहे हैं। -- if you had external backlinks pointing to specific Drupal URLs, check that those URLs are redirecting cleanly. Ahrefs' Lost Backlinks report surfaces this. Broken backlink targets are link equity you're actively haemorrhaging.
- Page speed regression -- WordPress sites कभी-कभी well-tuned Drupal sites से धीमे होते हैं। अपने 5 सबसे महत्वपूर्ण pages पर Lighthouse audit चलाएं और अपनी pre-migration baseline से तुलना करें। -- WordPress sites are sometimes slower than well-tuned Drupal sites. Run a Lighthouse audit on your 5 most important pages and compare to your pre-migration baseline.
- Indexation rate -- आपके submit किए गए URLs में से कितने indexed हैं? 30 दिन पर, आप अपने main content pages का कम से कम 80% indexed चाहते हैं। 60% से कम कुछ भी crawlability समस्या सुझाता है (robots.txt जांचें और सुनिश्चित करें कि आपने accidentally WordPress Settings → Reading में Googlebot को block नहीं किया)। -- how many of your submitted URLs are indexed? At 30 days, you want at least 80% of your main content pages indexed. Anything under 60% suggests a crawlability problem (check robots.txt and make sure you didn't accidentally block Googlebot in WordPress Settings → Reading).
Seahawk का पिछले साल एक फिनटेक क्लाइंट था जहाँ 30 दिन की जांच से पता चला कि 340 प्रोडक्ट पेजों को गलती से माइग्रेशन के दौरान एक गलत कॉन्फ़िगर किए गए Yoast बल्क एक्शन द्वारा noindex पर सेट कर दिया गया था। 30 दिन में पकड़े गए: दोपहर में ठीक किए जा सकते हैं। 6 महीने में पकड़े गए: संभवतः एक रैंकिंग छेद है जिसे आप भरने की कोशिश कर रहे हैं।noindex by a misconfigured Yoast bulk action during migration. Caught at 30 days: fixable in an afternoon. Caught at 6 months: probably a ranking hole you're still trying to fill.
---
FAQ
Drupal से WordPress माइग्रेशन वास्तव में कितना समय लेता है?
पूरी तरह site size और content complexity पर निर्भर करता है। एक 50-page brochure site: 2-3 दिन QA सहित। एक 5,000-page news archive custom content types के साथ: 6-10 सप्ताह। SEO work -- audit, URL mapping, redirect implementation, post-launch monitoring -- आमतौर पर core development estimate में 30-40% जोड़ता है। किसी को आपको कुछ और न कहने दें।
क्या Drupal से WordPress में माइग्रेट करने के बाद मैं रैंकिंग खो दूंगा?
Short-term fluctuation सामान्य है और लगभग अपरिहार्य है। अगर आपने URL mapping, redirects, और canonical tags सही तरीके से किए हैं, तो ज्यादातर rankings 6-12 सप्ताह में स्थिर हो जाते हैं। जिन sites को मैंने permanent losses suffer करते देखा है, उन सभी की एक ही समस्या थी: या तो कोई redirects नहीं, या mass redirects जो homepage की ओर pointing हैं। काम करो। Rankings वापस आते हैं।
क्या मुझे सभी Drupal कंटेंट माइग्रेट करना चाहिए या नए सिरे से शुरू करना चाहिए?
इस बात पर निर्भर करता है कि content आपके लिए क्या कर रहा है। अपना GSC data खींचें। कोई भी content जिसके 16 महीने में zero clicks हैं और कोई backlinks नहीं हैं, deletion के लिए एक candidate है migration के बजाय। Thin, low-value content migrate करना आपकी WordPress site को bloat करता है और crawl budget को dilute कर सकता है। Ruthless बनें। यह कहा जा रहा है, कभी भी किसी URL को delete न करें जिसके पास कोई भी external backlinks हों, भले ही page खुद rubbish हो -- इसे कुछ relevant की ओर redirect करें।
Drupal माइग्रेशन के बाद WordPress के लिए सबसे अच्छा थीम कौन सा है?
ईमानदारी से, अगर आप अच्छी तरह से संरचित HTML का उपयोग कर रहे हैं और पेज स्पीड में ध्यान रख रहे हैं, तो थीम चुनाव के लगभग कोई SEO प्रभाव नहीं है। मैं GeneratePress को इसके क्लीन मार्कअप और न्यूनतम ओवरहेड के लिए, या Kadence को डिफॉल्ट करता हूँ अगर क्लाइंट को अधिक डिजाइन लचीलापन चाहिए। पेज-बिल्डर-हेवी थीम्स से बचें जो हर पेज लोड पर 400KB अप्रयुक्त CSS को आउटपुट करते हैं।GeneratePress for its clean markup and minimal overhead, or Kadence if the client wants more design flexibility. Avoid page-builder-heavy themes that output 400KB of unused CSS on every page load.
क्या मुझे डेवलपर की जरूरत है या मैं यह खुद कर सकता हूँ?
50 pages से कम simple content के साथ एक छोटी site के लिए और कोई custom post types नहीं? आप शायद FG Drupal to WordPress और Redirection plugin के साथ, ऊपर दिए गए steps का पालन करते हुए manage कर सकते हैं। किसी भी बड़ी चीज़ के लिए, या CPTs, complex taxonomies, या meaningful existing SEO footprint वाली कोई भी चीज़ के लिए -- एक developer लें। एक botched migration को ठीक करने की लागत हमेशा इसे सही तरीके से करने की लागत से ज्यादा होती है।
---
Migration खुद शायद काम का 40% है। बाकी 60% वह SEO infrastructure है जो आप इसके चारों ओर बनाते हैं -- mapping, redirects, monitoring, 30 दिन के लिए data देखने की धैर्य victory की घोषणा करने से पहले। मैंने beautifully built WordPress sites को search में tank करते देखा है क्योंकि redirect work sloppy था, और मैंने scrappy, barely-themed WordPress installs को हर ranking hold करते देखा है क्योंकि URL map meticulous था।
बोरिंग स्टफ को सही तरीके से करो। बाकी सब कुछ आम तौर पर फॉलो कर जाता है।