タグ付けされた質問 「url」

URL(Uniform Resource Locator)は、ファイルまたはリソースのアドレスであり、そのリソースの場所と、リソースを取得する方法を指定します。

3
Stack Overflowの質問URLには、SEOフレンドリーな「質問」の前に質問IDが付いているのはなぜですか?
たとえば、次のランダムな質問を考えてみましょう。特定のcssセレクターがどのhtmlファイルで使用されているかを示すために必要なツールまたはプラグインは、関連する部分がであることに注意してください/questions/16999。 これで、次のようにURLを作成できた可能性があります。 /webmasters/tool-or-plugin-required-to-show-out-in-which-html-files-a-given-css-selectors-is/16999` つまり、question_idは質問の後にあり、URLで最初に来るものはseoでより重くなります。なぜ質問の部分はquestion_idの後に来るのですか。 また、最初の2つのサブディレクトリのみ/question/16999が関連するため、関連するだけであるという記事を読みました。SOを見てこれは間違いなく真実ではありませんが、私はこれの重さを決めることができません。 私はseoの最適化を実装するつもりであり、後で自分のページへのリンクを変更する必要がないため、質問しています。
13 url 

3
SEOフレンドリーURLに最適なファイル拡張子は何ですか?
私は、ウェブサイトのURLをSEOに優しいURLに変換するために、ウェブサイトで働いています。私はこれを使用する予定です: example.com/category-name/pageid-123-page-name 同様に分類され、ランクが高いWebサイトをいくつか見ました。それらは1つの点を除いて同じ構造を持っています。1つのケースでは、URL形式は example.com/category-name/pageid-123-page-name.html もう一つは example.com/category-name/pageid-123-page-name.php これで、URLのテキストがSEOに役立つことがわかりました。ファイル拡張子を付けた方が便利ですか?はいの場合、どちらが良いですか? または私の現在の計画が大丈夫である場合、それ/は最後に良いですか?


5
URLセグメントの日付の利点
URLセグメントの日付に興味がありましたが、SEOのメリットはありますか?たとえば、次のURL: http://techcrunch.com/2013/06/18/netflix-will-launch-in-the-netherlands-later-this-year-as-its-international-expansion-slows/ http://tips-for-new-bloggers.blogspot.in/2007/02/adding-favicon-icon-to-blogger-url.html https://community.jivesoftware.com/blogs/jivespace/2013/05/15/eol-of-the-html5-ipad-web-app 上記のすべてのURLには日付セグメントがあります。それらのブログの情報は、「netflix-will-launch-in-the-netherlands-later-this-as-its-international-expansion-slows」のようなブログスタブを介して取得できるので、なぜその日付部分を使用するのですか?
13 seo  url  dates 


2
URLにアスタリスクを使用できますか?
*URLにアスタリスク()を使用しない理由はありますか? バックグラウンド: アスタリスクを使用すると、これらのすてきで使いやすい(またはあなたはどう思いますか?)URLを提供できます。 example.com/some/folder/search-phrase*/ some / folder /にある「search-phrase」で始まる名前のページを検索 することを意味します。 example.com/some/**/*search-phrase*名前に「search-phrase」が含まれるページを検索 することを意味します。 example.com/some/folder/*/ some / folder /のすべてのページをリスト することを意味します(/ some / folder / indexページを表示するのではなく)。
12 seo  url  links 

3
URLに製品IDがあると、キーワードのみのURLに比べてSEOに悪影響がありますか?
たとえば、次のようなURLを持つカテゴリ(スーパーヒーロー)に製品(optimus-prime)を含むWebショップがあるとします。 www.example.com/superheroes/optimus-prime 次に、URLの製品名に製品ID(99)を付加して、URLを次のようにします。 www.example.com/superheroes/99-optimus-prime SEO、特にGoogleの検索ランキングに関して、ある製品のURLを他の製品のURLよりも使用すると、大きな違いはありますか? プログラマーとして、システムエイリアスの生成がCMSルーティングの目的で100%フェイルセーフになるため、IDが含まれているURLを使用することを好みます。
12 seo  url  identifier 

5
ドメイン名の大文字と小文字を定義できますか?
.comエクステンション付きのセカンドレベルドメイン(ウェブプラットフォームAltervista.org上)を購入したい。ドメイン検証プロセスでは大文字と小文字の両方で文字を入力できるため、これがドメインの最終的な形式に影響を与える可能性があるのか​​、URLで文字が大文字で表示されるのか、または私の以前の選択によると小文字。 最終的にURLは次のようになります。ただ、明確にすること、のは、私が名前「名前がMyWebSite」と私は「名前がMyWebSite」を選択し、ドメインの登録プロセス中にしたいことを、例えば、仮定してみましょうwww.MyWebSite.comかwww.mywebsite.com? だから、私の質問は:できるドメイン名はとの両方を表示することが、上または下ケースの中の文字URLとにおける検索エンジンのウェブマスターの前の選択に応じて、結果?


5
これら3つのURL書き換えのうち、SEOフレンドリーなURLはどれですか。
現在のフラットファイルのCMSなしのWebサイトに、などのURLがあるとしますhttp://example.com/en/tomato。 もちろんこれは非常にunsexyで、本当にから何もすることができスープトマト、音楽バンドトマト、映画トマト、またはさらにより低いしかし... ちょうどトマトについて! ですから、実際の人間と検索エンジンの両方に、より具体的にしたいと思います。与えられた:言語コードと短いファイル名コードの両方が不可欠であり、置き換えることができないので、.htaccessのような区切り文字enをtomato正確に/フォローして、目に見えない正しいリダイレクトを行う必要があります。//tomato.php?language=en URLに追加された単語に対していくつかのオプションが私の心の中で起こりました: A example.com/en/tomato/just-about-tomatos B example.com/en/tomato/just-about-tomatos.htm C example.com/just-about-tomatos/en/tomato D example.com/en/tomato_just_about_tomatos E example.com/en/tomato-just-about-tomatos 質問1:人間と検索エンジンのどちらに最適ですか。 質問2:これを.htaccessで発生させるエレガントなルールはどれですか。 あなたの提案と回答をありがとう!大変感謝いたします。

1
多言語のURL
私は、英語、繁体字中国語、簡体字中国語の3つの言語でサポートされるオンラインストアを構築しています。 私の質問は、SEOの目的で言語固有のURLを作成することは良い考えかどうかです。したがって、サイトを英語で表示している場合、製品ページのURLは英語ですが、繁体字中国語でサイトを表示している場合、URLは繁体字中国語で書かれています。 例: www.mysite.com/items/1/blue_cup(英語) www.mysite.com/xxxxx/1/xxxxxxxx(繁体字中国語) www.mysite.com/yyyyy/1/yyyyyyyy(簡体字中国語) 編集 私はこれが主に繁体字中国語を話す国のために構築されたサイトであるので、その聴衆と彼らの支配的な検索エンジンに応えるべきであることに注意すべきです:Yahoo
11 url  seo  multilingual 

2
URLパスとSEOへの影響
私たちは、ギャラリーと写真という2つの異なるタイプのコンテンツがあるWebサイトを開発しています。 / gallery / photoのようなURLパスを使用することはほとんど意味がありません。一部の写真は複数のギャラリーに表示される可能性があるためです(コンテンツの複製は不適切です)。したがって、現在のロジックは、サイト(/ photo1、/ photo2、/ photo3、/ gallery1など)に単一の深さを持つことです。 単一の深さのページの数が増えると、これはSEOに影響しますか?一般に、検索エンジンがよりRESTfulなインターフェース(/ galleries / gallery、/ photos / photo1など)を見る方が良いですか、それともより良い方法がありますか?これを処理するには? PS:写真には、(ギャラリーと同様に)深いテキストコンテンツを含む独自のランディングページがあります。
11 seo  path  url 

3
URLパスは大文字と小文字を区別する必要がありますか?
現在、私のWebサイトのURLでは大文字と小文字が区別されません。たとえば、次のリンクはどちらもまったく同じページを示しています。 http://example.com/about http://example.com/About しかし、wordpress.orgのWebサイトを見ると、URLは大文字と小文字が区別されていることに気付きました。たとえば、下の2番目のリンクは404エラーページです。 http://wordpress.org/about http://wordpress.org/About 私の考えは、私のWebサイトのURLで大文字と小文字を区別することです。コンテンツの重複を回避するという明らかな問題は別として、大文字と小文字を区別するURLを使用することの長所と短所は何ですか? 更新 Googleは独自のURLで大文字と小文字を区別するURLポリシーを運用しているようです。たとえば、下の2番目のリンクは404です。 http://google.com/doodles http://google.com/Doodles アップデート2 ご回答ありがとうございます。受け入れられた回答に記載されているアドバイスを取り入れ、必要に応じて301リダイレクトを実装することにしました。私はWordPressを使用しているので、私のコードソリューションは次のとおりです(誰かが興味を持っている場合に備えて)。 function force_lowercase_urls() { if ( is_admin() ) return; if ( preg_match( '/[A-Z]/', $_SERVER['REQUEST_URI'] ) ) { wp_redirect( strtolower( $_SERVER['REQUEST_URI'] ), 301 ); exit(); } } add_action( 'init', 'force_lowercase_urls' );

1
複数のディレクトリを持つWebサイトのURLパス構造
大量のコンテンツを持ついくつかのディレクトリを含むWebサイトを作成しています。 ここでは、URLをカテゴリに分けて、次のようにしました。 www.example.com/student/ www.example.com/student/student-name/ www.example.com/student/student-name/biography www.example.com/student/student-name/image-gallery/ www .example.com / student / student-name / image-gallery / gallery-name-1 www.example.com/student/student-name/image-gallery/gallery-name-2 www.example.com/student/student -name / contact www.example.com/teacher/ www.example.com/teacher/teacher-name www.example.com/teacher/teacher-name/biography www.example.com/teacher/teacher-name/image- gallery / www.example.com/teacher/teacher-name/image-gallery/gallery-name-1 www.example.com/teacher/teacher-name/image-gallery/gallery-name-2 多くの教師、学生、ギャラリー、ビデオなどがあります。 同じ方法で作成されたカテゴリがいくつかありますが、オンラインにする前に、これが最良の方法であるかどうかを確認したいと思います。


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.