Tip/Trick：URL書き換え拡張の使用による一般的なSEO問題の修正

連載：～ScottGu氏のブログより～

Tip/Trick：URL書き換え拡張の使用による一般的なSEO問題の修正

Scott Guthrie 著／Chica 訳
2010/04/30

　本記事は、Microsoftの本社副社長であり、ASP.NETやSilverlightなどの開発チームを率いるScott Guthrie氏のブログを翻訳したものです。氏の許可を得て転載しています。

【元記事】 Tip/Trick: Fix Common SEO Problems Using the URL Rewrite Extension
（2010/04/20）

　検索エンジン最適化（SEO）は、すべての公開Webサイトにとって重要です。サイトへのトラフィックの大きな割合が検索エンジンから直接来ており、サイトの検索関連性を改善すれば、検索エンジンのクエリからより多くのユーザーが訪れるように導けます。これは直接的または間接的に、サイトを通じた収益を増加できます。

　このブログ投稿では、無償のMicrosoftURL書き換え拡張（URL Rewrite Extension）を使って、サイトに存在する可能性のある多くの一般的なSEO問題を修正できます。15分以下（そしてコードの変更なし）で4つのシンプルなURLの書き換えルールをサイトへ適用でき、そうすることで検索エンジンからサイトへ、より多くの訪問者とトラフィックを導くことができます。以下のテクニックはASP.NET WebフォームおよびASP.NET MVCのどちらがベースでも、うまく同じように機能します。それらはどのASP.NETバージョンでも動作します（そしてASP.NETのコンテンツ以外にも作用します）。

[ブログに加え、現在Twitterを使って簡単な更新やリンク共有を行っています。twitter.com/scottguで、わたしをフォローしてください。]

Microsoft SEOツールキットでサイトのSEOを測定

　数カ月前、出荷済みの無償のSEOツールキットについてブログ投稿しました。これは便利なツールで、サイトのSEOを修正するために自動的にクロール／スキャンし、SEOの問題が見つかるとフラグを立てます。ツールをダウンロードして、扱っているすべてのパブリックなサイトに対して使用することを強く推奨します。それにより、サイトに存在する可能性のあるSEO問題が見つかり、さらにそれを最適化する方法を簡単に確認できます。

　以下は、このブログ投稿でカバーしているURL書き換えルールを適用する前の、わたしのあるサイトに対して行ったレポートの単純な例です（www.scottgu.com）

図1

検索関連性とURLの分離

　検索エンジンがサイトの“検索関連性”を評価する際の、2つの重要な点は以下のとおりです。

1. コンテンツにほかのサイトがいくつリンクしているか。検索エンジンは、Web上で多くの人がそのコンテンツへリンクしているとしたら、それは有益である可能性が高いと推測し、関連性を高く評価します。

2. サイト上のコンテンツのユニークさ。もし検索エンジンがそのコンテンツはインターネット上で（または、あなたのサイト上の複数のURL上で）複数の場所にコピーされているとしたら、それはコンテンツの関連性を落とす可能性が高くなります。

　公開サイトを構築する際に非常に気を付けて避けたいものの1つが、サイト内で同じコンテンツを取得する、異なるURLを許可しないことです。そうしてしまうと、上記の両方のケースで悪い影響を及ぼします。

　特に、複数のURLによる同一コンテンツへの外部サイトからのリンクを許可すると、それらの異なるURLに、リンク・カウントやページ・ランキングを分割することになります（そして1つのURLだけで得られるよりも小さいページ・ランクになります）。さまざまな方法での外部サイトからのリンクを許可しないというのは、理論的には簡単に聞こえますが、実際これをどのように実践し、どのようにそれを避ければよいのか疑問に思うでしょう。

サイトが抱える4つの非常に共通するSEO問題

　以下は、同じコンテンツに対して複数のURLを不注意に公開したことが引き起こす4つの非常によくあるシナリオです。これが起こると、リンクしている外部サイトは複数のURLに分割してページをリンクすることになり、結果検索エンジンでは本来より低いページ・ランキングになります。

SEO問題No.1：デフォルトのドキュメント

　IIS（およびそのほかのWebサービス）は”デフォルト・ドキュメント”の概念をサポートしています。これにより、Webサイト／アプリケーションのルートまたはサブディレクトリ内において、どのページを提供するかについて明示的に特定しなくてもよくなります。これは便利ですが、デフォルトでこのコンテンツは、2つの異なる公開URLを通じて利用可能になることを意味します（これは好ましくありません）。以下に例を示します。

