MDN/Contribute/Howto/Write_for_SEO を更新 (#1982)

1 files changed, 39 insertions, 38 deletions

diff --git a/files/ja/mdn/contribute/howto/write_for_seo/index.html b/files/ja/mdn/contribute/howto/write_for_seo/index.html
index b03503c0bf..d56b7cb817 100644
--- a/files/ja/mdn/contribute/howto/write_for_seo/index.html
+++ b/files/ja/mdn/contribute/howto/write_for_seo/index.html
@@ -1,71 +1,72 @@
 ---
-title: どのように MDN Web Docs で SEO を考慮するか
+title: SEO を考慮して MDN Web Docs を書く方法
 slug: MDN/Contribute/Howto/Write_for_SEO
+tags:
+  - Contributing to MDN
+  - Documentation
+  - MDN
+  - MDN Meta
+  - MDN Web Docs
+  - SEO
+  - Search Engine Optimization
 translation_of: MDN/Contribute/Howto/Write_for_SEO
 ---
 <div>{{MDNSidebar}}</div>
 
-<div>{{IncludeSubnav("/ja/docs/MDN")}}{{draft("私たちは最近、SEO を改善するためのいくつかの提案されたテクニックの評価を終了しました。この記事とその貢献者ガイドを更新する過程にあります。")}}</div>
-
 <p><span class="seoSummary">このガイドでは、ユーザーが必要なものに簡単にアクセスできるように、検索エンジンがコンテンツを簡単に分類して索引付けできるようにするための標準的なプラクティス、推奨事項、およびコンテンツの要件について説明します。</span></p>
 
-<h2 id="イントロダクション">イントロダクション</h2>
-
-<p>MDN を執筆する主な目標は、常にオープンな Web 技術について説明し、情報を提供することです。それにより開発者は実現したいことをするため、あるいはコードを完成させるために知っておく必要のある詳細を見つけるために学ぶことができます。彼らが、私たちが書いている資料を探し出せることが重要です。</p>
-
-<p>Since most readers reach content on MDN through search engines, as writers, we have to keep that in mind while we work. To do that, we are establishing a selection of "SEO guidelines," to help writers and editors on MDN ensure that each page they work on is reasonably well designed, written, and marked up to give search engines the context and clues they need to properly index articles.</p>
-
-<h2 id="この文書のステータス">この文書のステータス</h2>
+<h2 id="Introduction">イントロダクション</h2>
 
-<p>We're currently in the midst of the early stages of what is intended to be a long-term project to improve search engine optimization ({{Glossary("SEO")}}) on MDN. We have recently completed a series of small-scale experiments to test theories and to determine what changes to make to our practices and to the contributor guidelines to help improve our SEO.</p>
+<p>MDN を執筆する主な目標は、常にオープンなウェブ技術について説明し、情報を提供することです。それにより開発者は実現したいことをするため、あるいはコードを完成させるために知っておく必要のある詳細を見つけるために学ぶことができます。彼らが、私たちが書いている資料を探し出せることが重要です。</p>
 
-<p>We are still in the process of compiling our notes and updating this article and the rest of the contributor guide to incorporate our findings.</p>
+<p>MDN の読者の多くは検索エンジンを経由してコンテンツにたどり着くため、執筆者としてはそのことを念頭に置いて作業をしなければなりません。そのために、 MDN の執筆者や編集者が、それぞれのページが適度にデザインされ、書かれ、マークアップされ、検索エンジンが記事を適切にインデックスするために必要な文脈や手がかりを与えることができるように、「SEOガイドライン」を制定します。</p>
 
-<h2 id="SEO_チェックリスト">SEO チェックリスト</h2>
+<h2 id="SEO_checklist">SEO チェックリスト</h2>
 
-<p>The following is a list of things you should check while writing and reviewing content to help ensure that the page and its neighbors will be indexed properly by search engines.</p>
+<p>ページとその周辺が検索エンジンに適切にインデックスされるようにするために、コンテンツを書いたり見直したりする際に確認すべきことを以下にまとめました。</p>
 
 <ul>
- <li>Make sure the page's contents are <a href="/en-US/docs/MDN/Contribute/Howto/Write_for_SEO#Ensure_pages_aren't_too_similar">different enough from other pages</a> that search engines don't assume they're about the same thing.</li>
+ <li>ページの内容が<a href="#ensure_pages_aren't_too_similar">他のページとは十分に異なり</a>、検索エンジンが同じことについて書かれていると思わないようにしましょう。</li>
+ <li><a href="#avoid_pages_that_are_too_short">短すぎるページは避けましょう</a>。短すぎる記事 (SEO 用語では「薄いページ」と呼ばれます) は、正確なカタログ化が困難です。 MDN のページは、可能な限り、 300 語程度以下の短さを避けるべきです。</li>
 </ul>
 
-<h2 id="Ensure_pages_aren't_too_similar">Ensure pages aren't too similar</h2>
+<h2 id="Ensure_pages_aren't_too_similar">似たようなページにならないようにする</h2>
 
-<p>Each article should be as unique as possible. Articles that look similar to one another textually will wind up being considered to be about roughly the same thing, even if they aren't. For example, if an interface has the properties <code>width</code> and <code>height</code>, it's easy for the text to be surprisingly similar, with just a few words swapped out, and using the same example. This makes it hard for search engines to know which is which, and they wind up sharing page rank, resulting in both being harder to find than they ought to be.</p>
+<p>各記事はできる限り固有であるべきです。テキストが似ている記事は、実際には似ていなくても、ほぼ同じ内容であるとみなされてしまいます。例えば、インターフェイスに <code>width</code> と <code>height</code> というプロパティがある場合、同じ例を使っていくつかの単語を入れ替えただけで、驚くほど似た文章になってしまいがちです。これでは、検索エンジンはどちらがどちらなのか分かりませんし、ページランクも同じになってしまい、結果的にどちらも本来の目的よりも見つけにくくなってしまいます。</p>
 
-<p>Understandably, writers confronted with two related properties like <code>width</code> and <code>height</code> (or any other set of functionally related features) are tempted to write the article on <code>width</code>, then copy that article and paste it into the one on <code>height</code>, replacing a few words. Done!</p>
+<p>当然のことながら、 <code>width</code> と <code>height</code> のような 2 つの関連するプロパティ (または機能的に関連する他の機能のセット) に直面した執筆者は、 <code>width</code> に関する記事を書き、その記事をコピーして <code>height</code> に関する記事に貼り付け、いくつかの単語を入れ替えればよいと思うでしょう。これで完了。</p>
 
-<p>Unfortunately, the result is two pages that, as far as search engines are concerned, may as well be the same thing.</p>
+<p>残念ながら、結果として、検索エンジンが懸念する限りでは、同じものであるかもしれない 2 つのページができあがります。</p>
 
-<p>It's important, then, to ensure that every page has its own content. Here are some suggestions to help you accomplish that:</p>
+<p>そのためには、すべてのページに独自のコンテンツを持たせることが重要です。ここでは、それを実現するためのいくつかの提案を紹介します。</p>
 
 <ul>
- <li>Consider use cases where there might be more differences than one would think. For instance, in the case of <code>width</code> and <code>height</code>, perhaps consider ways horizontal space and vertical space are used differently, and provide a discussion about the appropriate concepts. Perhaps you mention the use of width in terms of making room for a sidebar, while using height to handle vertical scrolling or footers or similar. Including information about accessibility issues is a useful and important idea as well.</li>
- <li>Use entirely different examples on each page. Examples in these situations are often even more similar than the body text, since the examples may use both (or all) of the similar methods or properties to begin with, thereby requiring no real changes when reused. So throw out the example and write a new one, or at least provide multiple examples, with at least some of them different.</li>
- <li>Include descriptions of each example. Both an overview of what the example does as well as coverage of how it works, in an appropriate level of detail given the complexity of the topic and the target audience, should be included.</li>
+ <li>意外と違いがあるかもしれない使用例を考えてみます。例えば、 <code>width</code> と <code>height</code> のケースでは、水平方向の空間と垂直方向の空間がどのように異なる使い方をされているかを考え、適切な概念についての議論を行います。例えば、幅についてはサイドバーを設置するための空間として、高さについては縦方向のスクロールやフッターなどのために使用することを考えます。また、アクセシビリティの問題についての情報を盛り込むことも、有用かつ重要なアイデアです。</li>
+ <li>各ページにまったく異なる例を使ってください。このような場合の例は、本文よりもさらに似通っていることが多いものです。というのも、例はそもそも似たようなメソッドやプロパティの両方 (またはすべて) を使用していることがあり、再利用する際に実質的な変更を必要としないからです。そのため、例を捨てて新しい例を書くか、少なくとも複数の例を用意し、そのうちのいくつかは異なる例文してください。</li>
+ <li>それぞれの例について説明を加えます。トピックの複雑さと対象読者を考慮して、適切なレベルの詳細で、例が何をするのかという概要と、どのように機能するのかという説明の両方を含める必要があります。</li>
 </ul>
 
-<p>The easiest way to avoid being overly similar is of course to write each article from scratch if time allows.</p>
+<p>同じような内容になりすぎないようにするには、時間が許す限り、それぞれの記事を一から書き直すのが一番簡単です。</p>
 
-<h2 id="ページが短くなりすぎることは避ける">ページが短くなりすぎることは避ける</h2>
+<h2 id="Avoid_pages_that_are_too_short">ページが短くなりすぎることを避ける</h2>
 
-<p>Articles that are too short (called "thin pages" in SEO parlance) are difficult to catalog accurately. Whenever possible, pages on MDN should avoid being shorter than around 300 words or so. Here are some basic guidelines to help you create pages that have enough content to be properly searchable without resorting to cluttering them up with unnecessary text.</p>
+<p>短すぎる記事 (SEO 用語で「薄いページ」と呼ばれます) は、正確なカタログ化が困難です。 MDN のページは、可能な限り 300 語前後の短さを避けるべきです。ここでは、不必要なテキストでごちゃごちゃさせずに、検索に適した内容のページを作成するための基本的なガイドラインをご紹介します。</p>
 
 <ul>
- <li>Keep an eye on the convenient word counter located in the top-right corner of the editor's toolbar on MDN. This is not an exact representation of the true word count, since the true word count is based on the rendered page, not the page as you see it in the editor. That means macros that add a lot of words will result in a higher word count, while macros that insert nothing but adjust formatting will result in a lower word count.</li>
- <li>Obviously, if the article is a stub, or is missing material, add it. We try to avoid outright "stub" pages on MDN, although they do exist, but there are plenty of pages that are missing large portions of their content.</li>
- <li>Generally review the page to ensure that it's structured properly for the <a href="/en-US/docs/MDN/Contribute/Structures/Page_types">type of page</a> it is. Be sure every section that it should have is present and has appropriate content.</li>
- <li>Make sure every section is complete and up-to-date, with no information missing. Are all parameters listed and explained? Make sure any exceptions are covered (this is a particularly common place where content is missing).</li>
- <li>Be sure everything is fully fleshed-out. It's easy to give a quick explanation of something, but make sure that all the nuances are covered. Are there special cases? Known restrictions that the reader might need to know about?</li>
- <li>There should be examples covering all parameters or at least the parameters (or properties, or attributes) that users from the beginner through intermediate range are likely to use, as well as any advanced ones that require extra explanation. Each example should be preceded with an overview of what the example will do, what additional knowledge might be needed to understand it, and so forth. After the example (or interspersed among pieces of the example) should be text explaining how the code works. Don't skimp on the details and the handling of errors in examples; readers <em>will</em> copy and paste your example to use in their own projects, and your code <em>will</em> wind up used on production sites! See <a href="/en-US/docs/MDN/Contribute/Structures/Code_examples">Code examples</a> and our <a href="/en-US/docs/MDN/Contribute/Guidelines/Code_samples">Code sample guidelines</a> for more useful information.</li>
- <li>If there are particularly common use cases for the feature being described, talk about them! Instead of assuming the reader will figure out that the method being documented can be used to solve a common development problem, actually add a section about that use case with an example and text explaining how the example works.</li>
- <li>Include proper {{htmlattrxref("alt", "img")}} text on all images and diagrams; this text counts, as do captions on tables and other figures.</li>
- <li>Do <em>not</em> descend into adding repetitive, unhelpful material or blobs of keywords, in an attempt to improve the page's size and search ranking. This does more harm than good, both to content readability and to our search results.</li>
+ <li>もちろん、記事がスタブであったり、足りない部分があれば追加します。 MDN では、明らかな「スタブ」ページは避けるようにしていますが、実際には存在します。しかし、コンテンツの大部分が欠けているページはたくさんあります。</li>
+ <li>一般的には、<a href="/ja/docs/MDN/Structures/Page_types">ページの種類</a>に応じて適切に構成されていることを確認してください。持つべき節がすべて存在し、適切なコンテンツがあることを確認してください。</li>
+ <li>すべての節が完全で、最新の情報が含まれていることを確認してください。すべての引数がリストアップされ、説明されているか。例外がカバーされていることを確認してください (これは特にコンテンツが欠けていることが多い場所です)。</li>
+ <li>すべての項目が詳細に説明されているかどうか。簡単な説明をするのは簡単ですが、すべてのニュアンスが含まれているかどうかを確認してください。特別なケースはありますか？読者が知っておくべき既知の制限はありますか？</li>
+ <li>すべての引数、あるいは少なくとも初級から中級レベルのユーザーが使用する可能性のある引数 (またはプロパティや属性) と、追加の説明が必要な高度な引数を網羅した例を用意する必要があります。それぞれの例の前には、その例が何をするのか、それを理解するためにはどのような知識が必要なのかなどの概要を示す必要があります。例の後 (または例の一部の間) には、コードがどのように動作するかを説明する文章が必要です。例の詳細やエラー処理についても手を抜いてはいけません。読者は例をコピー＆ペーストして自分のプロジェクトで使用するでしょうから、そのコードが本番サイトで使用されることになるでしょう。より有用な情報は、<a href="/ja/docs/MDN/Structures/Code_examples">コード例</a>と<a href="/ja/docs/MDN/Guidelines/Code_guidelines">コード例のガイドライン</a>をご覧ください。</li>
+ <li>説明されている機能について、特に一般的な使用例がある場合は、それについて話してください。一般的な開発上の問題を解決するために文書化された方法を読者が理解すると仮定するのではなく、実際にその利用例についての節を追加し、例とその例がどのように機能するかを説明するテキストを追加してください。</li>
+ <li>すべての画像や図に適切な {{htmlattrxref("alt", "img")}} テキストを入れてください。このテキストは、表などのキャプションと同様に重要です。スパイダーは画像をクロールすることができないため、 {{htmlattrxref("alt", "img")}} テキストによって、埋め込まれたメディアに含まれるコンテンツを検索エンジンのクローラーに伝えることができます。注：検索エンジンのランキングを操作するために、キーワードを入れすぎたり、関係のないキーワードを使ったりすることは、ベストプラクティスではありません。このような行為は発見されやすく、罰せられる傾向にあります。</li>
+ <li>同様に、ページのサイズや検索順位を上げるために、反復的で役に立たない内容や、キーワードの塊を実際のページ内に追加するようなことも<em>しないでください</em>。これは、コンテンツの読みやすさと検索結果の両方に悪影響を及ぼします。</li>
+ <li>2013 年に行われた Google のハミングバードアップデートでは、自然言語による情報伝達が重視されるようになりました。つまり、特定のキーワードではなく、記事のトピックに沿ってコンテンツを書く方がはるかに良いということです。実際、多くの SEO 担当者は、記事の長さに応じて 5 ～ 100 種類のキーワード (ショートテール、ミディアムテール、ロングテール) をリストアップし、記事に含めるようにしています。そうすることで、表現が多様化し、繰り返しが少なくなります。</li>
 </ul>
 
-<h2 id="関連情報">関連情報</h2>
+<h2 id="See_also">関連情報</h2>
 
 <ul>
- <li><a href="/en-US/docs/MDN/Contribute">Contributing to MDN</a></li>
- <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Writing_style_guide">Writing style guide</a></li>
+ <li><a href="/ja/docs/MDN/Contribute">MDN への協力</a></li>
+ <li><a href="/ja/docs/MDN/Guidelines/Writing_style_guide">執筆スタイルガイド</a></li>
 </ul>