URLスラッグジェネレーター

任意のテキストをURL対応スラッグに変換します。

オールブラウザ、テキストはデバイスを離れません


URLスラッグとは?

スラッグは、ページタイトルのURLバージョンです。これは、ページを読みやすい形式で識別するURLの部分です。例えば、example.com/blog/my-amazing-articleでは、スラッグは「my-amazing-article」です。

良いスラッグは、小文字、数字、ハイフンのみを使用します。アクセント、特殊文字、余分なスペースを削除します。これは、SEOとユーザー体験の両方を改善します · 検索エンジンと人間がURLを読んで、ページのコンテンツを理解できます。

言葉の起源、19 世紀の編集室

言葉は Web より 1 世紀前にあります。Linotype 時代のコンポジングルームで、各活字行は単一の金属帯、「slug」、約 30 パイカ幅でおおよそ 12 オンスの鉛、として鋳造されました。用語は後に編集者が記事の上に書く生産全体でラベル付けする短い識別子を意味するように変わりました、ジャーナリスト、コピーエディター、プリンターが完全なタイトルをタイプせずに記事を参照するために使用できる 1 〜 2 単語のハンドル(mayor-budget や school-fire のような)。AP と主要な日刊紙のスタイルガイドは依然としてこの使用を文書化しています。

Movable Type、WordPress、初期 Django ドキュメントが 2000 年代初頭に「slug」をフィールド名として採用したとき、彼らはニュースルームから用語をそのまま借りました。Django ドキュメントは少なくとも2005 年の 0.91 リリース以来 slug フィールドを呼び、現在の標準的な定義:文字、数字、アンダースコア、またはハイフンのみを含む短いラベル、通常 URL で使用される。鋳造鉛 slug と URL slug が両方とも、より長いものを指す短く、明確で、機械フレンドリーなトークンであるからこそ、メタファーは正確に当てはまります。

RFC 3986 と予約されていない文字セット

URL の構文は RFC 3986（「Uniform Resource Identifier (URI): Generic Syntax」）で定義されています。2005 年 1 月に Tim Berners-Lee、Roy Fielding、Larry Masinter によって公開され、RFC 2396 と 2732 を置き換えました。これは STD 66 のインターネット標準であり、IETF の最高成熟度ランクとして、安定性が実証され広く実装されたプロトコルだけに与えられます。RFC 3986 のセクション 2.3 は非予約文字を定義しています。これはパーセントエンコードなしで URI のどの構成要素でも安全であることが保証された唯一の文字群で、A-Z、a-z、0-9、ハイフン、ピリオド、アンダースコア、チルダから成ります。合計で六十六文字です。それ以外はすべて、予約文字（URI のいずれかの構成要素で構造的な意味を持つ）か「その他」のどちらかであり、後者のグループの文字が URI に現れる場合は必ずパーセントエンコードしなければなりません。

予約されていないセットがこれまで書かれたあらゆる URI パーサーを通じてクリーンにラウンドトリップすることが保証される唯一のものなので、slug 生成器はほぼ同一のパイプラインに収束します:アルファベット文字を小文字化、数字を保持、ハイフンを保持、空白を単一ハイフンに置き換え、他のすべてを削除または音訳します。アンダースコア、ドット、チルダは技術的に許可されますが、慣習的に slug では避けられます、ドットはファイル拡張子と衝突、チルダは古い URL 慣習でホームディレクトリとして読まれ、アンダースコアは後で扱う SEO 理由でハイフンに負けます。

「Cool URIs Don't Change」、Berners-Lee、1998

Tim Berners-Lee の1998 年のスタイルノート「Cool URIs Don't Change」、W3C サイトでホスト、はこれまで書かれた最も引用された slug 哲学です。冒頭の文は有名です:cool URI は変わらないものです。ノートは次に、パスに一時的な実装詳細を刻み込む URL 設計に対する論争として読まれます。推奨される禁止事項は近 30 年間 slug 慣行を形作りました:URL に著作ツール拡張子を入れない、それらは実装を明らかにし、移行するときに壊れる、URL にステータスを入れない、ページは「現在」から離れますが URL はそうすべきではありません、著者名を入れない、著者は去ります、リソースに日付が基本的でない限り日付を入れない、セッション ID、クエリパラメータ、ログイン状態を標準 URL に入れない。

slug、説明的な、意味的な、小文字-ハイフン-単語、はまさに「cool」URI で許可されるものです。他のすべてはアドレスに出血すべきではない構造的装飾です。WordPress の permalink 設計、Django の SlugField、Rails の to_param はすべてこのアドバイスを内部化します:ページがどう提供されるかのメカニクスではなく、ページの意味である URL を出力します。

