URL Slug जनरेटर

URL slug क्या है?

A slug is the human-readable, URL-safe path segment that identifies a page within a site. It sits at the tail of the URL and replaces what would otherwise be an opaque database identifier with a descriptive token. In https://example.com/blog/2026/my-awesome-post, the slug is my-awesome-post. Mechanically, a slug is the output of a deterministic transformation: take an arbitrary input string, strip everything that isn't allowed in a URL path segment, fold case, replace whitespace with a separator, and emit ASCII. The transformation is one-way in practice, you can't reliably reconstruct "My Awesome Post: Take Two!" from my-awesome-post-take-two: which is why slugs are stored alongside the original title, not in place of it.

अच्छे slug केवल छोटे अक्षर, अंक और हाइफ़न का उपयोग करते हैं। वे उच्चारण, विशेष वर्ण और स्पेस हटाते हैं।

शब्द कहाँ से आया, 19वीं सदी के newsrooms

यह शब्द web से एक सदी पहले का है। Linotype-era के composing rooms में, type की प्रत्येक पंक्ति को एक एकल metal strip के रूप में डाला जाता था (एक «slug») लगभग तीस picas चौड़ा और लगभग बारह औंस सीसा वज़न में। शब्द फिर एक छोटे identifier के अर्थ की ओर बढ़ गया जो एक editor एक story के शीर्ष पर लिखता था ताकि production के दौरान उसे label किया जा सके: एक- या दो-शब्द handle जैसे mayor-budget या school-fire जिसका उपयोग journalists, sub-editors और printers पूरी headline टाइप किए बिना story को संदर्भित करने के लिए कर सकते थे। AP और प्रमुख-दैनिक style guides अभी भी इस उपयोग का दस्तावेज़ रखती हैं।

जब Movable Type, WordPress और शुरुआती Django docs ने 2000 के दशक की शुरुआत में «slug» को field नाम के रूप में अपनाया, तो वे newsroom शब्द को पूरी तरह उधार ले रहे थे। Django का documentation field को कम से कम 2005 की 0.91 release के बाद से slug कहता है, अब-canonical परिभाषा के साथ: एक छोटा label जिसमें केवल अक्षर, संख्याएँ, underscores या hyphens होते हैं, आमतौर पर URLs में उपयोग किया जाता है। रूपक बिल्कुल सही बैठता है क्योंकि lead-cast slug और URL slug दोनों ही छोटे, अलग, machine-friendly tokens हैं जो किसी लंबी चीज़ की ओर इंगित करते हैं।

RFC 3986 और unreserved character set

URL syntax is defined by RFC 3986 ("Uniform Resource Identifier (URI): Generic Syntax"), published January 2005 by Tim Berners-Lee, Roy Fielding and Larry Masinter, replacing RFCs 2396 and 2732. It is an STD 66 Internet Standard, the IETF's highest maturity tier, reserved for protocols of demonstrated stability and broad implementation. Section 2.3 of RFC 3986 defines the unreserved characters, the only characters that are guaranteed to be safe in any URI component without percent-encoding: A-Z, a-z, 0-9, hyphen, period, underscore, and tilde. That's sixty-six characters total. Everything else is either a reserved character (with structural meaning in some URI component) or "other", anything in the latter group must be percent-encoded if it appears in a URI.

क्योंकि unreserved set अब तक लिखे गए हर URI parser के माध्यम से साफ-सुथरे ढंग से round-trip करने की गारंटी वाला एकमात्र set है, slug generators लगभग समान pipeline पर converge होते हैं: alphabetic characters को lowercase करें, digits रखें, hyphens रखें, whitespace को एक hyphen से बदलें, और बाकी सब को या तो strip करें या transliterate करें। Underscore, period और tilde तकनीकी रूप से अनुमत हैं लेकिन slugs में पारंपरिक रूप से टाला जाता है, period file extensions से टकराता है, tilde पुरानी URL conventions में home directory के रूप में पढ़ा जाता है, और underscore नीचे कवर किए गए SEO कारणों से hyphen से हार जाता है।