　http://scottgu.com/

　http://scottgu.com/default.aspx

SEO問題No.2：URLの大文字・小文字の区別

　Web開発者は、Web上でURLが検索エンジンに対して大文字小文字の区別がされていることに気付いていない場合がよくあります。つまり検索エンジンは、以下のリンクを2つの完全に別のURLとして扱います。

　http://scottgu.com/Albums.aspx

　http://scottgu.com/albums.aspx

SEO問題No.3：スラッシュの後付け

　以下の2つのURLを考えてください。それらは一見すると同じに見えますが微妙に違います。最後のスラッシュがまた別のシチュエーションを作り出し、検索エンジンがそれらのURLを異なるものとして扱うため、検索のランキングを分けてしまいます。

　http://scottgu.com

　http://scottgu.com/

SEO問題No.4：基準のホスト名

　ときどき、サイトの先頭に“www”が付いたホスト名である場合と、ホスト名だけの場合の両方をWebサイトがサポートしていることがあります。これにより、検索エンジンはURLを異なるものとして扱うため、検索のランキングを分けてしまいます。

　http://scottgu.com/albums.aspx/

　http://www.scottgu.com/albums.aspx/

IIS書き換えを使用して10分間（以内）で簡単にこれらのSEO問題を修正する方法

　サイトのコーディングで気を付けないと、上記のSEO問題の1つ（またはそれ以上）に影響を受けている可能性があります。これらの問題点を修正すると、検索エンジンの関連性ランキングを改善し、サイトへより多くのトラフィックを導けます。

　“よいニュース”は、上記の4つの問題をURL書き換え拡張（URL Rewrite Extension）を使って非常に簡単に修正できることです。これは、（Windows Server 2008、Windows Server 2008 R2、Windows 7、Windows Vista上の）IIS 7.xに対する完全に無償のMicrosoftの拡張です。IIS書き換え拡張を使うことの素晴らしさは、アプリケーションのコードを変更すること*なく*問題を修正できる点です。

　Microsoft Web Platform Installerを使えば、3分以下で簡単にURL書き換え拡張をインストールできます（Webサーバと開発マシンに自動でセットアップを可能にするために出荷した無償ツールです）。URL Rewrite Spotlightページ上の緑色の“Install Now”ボタンをクリックするだけで、Windows Server 2008、Windows 7、Windows Vistaマシン上にインストールできます。

図2

　インストールが完了すると、IIS 7アドミン・ツール内にある新しい“URL書き換え”アイコンが確認できます。

図3

　アイコンをダブルクリックすると、URL書き換えの管理者パネルが開き、特定のアプリケーションまたはサイトに対して構成されたURL書き換えルールの一覧が表示されます。

図4

　上記の書き換えルール一覧が現在は空であることをご確認ください（これは最初に拡張をインストールしたときのデフォルトです）。パネルの右上にある“Add Rule...”リンクボタンをクリックすると、新しいURL書き換えロジックをサイトに対して追加し有効化できます。

シナリオ1：デフォルト・ドキュメントのシナリオの処理

　この投稿の最初で話したSEO問題の1つがIISの“デフォルト・ドキュメント”機能により、2つのURLをサイト上の同じコンテンツに対して不注意に公開するというシナリオです。以下に例を示します。

http://scottgu.com/

http://scottgu.com/default.aspx

　1つ目ではなく2つ目のURLへ導かれるすべての人を自動的にリダイレクトする新しいIIS書き換えルールを追加することで、これを修正できます。 “パーマネント・リダイレクト”になるようにHTTPリダイレクトを設定し、検索エンジンに対して、そのリダイレクトに従ってリダイレクトされた新しいURLを、取得するコンテンツのIDとして使用するように示します。

　そのようなルールをどのように作るのか見てみましょう。上記のスクリーンショットにある“Add Rule”リンクをクリックすることから始めます。これにより以下のダイアログが表示されます。

図5

　“Inbound rules”セクションにある“Blank Rule”を選択して、新しい独自のURL書き換えルールを作成します。これにより以下のような空のペインが表示されます。

図6

　上記のルールは簡単に設定できるので、ご心配なく。以下の4つのステップで、その方法を説明します。

ステップ 1：ルールに名前を付ける

　最初のステップは、作成するルールに名前を付けます。説明的な名前を付けることで、後で簡単に検索および把握できます。このルールには、“Default Document URL Rewrite”ルールと名前を付けましょう。