ハイフンはアンダースコアに勝つ、それは文書化されています

2005 年の WebmasterWorld インタビューで、Google エンジニア Matt Cutts はハイフンが Google のトークナイザーによって単語区切り文字として扱われ、アンダースコアは単語結合子として扱われると述べました。したがって green-apples は 2 つのトークン green と apples として読まれ、green_apples は単一トークン green_apples として読まれます。クエリ 「green apples」 には、ハイフン付き URL がタイトルキーワードチェックに一致します、アンダースコア付き URL はそうしません。Cutts は2007 年に彼のブログで、2011 年の YouTube の Google Webmaster Help ビデオ(「Underscores vs. dashes in URLs」)でこれに戻り、同じアドバイスを再確認し、Google がアンダースコア動作を区切り文字としても機能するように変更することを評価したが、アンダースコアを意図的に結合子として使用する既存の URL を多すぎて壊すのでしなかったと指摘しました(__init__.py、プログラミング関数名)。

Google の現在の「URL structure best practices for Google Search」ページはハイフンを直接推奨します:/green-dress.html のような URL は /greendress.html より有用で、アンダースコアではなくハイフンを使用すべきです。推奨は 20 年以上にわたって継続的に文書化されています。効果は URL ごとに小さいですが何千ページのサイトで蓄積し、ハイフンをアンダースコアに変換することに利点はありません、アンダースコアが勝つ SEO シナリオは存在しません。あらゆる信頼できる slug ガイドは同じアドバイスで終わります:ハイフンを使用してください。

Unicode 正規化、NFD がアクセントを取り除く方法

Unicode 標準は多くのアクセント付き文字をエンコードする 2 つの方法を定義します:事前合成(単一コードポイント、é は U+00E9)と分解(基本文字に続いて結合マーク、é は U+0065 プラス U+0301、結合鋭アクセント)。視覚的に同一、バイトごとに異なる。Unicode Technical Standard #15 は 4 つの正規化形式 NFC、NFD、NFKC、NFKD を定義し、slug 生成のために、NFD はレバーです。入力文字列を取り、NFD に正規化し、それから Unicode 範囲 U+0300 から U+036F(Combining Diacritical Marks ブロック)のあらゆるコードポイントを削除すると、基本 ASCII 文字を取り戻します。Café は cafe に、naïve は naive に、François は Francois に、niño は nino に、crème brûlée は creme brulee になります。

NFD は基本+マークに分解できない文字を折り畳みません。ドイツ語 ß(シャープ s)は NFD の下で ss に分解しません、明示的な音訳が必要です。ポーランド語 ł(ストローク付き l)は l に分解しません。ノルウェー語 ø は o に分解しません。アイスランド語 þ(ソーン)と ð(エズ)はマッピングテーブルを必要とします。ブラウザは約 2015 年(Chrome 34、Firefox 31、Safari 10)から String.prototype.normalize() をネイティブにサポートしています、それが小さな JavaScript slugify ユーティリティでさえライブラリなしでダイアクリティック削除作業を行える理由です。

slugify ライブラリファミリー、各エコシステムが出荷するもの

Django の django.utils.text.slugify() は2000 年代初頭から Python フレームワークにあります。それは小文字化、[A-Za-z0-9_-] から欠けている文字を削除、空白をハイフンで置き換えます。Django 1.9(2015)以降、allow_unicode=True キーワードは非 ASCII 文字を保持する Unicode 認識モードに切り替えます。これは皆がコピーするリファレンス実装です。Node.js では、Sindre Sorhus の @sindresorhus/slugify は npm で最もダウンロードされた slugify パッケージで、週に数百万のダウンロード、機能には人間が読める区切り文字、カスタマイズ可能な置換(& を and に、@ を at にマップできる)、Unicode 処理、ロケール認識小文字化(トルコ語のドット付き/なし I、ドイツ語 ß → ss)が含まれます。Django を使用しない Python ユーザーには、PyPI の Val Neekman の python-slugify が unidecode 音訳ライブラリをラップし、slug 固有の動作を追加:regex 単語分割、置換文字、最大長、ストップワード削除。