«Cool URIs Don’t Change», Berners-Lee, 1998

Tim Berners-Lee का 1998 का style note «Cool URIs Don’t Change», W3C site पर hosted, अब तक लिखा गया slug दर्शन का सबसे अधिक उद्धृत टुकड़ा है। शुरुआती पंक्ति प्रसिद्ध है: एक cool URI वह है जो बदलता नहीं है। Note फिर URL designs के खिलाफ एक polemic की तरह पढ़ा जाता है जो path में क्षणिक implementation विवरणों को सेंकते हैं। अनुशंसित न-करें ने लगभग तीस वर्षों से slug अभ्यास को आकार दिया है: URL में authoring-tool extensions न डालें (वे implementation को लीक करते हैं और जब आप migrate करते हैं तो टूट जाते हैं; URL में status न डालें) pages «current» से बाहर जाते हैं लेकिन URL को नहीं चाहिए; authors के नाम न डालें, authors आगे बढ़ जाते हैं; तब तक तारीखें न डालें जब तक तारीख resource के लिए मौलिक न हो; canonical URL में session IDs, query parameters या login state न डालें।

Slug (descriptive, semantic, lowercase-hyphen-words) बिल्कुल वही है जिसकी «cool» URI में अनुमति है। बाकी सब structural सजावट है जिसे address में नहीं बहना चाहिए। WordPress का permalink design, Django का SlugField और Rails का to_param सभी इस मार्गदर्शन को internalize करते हैं: एक URL emit करें जो page का अर्थ है, इसे कैसे serve किया जाता है इसकी mechanics नहीं।

Hyphens underscores को हराते हैं, और यह दस्तावेज़ है

2005 के WebmasterWorld interview में, Google engineer Matt Cutts ने कहा कि hyphens को Google के tokenizer द्वारा शब्द separators के रूप में माना जाता है, जबकि underscores word joiners हैं। तो green-apples को दो tokens green और apples के रूप में पढ़ा जाता है, जबकि green_apples को एकल token green_apples के रूप में पढ़ा जाता है। query «green apples» के लिए, hyphenated URL title-keyword check से मेल खाएगा; underscored URL नहीं। Cutts ने इसे 2007 में अपने blog पर और 2011 के Google Webmaster Help video पर YouTube («Underscores vs. dashes in URLs») में पुनर्विज़िट किया, उसी सलाह की पुष्टि की और बताया कि Google ने एक बिंदु पर underscore व्यवहार को separator के रूप में भी कार्य करने के लिए बदलने का मूल्यांकन किया था लेकिन ऐसा नहीं किया क्योंकि इसने बहुत सारी मौजूदा URLs को तोड़ दिया होता जो जानबूझकर underscores को joiners के रूप में उपयोग करती थीं (__init__.py, programming function नाम)।

Google का वर्तमान «URL structure best practices for Google Search» page सीधे hyphens की सिफारिश करता है: एक URL जैसे /green-dress.html /greendress.html से अधिक उपयोगी है, और आपको underscores के बजाय hyphens का उपयोग करना चाहिए। यह सिफारिश बीस से अधिक वर्षों से लगातार दस्तावेज़ की गई है। प्रति URL प्रभाव छोटा है लेकिन हजारों pages की site पर compounds होता है, और hyphens को underscores में बदलने का कोई लाभ नहीं है, ऐसा कोई SEO परिदृश्य नहीं है जहाँ underscores जीतते हों। हर विश्वसनीय slug guide उसी सलाह के साथ समाप्त होती है: hyphens का उपयोग करें।

Unicode normalization, NFD कैसे accents निकालता है