図7

ステップ 2：このルールにマッチする正規表現を設定する

　2つ目のステップは、正規表現パターンにマッチしたURLが入ってきたとき、このルールが実行されるように正規表現フィルタを指定します。正規表現が得意でなくても心配しないでください。わたしも苦手です。秘けつは得意な人を知っていることと、Webサイトからそれらをコピー／ペーストすることです。

　以降では、パターン・ルールとして次の正規表現を指定していきます。

　(.*?)/?Default\.aspx$

　このパターンは、Default.aspxで終わるURL文字列すべてとマッチします。“(.*?)”はすべての直前の文字がゼロ回以上マッチするものです。“/?”部分は、スラッシュ・シンボルとゼロ回以上マッチするものを指します。最後の“$”シンボルは、確実にそのパターンがDefault.aspxで終わる文字列だけにマッチするようにしています。

　これらすべての正規表現要素を合わせると、Webサイトのルートだけではなく（例：http://scottgu.com/default.aspx）、サイト内のすべてのアプリケーションやサブディレクトリにも（例：http://scottgu.com/photos/default.aspx）、このルールが適用できます。“ignore case”のチェック・ボックスが選択されていると、URL内の“Default.aspx”および“default.aspx”の両方にマッチします。

図8

　ルール・エディタにビルトインされた素晴らしい機能が“Test pattern”ボタンで、これをクリックするとダイアログが立ち上がり、いくつかのURLで構成中のルールをテストできます。

図9

　上記では“products/default.aspx”というURLを追加して“Test”ボタンをクリックしました。これにより、そのルールが実行されるかどうかのフィードバックをすぐ得られます。

ステップ 3：パーマネント・リダイレクト・アクションの設定

　その後、正規表現パターンと、入ってくるURLがマッチしたときに発生するアクションを設定します。

図10

　上記のダイアログでは、“Action Type”ドロップダウンを“Redirect”アクションに変更しました。“Redirect Type”はHTTP 301のパーマネント・リダイレクトになり、検索エンジンはそれを追います。

　また、以下のように“Redirect URL”プロパティを設定しました。

{R:1}/

　これは、元のURLをリクエストしてきたWebクライアントを、もともとリクエストされたURLパス－（マイナス）“Default.aspx”の、新しいURLへリダイレクトさせたいことを示しています。例えば、http://scottgu.com/default.aspxをリクエストすると、http://scottgu.com/へリダイレクトされ、http://scottgu.com/photos/default.aspxをリクエストすると、http://scottgu.com/photos/へリダイレクトされます。

　N >= 0の場合の“{R:N}”という正規表現の組み立ては、正規表現の後方参照と呼ばれ、Nは後方参照のインデックスです。この“(.*?)/?Default\.aspx$”のパターンのケースでは、もし入力URLが“products/Default.aspx”の場合、{R:0}には“products/Default.aspx”が含まれ、{R:1}には“products”が含まれます。ユーザーをリダイレクトするURLになるよう、この{R:1}/の値を使用します。

ステップ 4：ルールの適用と保存

　最後のステップとして、IISアドミン・ツールの右上にある“Apply”ボタンをクリックします。これによりツールがアプリケーションのルートにあるweb.configファイルにそのURL書き換えルールを保存します（<system.webServer/rewrite>構成セクションの下）:

<configuration>

  <system.webServer>

    <rewrite>

      <rules>

        <rule name="Default Document" stopProcessing="true">

          <match url="(.*?)/?Default\.aspx$" />

          <action type="Redirect" url="{R:1}/" />

        </rule>

      </rules>

    </rewrite>

  </system.webServer>

</configuration>

　IIS 7.xとASP.NETは同じ web.configファイルを共有しているので、実際は上記のコードをVisual Studioを使ってweb.configファイルにコピー／ペーストすれば、そのアドミン・ツールの起動部分をすべてスキップできます。またこれにより、ASP.NETアプリケーションへのURL書き換えルールの追加／配置が非常に簡単になります。

ステップ 5：ルールのテスト

　ルールが保存できたので、サイトで試してみましょう。わたしのサイト上で以下の2つのURLを試してみます。

　http://scottgu.com/

　http://scottgu.com/default.aspx

　2つ目のURLは自動的に1つ目にリダイレクトされることがお分かりいただけます。これはパーマネント・リダイレクトなため、検索エンジンはそのURLを追っていくので、http://scottgu.comのページ・ランキングをhttp://scottgu.com/default.aspxへのリンクも含めて更新します。