他のエコシステムは同じパターンに従います。PHP には Packagist で Cocur の cocur/slugify があり、Laravel と Symfony プラグインで使用、Symfony 自体はバージョン 5.0 以降 symfony/string で AsciiSlugger を出荷します。Ruby on Rails は String#parameterize を使用、少なくとも Rails 1.0 以来 ActiveSupport に組み込まれています、friendly_id gem は履歴追跡と衝突処理をレイヤー化します。Go は 80 以上の言語のロケールテーブルを持つ gosimple/slug を持っています。Rust は slug クレートを持っています。Java は Apache Commons Text と slugify-jvm を持っています。注目すべきことは API がどれだけ収束しているかです:文字列イン、slug アウト、同じいくつかのオプション、区切り文字、最大長、小文字化、ロケール。Absolutool のツールは同じファミリーに登録しますが、ブラウザで完全に実行され、インストールするライブラリはありません。

WordPress、Web の 43% がこのパイプラインを実行

WordPress は Web 上で最大の slug 発行システムです、2026 年 W3Techs 調査によるとすべての Web サイトの約 43% を動かしているので、その slug 慣習はほとんどの読者にとって事実上 Web の slug 慣習です。投稿が保存されると、WordPress は sanitize_title() 経由でタイトルから自動的に slug を生成します(デフォルト書き換えケースのために sanitize_title_with_dashes() を呼び出す):小文字化、HTML を削除、エンティティをデコード、空白とほとんどの句読点をハイフンで置き換え、安全でない文字をパーセントエンコード、隣接ハイフンをマージ、先頭/末尾ハイフンを削除。結果が既存の投稿の slug と衝突する場合、WordPress は -2、-3 などを追加します。slug は投稿エディタで編集可能、投稿が公開されると、エディタがリダイレクトを設定しない限り、slug を変更すると既存のあらゆるリンクが壊れます。WordPress は歴史的にデフォルトで非 ASCII 文字を音訳しませんでした、それらをパーセントエンコードしました、それは Cyr-To-Lat のようなプラグインが書かれて修正される有名に醜いキリル文字 URL %D0%BF%D1%80%D0%B8... を生成しました。

ラテン語を超えて、キリル文字、CJK、アラビア語の音訳

NFD は基本 ASCII + 結合マークに分解する文字のみを処理します。非ラテン文字には、slug パイプラインは音訳が必要です、各非ラテン文字をそのラテン文字等価物にマッピング。標準的な Python ライブラリは unidecode、元々 Sean M. Burke の2001 年 Perl Text::Unidecode のポート、Basic Multilingual Plane の本質的にあらゆる文字を「最良推測」ASCII 文字列にマップします:Москва → Moskva、Αθήνα → Athena。CJK フォールバックは論争の的の部分です:unidecode はすべての CJK 文字に北京語 pinyin を使用します、中国語が最大の CJK 文字カバレッジを持つから、それは日本語にナンセンスなローマ字化を生成します(東京 → pinyin で Dong Jing、Tokyo ではない)。pykakasi のような日本固有のツールは漢字 + かなをクリーンなローマ字に変換する作業を行います。International Components for Unicode(ICU)ライブラリ、Unicode Consortium と IBM によってメンテナンス、は Russian-Latin/BGN、Greek-Latin/UNGEGN、Han-Latin のような名前付きルールセットを持つ Transliterator API を提供、公式ローマ字化標準を実装します。Absolutool のツールは軽量端に立ちます:NFD でラテンダイアクリティックを折り畳み、他のすべてを破棄します。ロシア語または中国語のタイトル slug を望むユーザーはテキストを貼り付ける前に別個の音訳ステップを実行できます。

URL 長制限、2000 文字ルールの出所

RFC 3986 自体によって長さ制限は指定されません、URI 構文は無制限です。あらゆる制限は実用的です。Internet Explorer は歴史的に URL を 2,083 文字(Trident エンジンに組み込まれたハード制限)に制限しました、それが広く引用される「2,000 文字」経験則の起源です。Chrome、Firefox、Safari、現代の Edge はアドレスバーで約 64,000 〜 100,000+ 文字までの URL をサポートします。Apache の LimitRequestLine はリクエスト全体行に対してデフォルト 8,190 バイト、nginx の large_client_header_buffers はデフォルト 8 KB、IIS は URL に対してデフォルト 16,384 バイト、クエリ文字列に対して 4,096 バイトです。RFC 9110(HTTP/1.1、2022)は §4.1 でサーバーが「8,000 オクテット以上の長さの URI を処理できるべきである」ことを推奨しますが、上限を強制するほど遠くは行きません。slug にとって重要なのはそれらが慣習的に短い、3 〜 7 単語、30 〜 60 文字、SEO と共有可能性のためです。Google の John Mueller は複数の Webmaster Hangouts で URL 長自体はランキングシグナルではないと述べましたが、長い URL は検索結果スニペットで切り捨てられる可能性があり、クリック率を傷つけ、ソーシャル共有で非専門的に見える可能性があります。ほとんどの slug 生成器はこの理由で最大長オプションを公開します、これはデフォルトで無制限で、上限を設定させます。