Unicode standard कई accented characters को encode करने के दो तरीके परिभाषित करता है: precomposed (एक एकल code point, जहाँ é U+00E9 है) और decomposed (एक base letter जिसके बाद combining marks होते हैं, जहाँ é U+0065 plus U+0301 है, combining acute accent)। दृष्टिगत रूप से समान, byte-for-byte भिन्न। Unicode Technical Standard #15 चार normalisation forms परिभाषित करता है (NFC, NFD, NFKC, NFKD) और slug generation के लिए, NFD lever है। यदि आप एक input string लेते हैं, NFD में normalize करते हैं, फिर Unicode range U+0300 से U+036F (Combining Diacritical Marks block) में हर code point को strip करते हैं, तो आपको base ASCII letter वापस मिलता है। Café cafe बन जाता है, naïve naive बन जाता है, François Francois बन जाता है, niño nino बन जाता है, crème brûlée creme brulee बन जाता है।

NFD उन characters को fold नहीं करता जो base+mark में decomposable नहीं हैं। German ß (sharp s) NFD के तहत ss में decompose नहीं होता, इसे स्पष्ट transliteration की आवश्यकता होती है। Polish ł (l with stroke) l में decompose नहीं होता। Norwegian ø o में decompose नहीं होता। Icelandic þ (thorn) और ð (eth) को lookup tables की आवश्यकता होती है। Browsers ने लगभग 2015 (Chrome 34, Firefox 31, Safari 10) के बाद से String.prototype.normalize() का native रूप से समर्थन किया है, यही कारण है कि छोटे JavaScript slugify utilities भी library के बिना diacritic-stripping कार्य कर सकते हैं।

slugify library परिवार, हर ecosystem क्या भेजता है

Django का django.utils.text.slugify() Python framework में 2000 के दशक की शुरुआत से है। यह lowercase करता है, [A-Za-z0-9_-] में नहीं वाले characters को strip करता है, और whitespace को hyphens से बदलता है। Django 1.9 (2015) के बाद से एक allow_unicode=True keyword Unicode-aware mode पर switch करता है जो non-ASCII letters को preserve करता है। यह reference implementation है जिसे बाकी सब copy करते हैं। Node.js में, Sindre Sorhus का @sindresorhus/slugify npm पर सबसे अधिक downloaded slugify package है, लाखों साप्ताहिक downloads के साथ, features में human-readable separators, customisable replacements (ताकि आप & को and, @ को at पर map कर सकें), Unicode handling और locale-aware lowercase (Turkish dotted/dotless I, German ß → ss) शामिल हैं। Django का उपयोग न करने वाले Python users के लिए, Val Neekman का python-slugify PyPI पर unidecode transliteration library को wrap करता है और slug-specific व्यवहार जोड़ता है: regex word-splitting, replacement characters, max length, stop-word removal।

अन्य ecosystems उसी pattern का अनुसरण करते हैं। PHP के पास Cocur का cocur/slugify Packagist पर है, जिसका उपयोग Laravel और Symfony plugins द्वारा किया जाता है, और Symfony स्वयं संस्करण 5.0 से symfony/string में एक AsciiSlugger भेजता है। Ruby on Rails String#parameterize का उपयोग करता है, ActiveSupport में कम से कम Rails 1.0 से built-in; friendly_id gem शीर्ष पर history-tracking और collision-handling layers जोड़ता है। Go के पास अस्सी से अधिक भाषाओं के लिए locale tables के साथ gosimple/slug है। Rust के पास slug crate है। Java के पास Apache Commons Text और slugify-jvm है। उल्लेखनीय बात यह है कि API कितनी convergent है: input string, slug string out, उसी मुट्ठी भर options के साथ, separator, max-length, lowercase, locale। Absolutool का उपकरण उसी परिवार में बैठता है लेकिन पूरी तरह से आपके browser में चलता है, बिना किसी library के install करने के।

WordPress: web का 43% यह pipeline चलाता है