シナリオ2：URLの大文字小文字の区別

　この投稿の最初に話したもう1つのよくあるSEO問題は、Web上で検索エンジンに対してURLが大文字小文字の区別をされている場合です。つまり、検索エンジンは以下のリンクを2つのまったく異なるURLとして扱います。

　http://scottgu.com/Albums.aspx

　http://scottgu.com/albums.aspx

　これは、2つ目（すべて小文字）のものではなく、1つ目のURLへ導かれた人をすべて自動的にリダイレクトするという新しいIISの書き換えルールを追加すれば、修正できます。前のように、HTTPリダイレクトを“パーマネント・リダイレクト”に設定します。これは検索エンジンにそのリダイレクトを追ってリダイレクトされた新しいURLを、取得するコンテンツのIDとして使用するように示しています。

　そのようなルールを作成するために、URL書き換えアドミン・ツールの“Add Rule”リンクを再度クリックします。これにより“Add Rule”ダイアログが再度表示されます。

図11

　以前のシナリオ（“Blank Rule”を作成したとき）と違い、このシナリオでは、ビルトインの“Enforce lowercase URLs”ルール・テンプレートが使用できます。“OK”ボタンをクリックすると、以下のようなダイアログが表示され、URLの小文字の使用を強制するルールを作成するかどうか聞かれます。

図12

　“Yes”ボタンをクリックすると、入ってきたURLに大文字が含まれていた場合、自動的にそのURLの小文字バージョンへユーザーを遷移させるというパーマネント・リダイレクトを自動的に実行する、事前定義のルールを得られます。

図13

　“Apply”ボタンをクリックすれば、このルールを“そのまま”使用でき、サイトに入ってきたすべてのURLに適用できます。

　わたしのwww.scottgu.comサイトは、ASP.NET Webフォームを使用しているので、上記で生成されたルールを少し変更して、大文字小文字区別のURL書き換えロジックから、ASP.NETにビルトインされている“WebResource.axd”ハンドラを除外するように条件を追加しました。WebResource.axdへのURLには、ページで発行されてサーバ・コントロールから来るだけで、外部サイトから決してリンクされることはありません。わたしのサイトでは、これらのURLを自動的に小文字にしても問題なく継続して機能しますが、それは不必要なことであり、余分なHTTPリダイレクトを多くのページに追加することになります。

　幸いにも、特定のURLで発生するURL書き換えルールを回避するような条件を1つ追加するのは簡単です。単に、上記から“Conditions”セクションを開くだけです。

図14

　そして“Add”ボタンをクリックして条件節を追加できます。これにより“Add Condition”ダイアログが表示されます。

図15

　上記では、その条件として{URL}を入力しました。これは、“WebResource.axd”という文字列を含む正規表現パターンにURLがマッチしない場合にのみ、このルールが実行されることを示しています。これで確実に、わたしのサイトへのWebResource.axdのURLは、すべてが小文字になるように書き換えられることなく、うまく実行されます。

注意：もし現在、大文字を使用している静的なリソース（例えば.jpg、.css、.jsファイルへの参照）がサイト内にあるなら、恐らく、さらに条件フィルタ節を追加して、それらのURLも小文字へリダイレクトしなくてもいいようにしたいかもしれません（.jpg、.gif、.jsなどのパターンにルールを追加するだけです）。もしこれらのURLが小文字にリダイレクトされても、サイトは継続して問題なく動作します（つまりサイトは壊れません）。しかし、SEOの理由のために必要なリダイレクトではない余分なHTTPリダイレクトがサイト上で発生します。ですので、条件節を追加設定することは理にかなっています。

　上記で“OK”ボタンをクリックして小文字の書き換えルールを適用すると、アドミン・ツールは以下の追加ルールをweb.configファイルに保存します。

<configuration>

 <system.webServer>

  <rewrite>

   <rules>



    <rule name="Default Document" stopProcessing="true">

     <match url="(.*?)/?Default\.aspx$" />

     <action type="Redirect" url="{R:1}/" />

    </rule>



    <rule name="Lower Case URLs" stopProcessing="true">

     <match url="[A-Z]" ignoreCase="false" />

     <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

      <add input="{URL}" pattern="WebResource.axd" negate="true" />

     </conditions>

     <action type="Redirect" url="{ToLower:{URL}}" />

    </rule>



   </rules>

  </rewrite>

 </system.webServer>

</configuration>

ルールのテスト

