URL短縮サービスを使用するのではなく、独自のドメイン上の短いURLから301リダイレクトを使用することの欠点はありますか？
自分のドメインでリダイレクトをURL Shortenerのようなものとして使用することにマイナスの影響があるかどうか疑問に思います。
私はよく「短いURL」用の印刷文書を作成する人々から尋ねられます。私の前任者は301リダイレクトを使用してこれを行いました。練習は間違っているように思えますが、その理由を説明することはできません。
唯一の本当の欠点は、多くのリダイレクトを設定すると、最終的にサーバーの負荷になり始める可能性があることです。サーバーはトラフィックとコードのパフォーマンスとともに大きく異なるため、リダイレクトの数が多すぎるという魔法の数字はありません。逸話的に、私は月に約220,000のページビューでウェブサイトを管理しており、通常、パフォーマンスの問題なしに、.htaccessの他の800以上の行とともに、200から300のバニティリダイレクトが通常あります。マイナスの影響を与えることなく、トラフィックの多いサイトを管理しました。パフォーマンスに不安がある場合は、リダイレクトのバッチを追加する前後にサイトの速度を測定して、パフォーマンスに影響を与えないようにしますが、一般的に、パフォーマンスの低い共有ホストを使用している場合を除き、表示されませんこれらの単純なリダイレクトの問題。単純な1対1のリダイレクトは、通常はパフォーマンスへの影響に気付くRedirectMatchのようなものと比較して、それほどパフォーマンスが高くありません。
CMSを使用している場合、このタイプのリダイレクトを追加するためのプラグインが利用可能かどうかを検討することをお勧めします。そうすることで、マーケティング担当者が独自のリダイレクトを設定できるようになります。そうすることで、既に設定されているものを忘れてしまう可能性があるため、既に存在するリダイレクトを確認することもできます。このようなプラグインは、品質と機能が異なります-302を実行するもの、301を実行するもの、リダイレクトの重大な負荷に達したときにパフォーマンスの問題が発生するものもあります。ただし、誰かが新しいバニティURLを必要とするたびに.htaccessファイルを手動で編集するよりも、時間を大幅に節約できます。
注意事項：これらの設定を開始する前に命名規則を設定すると役立ちます。すべてのバニティーURLをすべて小文字にする（すべて小文字の場合は印刷された部分から手動で入力する方が簡単なので）か、タイトルケースを許可するかを前もって決定します。ハイフン（SEOフレンドリーでモバイルキーボードで簡単に見られる）またはアンダースコア（より古めかしいが完全なURLに一致する可能性がある）を好むかどうか、およびバニティURLの長さに厳しい文字制限があるかどうかを決定する許可されています。
最後に、これらの印刷物に役立つ可能性のある他の何か：GoogleのUTMパラメーターを調べます。特定の印刷物から特定のURLを実際に何人が入力したかを測定することが有用または興味深いと思われる場合は、使用する印刷媒体ごとに個別のバニティURLを設定してください。したがって、たとえば、example.com/tx-offerを使用して、
example.com/offers/september/?utm_campaign=offer&utm_medium=print&utm_source=texas-magazine
example.com/ks-offerもリダイレクトします
example.com/offers/september/?utm_campaign=offer&utm_medium=print&utm_source=name-of-kansas-magazine
したがって、実際には両方が同じランディングページに移動しますが、utm_sourceおよびその他のパラメーターは、カンザスマガジンまたはテキサスマガジン-おそらく同じクリエイティブを使用して-より多くの実際の訪問者をWebサイトに送りました。これはもちろん、Googleアナリティクスでそのようなことを測定している場合にのみ役立ちますが、かなり一般的で設定は無料です。これは、どの印刷物がより成功しているかを人々がよりよく理解するのに役立つかもしれません。これは、開始する前に可能であれば標準化するもう1つのことです。キャンペーンを追跡するために、便宜上小文字を使用するか、おそらく大文字を使用するかを決定します。メディア（雑誌とニュースレターなど）の「印刷」よりも細かくすることも、すべての「印刷」メディアをグループ化して1つのビューでより簡単に比較することもできます。有料キャンペーンに取り組んでいない場合でも、時間とお金をかける場所を決定するのに役立つ場合があります。たとえば、ポストカードはニュースレターよりもパフォーマンスが低いため、ポストカードにWeb CTAがもうないかもしれません。
これは全体的には良いアイデアだと思います。サードパーティのショートナーを使用するよりは確かに良いですが、考慮したいことがいくつかあります。
- どのようにリダイレクトを実際に実装しますか。Webサーバーの設定ファイルは1つの方法ですが、実際には大量のURLに特にうまく対応できません。スクリプトベースのsoloutionはより柔軟で、広範囲のURLを処理できますが、発行されるリダイレクトごとのオーバーヘッドが潜在的に高くなります。
- 本当に 301を使用しますか？または、302を使用してサーバー負荷を少し増やして、柔軟性を維持しますか？
- 通常のURLとリダイレクトの競合の可能性をどのように管理しますか（一部のサイトでは専用ドメインを使用しているため、この問題を回避し、短縮URLをさらに短くすることができますが、リンクが合法である場所でユーザーが混乱する可能性があります）。
- リダイレクトの大文字と小文字を区別せずに、タイトルケースのURLを公開できる一方で、Enterキーを押すのを忘れた訪問者を取得できるシステムが必要ですか？
URL短縮サービスを使用するサービスではなく、独自のドメインでURL短縮サービスを使用すると、おそらく利点があります。
1つには、301リダイレクトがリンクジュースの90〜100％を渡すことがわかっています。そのため、リンクがurlshortener->example.com/pageから送信されると、urlshortenerサービスで一部が失われる可能性があるため、example.comはリンクジュースの100％をキャプチャしない場合があります。一方、独自のサービスを使用する場合、失われたリンクジュースはおそらく独自のドメインに保持されます。
Htaccessリダイレクトは遅いと見なされますが、ミリ秒について話しています。 URL短縮サービスは、ご使用のサーバーよりもリダイレクトが高速になるように最適化される可能性がありますが、時間差はほとんど目立たない可能性があります。また、必要なサーバー/ドメインリクエストごとにページをロードするのに余分な時間がかかります。 URL短縮サービスでは、ページを読み込むために複数のサーバーリクエストが必要ですが、独自の短いURLは1つのサーバーリクエストのみを必要とします。
ブランド認知度もあります。 urlshortenerのリンクが表示されても、そのブランド名は表示されません。彼がexample.com/urlを見ると、特にリンクがアンカーテキストでもある場合、リンクにブランドが表示されます。
同様に、Googleは検出したすべてのリンクをクロールしません。そして、これは私自身の考えに基づいた推測にすぎないかもしれませんが、example.comリンクを発見したとき、それはブランドの言及としてカウントされるかもしれません。また、クロールしないにもかかわらずリンクを承認するだけで、example.comに信頼スコアを渡すこともあります。 urlshorteningサービスのリンクとして独自のドメインがある場合、この機会は失われます。
数年前に人気が高まっているように見えるため、ほとんどの主要ブランドはurlshortenerサービスから離れたようです。それらの使用が過剰であり、潜在的に間違いである可能性は十分にあります。 urlshortenerサービスの一部は、それに付随するNiceデータ分析トラフィックを提供しました。これは、おそらくいくつかの大規模サイトがそれらを使用している大きな理由です。
また、Twitterは最大ツイート文字数に対してURLサイズをカウントするため、ロングテールリンクの代わりに短いリンクをTwitterに持つことが非常に重要でした。また、当時のTwitterの人気の高まりは、urlshortenersが大きなトレンドになったこととおそらく関係がありました。しかし、URLサイズがTwitterの文字数にカウントされなくなったため、これはもはや当てはまりません。
URL短縮サービスの一般的な機能は、各リダイレクトの統計情報です（サーバーログから独自のリダイレクト用にこの情報を抽出することもできますが、かなり面倒な場合があります）。印刷されたドキュメントについて言及したので、これはもちろん、印刷された広告などの使用フィードバックを得るために一般的に使用されます。
つまり、独自のドメインで独自のURL短縮サービスをホストするためのソリューションは複数あります。便利なURL短縮サービスを提供するために、必ずしも外部サービスを使用する必要はありません。
正しく行われれば、同じパスでCMSとURL短縮サービスをホストすることも可能です-URLが区別できることを確認してください（たとえば、プレフィックスなどを使用して）。
自分のドメインでリダイレクトをURL Shortenerのようなものとして使用することにマイナスの影響があるかどうか疑問に思います。
本当にミリ秒になります。どうして？非常に重要な要因の1つは、「最初のバイトまでの時間」という用語です。これは、最初のバイトがWebブラウザーで認識されるまでにかかる時間を意味します。
Webページへのリダイレクトを作成するために、あらゆる種類のリモートサービスを使用することは、a）Stevenが示したように、追加のDNS要求が必要であり、クライアントの待ち時間が長くなることに加えて、リクエストを処理するリモートコンピューターの速度で、そのコンピューターが古い '286プロセッサーのように機能する場合、そのサービスを使用すると、リダイレクトに到達したクライアントが待機する場合があります数秒今日の世界ではひどい画面上の最初のキャラクターを参照してください。
今、あなたがウェブマスターとしてできることは、あなたのウェブページを保存しているコンピューターを制御している人に、それが優れた速度で実行されていることを確認することです。その後、同じサーバーで自分でリダイレクトページをホストできます。サーバーを実行する場合は、不要なバックグラウンドプロセスが実行されないようにしてください。
また、完了したら、URLを送信する検索エンジンが新しいURLのみを受信し、古いURLは受信しないことを確認してください。これにより、新しいURLへのリダイレクトである古いURLを要求する必要が最小限になります。
ヘック、ボーナスとして（何千人もの人々がアクセスするので、私は常に自分のサイトのHTMLに何かをします）、頻繁に使用されるページをサーバーのRAMドライブに配置してみてください。ディスク。ただし、これを行う場合は、コンピューターをリセットするとRAMの内容が消去され、データをRAMに再ロードして最高速度を実現できるように、ディスク上のバックアップが必要になります。
結局のところ、webpagetest.orgなどのテストツールを使用して、最初のバイトまでの時間を測定してください。それは非常に重要です。また、テストするときは、サーバーから最も遠く離れた場所を選択してください。そうすることで、遠く離れた場所にいる人でもサイトを快適に利用できます。
本当の欠点はありません。実際、多くのサイトは、少なくとも/1234/my-article-about-goats/と/1234/goats/を使用してロードできる/1234/g/などの短縮可能なURLを使用していますが、/1234/。
これらのURLを正規のURLにし（対応するタグを使用してHTMLに追加）、ユーザーに対して長い「SEO-URL」のみを使用することを検討する必要があります。次に、数値のみのバージョンから長いバージョンにリダイレクトする場合としない場合があります。
URLの一致が厳密でないと、URLのタイトルが/1234/my-article-about-cats/に変更される可能性があり、他の人はヤギではなく猫が好きだと思うかもしれません。したがって、少なくとも、間違ったスラッグのURLから現在のスラッグのURLにリダイレクトすることができます。
考慮すべきもう1つの点：任意のURLに対してshort.mydomain/a6xスタイルの自動生成リダイレクトを本当に実装したい場合は、短いURLサービスをホストし続けるか、それを中止するときに多くのURLを中断することを確認する必要があります。