ストップワード削除、密集 vs 文法的

多くの slugify ライブラリはオプションのストップワード削除を提供します、slug を組み立てる前に短い一般的な単語(a、an、the、of、is、and、or、to、in、for、on)を削除します。理論的根拠はそれらが SEO シグナルを追加せず URL を膨らませることです。したがって 「The Best Way to Make a Cup of Tea」 は the-best-way-to-make-a-cup-of-tea(10 トークン、35 文字)の代わりに best-way-make-cup-tea(5 トークン、24 文字)になります。トレードオフ:より短くより密集だが、たまの文法崩壊(how-to-be-good が how-good に削減されると意味を失う)と意図を実際に運ぶ単語を削除するリスク(art-of-war が art-war に削減)。WordPress はデフォルトでストップワードを削除しません、それはオプトインプラグイン動作です、ほとんどの現代の slug 生成器はデフォルトでオフにし、チェックボックスとして提供します。WordPress 用 Yoast SEO はストップワードを含む slug をエラーではなくマイナーな推奨としてフラグします。この生成器は自動的にストップワードを削除しません、エディタが静的単語リストよりタイトルの意図をよく知っているという理由で。それらが消えるのを見たいなら、出力を直接編集してください。

Slug 衝突、2 つの投稿がタイトルを共有するときに CMS が行うこと

2 つの投稿が同じ slug を自動生成するとき、「My Post」と「My-Post!」は両方とも my-post を生成します、システムは衝突を解決しなければなりません。最も一般的な戦略:数値サフィックス(my-post-2、my-post-3)、予測可能、決して衝突しないが、サフィックスは意味的差異を運ばない、日付プレフィックス(2026-04-27/my-post)、ブログコンテンツに対してうまく機能、Jekyll、Hugo、ほとんどのニュースサイトでデフォルト、著者サフィックス(my-post-jane)、Medium と複数著者ブログで使用、ランダムハッシュサフィックス(my-post-a3f9)、Stack Overflow、Notion、ショートリンクシステムで使用、人間の読みやすさを保証された一意性と交換、または公開時の手動編集、編集的にクリーンだがフローを中断するのでデフォルトとしてはまれ。ほとんどの CMS の実用的な選択は、エスケープハッチとしての手動編集を持つ数値サフィックスです。日付プレフィックス permalink は日付が意味のある情報である時間アンカーコンテンツに人気です。

SEO 影響、マイナーだが見える信号としての slug

Google のランキングドキュメントは URL 構造をマイナーランキングシグナルとしてリストします、ページコンテンツ、バックリンク、ユーザーエンゲージメントシグナル、新鮮さがすべてより多くの重みを持ちます。しかし URL 単語は寄与し、それらは目に見えて寄与します。slug 用語はタイトルの下の SERP スニペット URL ラインに現れ、slug 自体がランキングされていなくてもクリック率に影響します。slug 用語はユーザーのクエリと一致する場合、SERP で太字で現れる可能性があります、追加の視覚的重み。内部および外部リンクのアンカーテキストは、リンクテキストが提供されないとき、しばしば URL にデフォルトします、つまり意味的 slug がリンクテキストになり、入ってくるリンクエクイティを通じてキーワードを運びます。パブリッシャーでの A/B テストは、説明的 slug が不透明な ID と比較して CTR を 1 桁のパーセントで増加させることを一貫して示します。Backlinko の2020 年ランキング要因研究(118 万 SERP を分析)は、短い URL が SERP の上位で長いものをわずかに上回ることを発見しました。

「より多くのキーワード = より良い」直感には例外があります:キーワードスタッフィング。2012 年 9 月の Exact-Match Domain(EMD)アップデートは特に低品質の正確一致ドメインと slug(cheap-life-insurance.com/buy-cheap-life-insurance)に対するクレジットを減らし、Google はそれ以来 URL でのキーワードスタッフィングを下げ続けています。2026 年の見解:slug でのキーワード存在は控えめに役立つ、キーワードスタッフィングは害をもたらす。slug からの最大の SEO 利益は公開後にそれを変更しないことです。入ってくるリンクは URL に蓄積します。ページ権限は URL レベルで複合します。301 リダイレクトはほとんどのリンクエクイティを保持しますが、すべてではありません、そしてエディタが実際にリダイレクトを設定する場合のみ、多くはしません。Berners-Lee の「Cool URIs Don't Change」アドバイスは直接的な SEO 結果を持ちます:すべての slug 変更は、リダイレクトがあっても、回復するのに時間がかかる権限の少量のコストがかかります。