　ルールが保存できたので、サイト上で試してみましょう。わたしのサイト上で以下の2つのURLを試しましょう。

　http://scottgu.com/Albums.aspx

　http://scottgu.com/albums.aspx

　最初のURL（大文字の“A”がある）が、自動的に小文字バージョンのURLへ確かにリダイレクトされたことをご確認ください。

シナリオ3：スラッシュの後付け

　この投稿の最初で話したもう1つのよくあるSEO問題は、URLの最後にスラッシュがあるシナリオです。このスラッシュの後付けは、検索エンジンがURLを別のものとして取り扱い、検索ランキングを分別することになるシチュエーションをまた別に作り出します。

　http://scottgu.com

　http://scottgu.com/

　これは、2つ目に行かず1つ目のURL（スラッシュが付いていない）へ導かれた人を、すべて自動的にリダイレクトするという新しいIISの書き換えルールを追加すれば修正できます。前のように、HTTPリダイレクトを“パーマネント・リダイレクト”に設定します。これは検索エンジンに、そのリダイレクトを追ってリダイレクトされた新しいURLを、取得するコンテンツのIDとして使用するように示しています。

図16

　URL書き換えアドミン・ツールにはビルトインの“Append or remove the trailing slash symbol”ルール・テンプレートがあります。

　それを選択して“OK”ボタンをクリックすると、以下のようなダイアログが表示され、スラッシュの付いていないURLだった場合、付いているURLへ自動的にユーザーをリダイレクトするようなルールを作成するかどうか尋ねられます。

図17

　“OK”ボタンをクリックすると、そのURLにスラッシュが付いていなくて、ディレクトリやファイルがそのURLを処理していない場合に、自動的にパーマネント・リダイレクトを実行するという事前定義のルールが得られます。

　以前の小文字の書き換えルールのように、このルールからWebResource.axd URLの処理が省かれるように、追加条件節を1つ加えます。これにより不必要なリダイレクトが、これらのURLに対して発生しないようになります。

　これによりweb.configファイルへ以下の追加ルールが保存されます。

<configuration>

 <system.webServer>

  <rewrite>

   <rules>



    <rule name="Default Document" stopProcessing="true">

     <match url="(.*?)/?Default\.aspx$" />

     <action type="Redirect" url="{R:1}/" />

    </rule>



    <rule name="Lower Case URLs" stopProcessing="true">

     <match url="[A-Z]" ignoreCase="false" />

     <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

      <add input="{URL}" pattern="WebResource.axd" negate="true" />

     </conditions>

     <action type="Redirect" url="{ToLower:{URL}}" />

    </rule>



    <rule name="Trailing Slash" stopProcessing="true">

     <match url="(.*[^/])$" />

     <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

      <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />

      <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />

      <add input="{URL}" pattern="WebResource.axd" negate="true" />

     </conditions>

     <action type="Redirect" url="{R:1}/" />

    </rule>



   </rules>

  </rewrite>

 </system.webServer>

</configuration>

ルールのテスト

　ルールが保存できたので、サイト上で試してみましょう。わたしのサイト上で以下の2つのURLを試しましょう。

　http://scottgu.com

　http://scottgu.com/

　最初の（スラッシュの付いていない）URLは、自動的にスラッシュのあるURLへ確かにリダイレクトされたことをご確認ください。これはパーマネント・リダイレクトなため、検索エンジンはそのURLを追っていき、ページ・ランキングを更新します。

シナリオ4：基準のホスト名

　最初に話したシナリオでの最後のSEO問題は、“www”が先頭に付いたホスト名でも、あるいはホスト名だけでもサイトが機能する場合です。これにより、検索エンジンはURLを異なるものとして扱うため、検索のランキングを分けてしまいます。

　http://www.scottgu.com/albums.aspx

　http://scottgu.com/albums.aspx

　これは、2つ目に行かず1つ目のURL（wwwのある）へ導かれた人をすべて、自動的にリダイレクトするという新しいIISの書き換えルールを追加すれば修正できます。前のように、HTTPリダイレクトを“パーマネント・リダイレクト”に設定します。これは検索エンジンにそのリダイレクトを追って、リダイレクトされたその新しいURLを、取得するコンテンツのIDとして使用するように示しています。

図18

　URL書き換えアドミン・ツールには、ビルトインの“Canonical domain name”ルール・テンプレートがあります。

　それを選択して“OK”ボタンをクリックすると、以下のようなダイアログが表示され、自動的にユーザーをプライマリのホスト名のURLへリダイレクトするルールを作成するかどうか尋ねられます。