WordPress web पर सबसे बड़ा एकल slug-emitting system है, यह W3Techs के 2026 सर्वेक्षण के अनुसार सभी websites का लगभग 43% शक्ति देता है, इसलिए इसकी slug conventions अधिकांश पाठकों के लिए प्रभावी रूप से web की slug conventions हैं। जब एक post save किया जाता है, WordPress sanitize_title() के माध्यम से title से slug auto-generate करता है (जो default rewrite case के लिए sanitize_title_with_dashes() कॉल करता है): lowercase, HTML strip करें, entities decode करें, whitespace और अधिकांश punctuation को hyphens से बदलें, असुरक्षित characters को percent-encode करें, adjacent hyphens को collapse करें, leading/trailing hyphens को trim करें। यदि परिणाम मौजूदा post के slug से टकराता है, तो WordPress -2, -3, और इसी तरह जोड़ता है। Slug post editor में editable है, एक बार post प्रकाशित होने के बाद, slug बदलने से हर मौजूदा link टूट जाता है जब तक कि publisher एक redirect स्थापित नहीं करता। WordPress ऐतिहासिक रूप से non-ASCII characters को default रूप से transliterate नहीं करता था; यह उन्हें percent-encode करता था, जो प्रसिद्ध रूप से बदसूरत Cyrillic URLs जैसे %D0%BF%D1%80%D0%B8... उत्पन्न करता था जिन्हें ठीक करने के लिए Cyr-To-Lat जैसे plugins लिखे गए थे।

Latin से परे: Cyrillic, CJK, Arabic के लिए transliteration

NFD केवल उन characters को संभालता है जो ASCII base + combining marks में decompose होते हैं। Non-Latin scripts के लिए, slug pipeline को transliteration की आवश्यकता है, प्रत्येक non-Latin character का इसके Latin-script समकक्ष से एक mapping। Canonical Python library unidecode है, मूल रूप से 2001 के Sean M. Burke के Perl Text::Unidecode का port, जो Basic Multilingual Plane में लगभग हर character को best-guess ASCII string पर map करता है: Москва → Moskva, Αθήνα → Athena। CJK fallback विवादास्पद बिट है: unidecode सभी CJK characters के लिए Mandarin pinyin का उपयोग करता है क्योंकि चीनी के पास सबसे बड़ा CJK character coverage है, जो जापानी के लिए निरर्थक romanisations उत्पन्न करता है (東京 → Dong Jing pinyin में, Tokyo नहीं)। Japanese-specific उपकरण जैसे pykakasi kanji + kana को उचित rōmaji में convert करने का काम करते हैं। International Components for Unicode (ICU) library, Unicode Consortium और IBM द्वारा maintained, Russian-Latin/BGN, Greek-Latin/UNGEGN, और Han-Latin जैसे named rule sets के साथ एक Transliterator API प्रदान करती है जो आधिकारिक romanisation standards को implement करती है। Absolutool का उपकरण हल्के सिरे पर बैठता है: यह Latin diacritics को NFD के माध्यम से fold करता है और बाकी सब को छोड़ देता है। एक उपयोगकर्ता जो एक slugged Russian या Chinese title चाहता है, text paste करने से पहले एक अलग transliteration step चला सकता है।

URL लंबाई की सीमाएँ, 2,000 character नियम कहाँ से आता है

RFC 3986 स्वयं द्वारा कोई लंबाई सीमा specified नहीं है, URI syntax असीमित है। हर सीमा व्यावहारिक है। Internet Explorer ने ऐतिहासिक रूप से URLs को 2,083 characters पर capped किया (Trident engine में baked एक hard limit), जो व्यापक रूप से उद्धृत «2,000 character» rule of thumb की उत्पत्ति है। Chrome, Firefox, Safari और modern Edge address bar में लगभग 64,000 से 100,000+ characters तक URLs का समर्थन करते हैं। Apache का LimitRequestLine default पूरी request line के लिए 8,190 bytes है; nginx का large_client_header_buffers default 8 KB है; IIS URL के लिए 16,384 bytes और query string के लिए 4,096 default है। RFC 9110 (HTTP/1.1, 2022) §4.1 में सिफारिश करता है कि एक server «ought to be capable of handling URIs of length 8,000 octets or longer» लेकिन ऊपरी सीमा अनिवार्य करने तक नहीं जाता। Slugs के लिए, जो मायने रखता है वह यह है कि वे SEO और shareability के लिए पारंपरिक रूप से छोटे होते हैं, तीन से सात शब्द, तीस से साठ characters। Google के John Mueller ने कई Webmaster Hangouts में कहा है कि URL लंबाई स्वयं ranking signal नहीं है, लेकिन लंबी URLs को search-result snippets में truncated किया जा सकता है, click-through rates को नुकसान हो सकता है, और social shares में अव्यवसायिक दिख सकते हैं। अधिकांश slug generators इसी कारण से max-length option expose करते हैं; यह default unlimited है और आपको cap सेट करने देता है।