スラッグのSEOベストプラクティス

よくある質問

アクセント付き文字をサポートしていますか?

はい。ジェネレーターはアクセントを削除するためにUnicode正規化(NFD)を使用します。例えば、「cafe」は「cafe」のままですが、「café」も「cafe」になります。これにより、純粋なASCIIのクリーンなスラッグが保証されます。

ハイフンとアンダースコアのどちらを使うべきですか?

SEOにはハイフンが推奨されます。Googleの公式ドキュメントは、URLのハイフンが単語区切り記号として扱われるが、アンダースコアはそうでないことを確認しています。したがって、「my-article」は2つの単語として読まれますが、「my_article」は1つだけを形成します。

絵文字とシンボルはどうなりますか?

絵文字は URL の予約されていない文字セットになく、NFD はそれらを分解しません、それらはラテン語等価物を持ちません。この生成器はそれらを削除します。他のツールは絵文字をパーセントエンコードします(単一文字を %F0%9F%94%A5 のような長い文字列に変える)、技術的に現代のブラウザで動作しますが、分析、ソーシャル共有、メールプレビューで読めない URL を生成します。ほとんどの slug ガイドは絵文字を完全に削除することを推奨します、それらを保持したい場合は、slug ステップの上流でパーセントエンコードしてください。

ロシア語、中国語、アラビア語のタイトルを slug 化しますか?

それ単独ではしません。NFD はラテン文字でアクセント付き文字のみを折り畳みます、キリル文字、ギリシャ文字、アラビア文字、ヘブライ文字、CJK スクリプトをラテン語に音訳できません。このツールにロシア語または中国語のタイトルを貼り付けるとそれらの文字を削除し、空または近空 slug を生成します。正しいワークフローは最初に音訳ステップを実行することです、Python の unidecode、JavaScript の npm パッケージ transliteration、または Wikipedia のローマ字化慣習、そしてローマ字化された結果をここに貼り付けます。日本語に特に、pykakasi のような kana 認識ツールを使用してください、汎用 CJK トランスリテレータは北京語 pinyin を適用し、東京 に Tokyo ではなく Dong Jing を生成します。

公開後に slug を変更する必要がある場合は?

slug を変更する前に古い URL から新しい URL への 301 リダイレクトを設定してください。301(「Moved Permanently」)は古い URL に蓄積されたほとんどのリンクエクイティを保持し、クローラーとブラウザにブックマークを更新するように伝えます。リダイレクトなしでは、既存の入ってくるリンクは壊れ、それらのリンクが表したページ権限を失います。リダイレクトがあっても、回復するのに数週間または数か月かかる少量のエクイティを失います。Berners-Lee の格言、cool URI は変わらない、は部分的に美的、部分的に SEO 真実です:すべての slug 変更は何かをコストします、最初に slug を正しく取得することは価値があります。

推奨される slug 長はありますか?

慣習は 3 〜 7 単語、約 30 〜 60 文字です。説明的に十分長く、Google の SERP スニペットがそれを切り捨てず人間が一目で件名を把握できるほど短い。ハードな技術的最大値はありません、RFC 3986 はそれを指定せず現代のブラウザは数万文字の URL を処理しますが、Apache、nginx、IIS はキロバイト範囲の実用的な上限を強制します、Internet Explorer の継承された「2,000 文字」ルールは依然として安全なクロスプラットフォーム上限として引用されます。ここの最大長オプションは出力に上限を設定させます、それを 0 に設定すると無制限を意味します。

私のテキストは保存またはどこかに送信されますか?

いいえ。変換は JavaScript の組み込み String.prototype.normalize() メソッド(Chrome 34、Firefox 31、Safari 10 以降サポート、約 2015 年)を使用して完全にブラウザで実行されます。何もアップロードされず、API は呼ばれず、ログは書かれません。slug を生成する間にブラウザの DevTools の Network タブを開いて確認できます、発信リクエストはありません。ページは未公開のタイトル、内部ドキュメント、ドラフト投稿、またはデバイスを離れたくないあらゆる他のコンテンツから派生した slug に安全です。

関連ツール

URLエンコーダー/デコーダー

URLとURIコンポーネントをエンコードまたはデコードします。

ケースコンバーター

テキストを異なるケース間で変換します。

ワードカウンター

単語、文字、読了時間をカウントします。