図19

　上記では、プライマリのURLアドレスをscottgu.comで公開したいということを入力しました。“OK”ボタンをクリックすると、もしURLに別のドメイン名が先頭に付いていたら自動的にパーマネント・リダイレクトを実行するという事前定義のルールが得られます。

　これにより次の追加ルールがweb.configに保存されます。

<configuration>

 <system.webServer>

  <rewrite>

   <rules>



    <rule name="Cannonical Hostname">

     <match url="(.*)" />

     <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

      <add input="{HTTP_HOST}" pattern="^scottgu\.com$" negate="true" />

     </conditions>

     <action type="Redirect" url="http://scottgu.com/{R:1}" />

    </rule>



    <rule name="Default Document" stopProcessing="true">

     <match url="(.*?)/?Default\.aspx$" />

     <action type="Redirect" url="{R:1}/" />

    </rule>



    <rule name="Lower Case URLs" stopProcessing="true">

     <match url="[A-Z]" ignoreCase="false" />

     <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

      <add input="{URL}" pattern="WebResource.axd" negate="true" />

     </conditions>

     <action type="Redirect" url="{ToLower:{URL}}" />

    </rule>



    <rule name="Trailing Slash" stopProcessing="true">

     <match url="(.*[^/])$" />

     <conditions logicalGrouping="MatchAll" trackAllCaptures="false">

      <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />

      <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />

      <add input="{URL}" pattern="WebResource.axd" negate="true" />

     </conditions>

     <action type="Redirect" url="{R:1}/" />

    </rule>



   </rules>

  </rewrite>

 </system.webServer>

</configuration>

ルールのテスト

　ルールが保存できたので、サイト上で試してみましょう。わたしのサイト上で以下の2つのURLを試しましょう。

　http://www.scottgu.com/albums.aspx

　http://scottgu.com/albums.aspx

　1つ目のURL（“www”が先頭に付いている）が自動的にwwwの付いていない2つ目のURLへリダイレクトされるようになったことをご確認ください。これはパーマネント・リダイレクトなため、検索エンジンはそのURLを追っていき、ページ・ランキングを更新します。

SEOを改善するシンプルな4つのルール

　上記の4つのルールを設定するのは非常に簡単で、15分もかからずに既存のサイトを構成できます。

　URLの書き換え拡張のようなソリューションを使うことの長所は、Webサイトにあるコードの変更がいらないことや、あなたのサイトに向けている既存のリンクを壊すことがないという利点が得られることです。既存のリンクをたどっているユーザーは、公開したいと思っている新しいURLへ自動的にリダイレクトされます。検索エンジンはより高い検索関連性のランキングを与え始めるので、検索結果であなたのサイトは上位にリストされ、それにより、より多くのトラフィックが導かれます。

　URL書き換えルールをさらにカスタマイズすることも簡単で、web.configファイルを直接編集したり、または、IIS 7.xのアドミン・ツールのURL書き換えアイコンをダブルクリックしたりするだけで、Webサイトまたはアプリケーションに対するすべてのアクティブなルールを一覧できます。

図20

　上記のどのルールをクリックしてもルール・エディタが開くので、さらにそれらの微調整／カスタマイズ／保存ができるようになります。

まとめ

　SEOの測定および改善は、公開用Webサイトを構築するすべての開発者が考え注目すべきことです。もしまだ行っていない人は、サイトのSEOを分析するのにSEOツールキットをダウンロードして利用してください。

　ASP.NET MVCやASP.NET Webフォーム4にある新しいURLルーティング機能では、公開済みのURLをもっと管理できるアプリケーションを簡単に構築できます。このブログ投稿で話したURL書き換え拡張のようなツールでは、多くのコードを変更することなく、すでに構築されているサイトから公開されているURLの改善が非常に簡単にできます。

　URL書き換え拡張は、SEOだけでなく、さらに素晴らしい多くの追加機能を提供します。今後のブログ投稿で、それらの追加機能についてはカバーする予定です。

　Hope this helps,

　Scott

　「～ScottGu氏のブログより～」

Insider.NET フォーラム新着記事

第2回　簡潔なコーディングのために （2017/7/26）
　ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
第1回　Visual Studio Codeデバッグの基礎知識 （2017/7/21）
　Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
第1回　明瞭なコーディングのために （2017/7/19）
　C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
Presentation Translator （2017/7/18）
　Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える