Stop-word हटाना: dense vs grammatical

कई slugify libraries optional stop-word removal प्रदान करती हैं, slug को assemble करने से पहले सामान्य छोटे शब्दों (a, an, the, of, is, and, or, to, in, for, on) को छोड़ दें। तर्क यह है कि वे कोई SEO signal नहीं जोड़ते और URL को pad करते हैं। तो «The Best Way to Make a Cup of Tea» best-way-make-cup-tea (5 tokens, 24 characters) बन जाता है the-best-way-to-make-a-cup-of-tea (10 tokens, 35 characters) के बजाय। Trade-off: छोटा और denser, लेकिन कभी-कभार व्याकरणिक collapse के साथ (how-to-be-good stripped how-good अर्थ खो देता है) और उन शब्दों को हटाने का जोखिम जो वास्तव में intent ले जाते हैं (art-of-war stripped art-war)। WordPress default रूप से stop words को strip नहीं करता (यह opt-in plugin व्यवहार है) और अधिकांश आधुनिक slug generators इसे default रूप से बंद रखते हैं और इसे एक checkbox के रूप में सामने लाते हैं। WordPress के लिए Yoast SEO एक error के बजाय एक मामूली सिफारिश के रूप में stop words वाले slug को flag करता है। यह generator stop words को स्वचालित रूप से strip नहीं करता, इस आधार पर कि publisher title के intent को एक static word list की तुलना में बेहतर जानता है। यदि आप उन्हें जाने देना चाहते हैं, तो output को सीधे edit करें।

Slug collisions: जब दो posts एक title share करें तो CMSes क्या करते हैं

जब दो posts एक ही slug auto-generate करते हैं («My Post» और «My-Post!» दोनों my-post उत्पन्न करते हैं) तो system को संघर्ष को हल करना होगा। सबसे आम रणनीतियाँ: एक numeric suffix (my-post-2, my-post-3) (predictable, कभी टकराव नहीं, लेकिन suffix कोई semantic difference नहीं ले जाता; एक date prefix (2026-04-27/my-post)) blog content के लिए अच्छा काम करता है और Jekyll, Hugo और अधिकांश news sites में default है; एक author suffix (my-post-jane) (Medium और multi-author blogs द्वारा उपयोग; एक random hash suffix (my-post-a3f9)) Stack Overflow, Notion और shortlinking systems द्वारा उपयोग, मानवीय पठनीयता को guaranteed uniqueness के लिए trade करना; या publish time पर manual edit, संपादकीय रूप से साफ लेकिन शायद ही default है क्योंकि यह flow को बाधित करता है। अधिकांश CMSes के लिए व्यावहारिक विकल्प escape hatch के रूप में manual editing के साथ numeric suffix है। Date-prefixed permalinks time-anchored content के लिए लोकप्रिय हैं जहाँ तारीख सार्थक जानकारी है।

SEO प्रभाव: एक मामूली लेकिन दृश्यमान signal के रूप में slug

Google का ranking documentation URL structure को एक मामूली ranking signal के रूप में सूचीबद्ध करता है, page content, backlinks, user-engagement signals और freshness सभी अधिक भार ले जाते हैं। लेकिन URL शब्द योगदान देते हैं, और वे दृश्य रूप से योगदान देते हैं। Slug terms title के नीचे SERP snippet URL line में दिखाई देते हैं, जो click-through rate को प्रभावित करता है तब भी जब slug स्वयं ranked नहीं है। Slug terms SERP में bolded दिखाई दे सकते हैं यदि वे user की query से मेल खाते हैं, अतिरिक्त visual weight। आंतरिक और बाहरी links का anchor text अक्सर URL पर default होता है जब कोई link text supplied नहीं होता, इसलिए एक semantic slug link text बन जाता है और inbound link equity के माध्यम से अपने keywords को ले जाता है। Publishers में A/B tests लगातार दिखाते हैं कि descriptive slugs opaque IDs पर single-digit प्रतिशत से CTR बढ़ाते हैं। Backlinko का 2020 ranking-factors अध्ययन (1.18 मिलियन SERPs analyzed) ने पाया कि छोटी URLs ने SERPs के शीर्ष पर लंबी URLs से थोड़ा बेहतर प्रदर्शन किया।

«अधिक keywords = बेहतर» intuition के लिए एक अपवाद है: keyword stuffing। सितंबर 2012 Exact-Match Domain (EMD) update ने विशेष रूप से निम्न-गुणवत्ता वाले exact-match domains और slugs (cheap-life-insurance.com/buy-cheap-life-insurance) के लिए credit कम कर दिया, और Google ने तब से URLs में keyword stuffing को discount करना जारी रखा है। 2026 की takeaway: slug में keyword उपस्थिति मामूली रूप से मदद करती है; keyword stuffing नुकसान करता है। एक slug से सबसे बड़ा एकल SEO जीत प्रकाशन के बाद इसे न बदलना है। Inbound links एक URL में जमा होते हैं। Page authority URL स्तर पर compounds होती है। एक 301 redirect link equity का अधिकांश लेकिन सभी नहीं को preserve करता है, और केवल यदि publisher वास्तव में redirect स्थापित करता है, कई नहीं करते। Berners-Lee का «Cool URIs Don’t Change» सलाह के सीधे SEO परिणाम हैं: हर slug परिवर्तन, यहाँ तक कि एक redirect के साथ भी, एक छोटी मात्रा का authority खर्च करता है जिसे recover करने में समय लगता है।

slug के लिए SEO सर्वोत्तम प्रथाएँ

• slug छोटे रखें (3-5 शब्द आदर्श हैं)
• लक्षित कीवर्ड शामिल करें
• हाइफ़न का उपयोग करें, अंडरस्कोर नहीं (Google हाइफ़न को शब्द विभाजक के रूप में मानता है)
• जब वे कुछ नहीं जोड़ते तो स्टॉप वर्ड्स (the, is, and, आदि) हटाएँ
• केवल छोटे अक्षरों का उपयोग करें
• प्रकाशन के बाद slug बदलने से बचें (या रीडायरेक्ट सेट करें)
• non-ASCII characters को strip या transliterate करें जब तक कि आपका platform analytics, social shares और email clients में IRIs को साफ-सुथरे ढंग से न संभालता हो।
• तब तक तारीखें टालें जब तक तारीख resource के लिए मौलिक न हो; file extensions, session IDs, author names और status words टालें।

अक्सर पूछे जाने वाले प्रश्न

क्या यह उच्चारित वर्णों का समर्थन करता है?

हाँ। जनरेटर उच्चारण हटाने के लिए Unicode सामान्यीकरण (NFD) का उपयोग करता है। उदाहरण: "café" "cafe" बन जाता है।

हाइफ़न या अंडरस्कोर उपयोग करें?

SEO के लिए हाइफ़न अनुशंसित हैं। Google की आधिकारिक दस्तावेज़ीकरण पुष्टि करती है कि URL में हाइफ़न को शब्द विभाजक के रूप में माना जाता है।

Emoji और symbols का क्या होता है?

Emoji URL unreserved character set में नहीं हैं, और NFD उन्हें decompose नहीं करता, उनका कोई Latin समकक्ष नहीं है। यह generator उन्हें छोड़ देता है। अन्य उपकरण emoji को percent-encode करते हैं (एक एकल character को %F0%9F%94%A5 जैसी लंबी string में बदलते हुए), जो modern browsers में तकनीकी रूप से काम करता है लेकिन analytics, social shares और email previews में अपठनीय URLs उत्पन्न करता है। अधिकांश slug guides emoji को पूरी तरह से strip करने की सिफारिश करती हैं; यदि आप उन्हें preserved चाहते हैं, तो slug step से पहले उन्हें percent-encode करें।

क्या यह Russian, Chinese या Arabic titles को slugify करेगा?

अपने आप पर नहीं। NFD केवल Latin-script accented characters को folds करता है; यह Cyrillic, Greek, Arabic, Hebrew या CJK scripts को Latin में transliterate नहीं कर सकता। इस उपकरण में एक Russian या Chinese title paste करना उन characters को छोड़ देगा और एक खाली या लगभग-खाली slug उत्पन्न करेगा। सही workflow पहले एक transliteration step चलाना है (Python का unidecode, JavaScript का transliteration npm package, या Wikipedia की romanisation conventions) और romanised परिणाम यहाँ paste करना। विशेष रूप से Japanese के लिए, pykakasi जैसे kana-aware उपकरण का उपयोग करें: सामान्य CJK transliterators Mandarin pinyin लागू करते हैं और 東京 के लिए Tokyo के बजाय Dong Jing उत्पन्न करते हैं।

यदि मुझे प्रकाशन के बाद slug बदलने की आवश्यकता है तो क्या?

Slug बदलने से पहले पुरानी URL से नई URL में एक 301 redirect स्थापित करें। एक 301 («Moved Permanently») पुरानी URL में जमा हुई link equity का अधिकांश preserve करता है और crawlers और browsers से कहता है कि वे अपने bookmarks update करें। बिना redirect के, हर मौजूदा inbound link टूट जाता है और आप उन links द्वारा represented page authority खो देते हैं। एक redirect के साथ भी, आप equity की एक छोटी मात्रा खो देते हैं जिसे recover करने में सप्ताह या महीने लगते हैं। Berners-Lee का maxim (cool URIs don’t change) आंशिक रूप से सौंदर्य है, आंशिक रूप से एक SEO सच्चाई: हर slug परिवर्तन कुछ खर्च करता है, इसलिए पहली बार में slug सही करना उचित है।

क्या एक अनुशंसित slug लंबाई है?

Convention तीन से सात शब्द है, मोटे तौर पर तीस से साठ characters। descriptive होने के लिए पर्याप्त लंबा, इतना छोटा कि Google का SERP snippet इसे truncate न करे और मनुष्य एक नज़र में विषय को समझ सकें। कोई कठोर तकनीकी अधिकतम नहीं है (RFC 3986 एक specify नहीं करता और modern browsers दसियों हज़ारों characters में URLs को संभालते हैं) लेकिन Apache, nginx और IIS kilobytes range में व्यावहारिक caps लगाते हैं, और Internet Explorer से legacy «2,000 character» नियम अभी भी एक सुरक्षित cross-platform ceiling के रूप में उद्धृत है। यहाँ Max Length विकल्प आपको output cap करने देता है; इसे 0 पर सेट करना असीमित का अर्थ है।

क्या मेरे texts कहीं संग्रहीत या भेजे जाते हैं?

नहीं। परिवर्तन पूरी तरह से आपके browser में JavaScript की built-in String.prototype.normalize() method का उपयोग करके चलता है (Chrome 34, Firefox 31, Safari 10, लगभग 2015 के बाद से supported)। कुछ भी upload नहीं होता, कोई API call नहीं की जाती, कोई logs नहीं लिखे जाते। आप slugs उत्पन्न करते समय अपने browser के DevTools Network tab खोलकर इसे verify कर सकते हैं, कोई outbound requests नहीं हैं। अप्रकाशित titles, internal documentation, draft posts या किसी अन्य content से प्राप्त slugs के लिए page सुरक्षित है जिसे आप अपने device को छोड़ना नहीं चाहते।

संबंधित टूल