🌐The onwer of 海外SEO情報ブログ🔎
เป็นสมาชิกตั้งแต่ 20/12/2555
ประวัติส่วนตัว
🏅 Google Product Expert
📝 SEO Blogger
🥑 Search Advocate
😼Mieruca Global Strategist
รางวัลพิเศษ
กิจกรรม
| คำแนะนำในชุมชน | |
| วิดีโอของชุมชน |
| คำถาม | |
| การตอบกลับทั้งหมด |
| แนะนำ |
แผนภูมิกิจกรรมของผู้ใช้
โพสต์ประวัติ
ตอบกลับ 会員限定動画の構造化マークアップに関する質問
Google 検索セントラル•30/1/2568
ตอบกลับ 会員限定動画の構造化マークアップに関する質問
Google 検索セントラル•30/1/2568
ペイウォールコンテンツの構造化マークアップと合わせて動画の構造化マークアップをしており
「合わせて」というのは、1 つの構造化データのまとまりとしてマークアップしているということでしょうか？
それとも、ペイウォールと動画の構造化データを個別に同じページにマークアップしているということでしょうか？
後者であれば、ペイウォール内のエリアに動画構造化データをマークアップすれば検索結果には出ないはずです。
ตอบกลับ トークンの削除ができない
Google 検索セントラル•30/1/2568
CDN は利用していますか？
キャッシュやリダイレクトなど、確かにいろいろな理由が考えられそうです。
URL を提示いただければこちらでも調べられますが、可能ですか？
ตอบกลับ ユーザーと権限で自分を削除したい
Google 検索セントラル•1/1/2568
別のオーナーに削除してもらってください。
คำตอบที่แนะนำ
ตอบกลับ ワードプレスの個人ブログが危険とみなされる
Google 検索セントラル•1/1/2568
Google検索に関係していますか？
คำตอบที่แนะนำ
ตอบกลับ 求人の構造化データのdescriptionについて
Google 検索セントラル•23/11/2567
<br /> ではなく \n で改行するとどうなりますか？คำตอบที่แนะนำ
ตอบกลับ ビジネスプロフィールのオーナー確認をする
Google 検索セントラル•21/11/2567
คำตอบที่แนะนำ
ตอบกลับ 求人の構造化データのdescriptionについて
Google 検索セントラル•21/11/2567
①Pタグの前後には改行が入るのでしょうか？
1行のスペースを入れたくなければ
<br /> で改行してみてください➁文章の前後にpタグをつけなくても正常に表示されるのでしょうか
<br>, <p>, または \n を用いて段落区切りを追加するように指示されています。
が、なくても表示されるような気がします（でも、ガイドラインに沿うことを推奨）
③調べるとhtmlタグで記載とあり実行したのですが間違えていますでしょうか。
<p><br><ul><li>で記載する。
利用できるタグは以下のとおりです。
<br><p><ul><li>
④description内で<h>タグは使用できないのでしょうか。
使っても構いませんが、認識されません（無視される）
⑤太字はできますか？<strong>タグは使えるのでしょうか？
太字はできません。<strong> を使っても構いませんが、認識されません（無視される）
⑥google for jobsで求人本文が下記のように見えるようにするには、どのように記載するのが正しいのでしょうか。可能であれば実際にマークアップしていただきたいです。
これはどうでしょう？
<p>シンプルな軽作業のお仕事です！<br />これはテストの求人です</p><p>ぜひご応募ください。</p>利用できるタグ、できないタグはドキュメントに書いてあります。
https://developers.google.com/search/docs/appearance/structured-data/job-posting#job-posting-definition
คำตอบที่แนะนำ
ตอบกลับ サブドメインで作成したページがGoogle検索に出てきません
Google 検索セントラル•8/11/2567
サイトの URL を提示するとコミュニティのエキスパートが見てくれます
คำตอบที่แนะนำ
ตอบกลับ SERPsに旧ドメインが表示されるようになりました
Google 検索セントラル•8/11/2567
サイトの URLを提示していただければこちらでも調べられます
ตอบกลับ AI Overviewsからの流入について
Google 検索セントラル•28/10/2567
google / organic でした。通常のウェブ検索とは区別できません（Search Console でも区別できない）
ตอบกลับ ドメインを解約した後、サーチコンソールのプロパティ削除ができない
Google 検索セントラル•29/9/2567
คำตอบที่แนะนำ
ตอบกลับ sitemap.xmlの記述について
Google 検索セントラル•25/9/2567
定義に従っていない場合、サイトマップが読み取られないことがあります。
SEO に影響があるかどうかは、何を持って「影響がある」とするかによります。
大規模サイトのようですから、サイトマップはインデックス対象 URL の発見に役立ちます。
この点で言えば、サイトマップが適切に読み取られない場合は、適切に読み取られた場合と比較して URL 発見が遅れるかもしれません。
しかし、サイトマップが間違っていたからといって評価が下がることはないし、まして手動の対策を受けることも絶対にありません。
SEO に悪影響はありません。
คำตอบที่แนะนำ
ตอบกลับ JobPostingが表示されなくなった件
Google 検索セントラル•20/9/2567
1、JobPostingのタグの掲載日を最新の日付に更新
これは
datePosted プロパティのことですよね？2、JobPostingのタグの掲載終了日を削除
こちらは、
validThrough プロパティのことですよね？コードを編集したとのことで、更新が正常に反映されていないのかなと思いました。
編集後に再クロールされていますか？（URL検査ツールで確認可能）。
再クロール後に再インデックス処理もあり、検索結果への反映にはさらに別のプロセスも必要になります。
サイトマップでは、更新したページには
lastmod を指定してください。可能であれば、Indexing API を利用するのも良いかと。
คำตอบที่แนะนำ
Google 検索セントラル•18/9/2567
Discover からのトラフィックは、キーワード検索からのトラフィックと比べて予測可能性や信頼性が低くなります。このような偶発的な要素を考慮し、Discover からのトラフィックは、キーワード検索のトラフィックの補完的なものと考える必要があります。- Discover のトラフィックが時間の経過とともに変化する理由 -
こちらのドキュメントはすでにお読みかとは思いますが、Discover のコントロールはできないものと考えるべきかと思います。
何もしていなくてもトラフィックがなくなり、かと思うと突然復活したりします。
Discover は特別ボーナスのようなものと捉えて、主力トラフィック源として計算に入れないほうが無難です。
検索ほか、他のトラフィック獲得にフォーカスした方が確実性、生産性が高まるのではないでしょうか。
คำตอบที่แนะนำ
Google 検索セントラル•10/9/2567
可能性として考えられるのは次の 2 つですかね。
- 何らかの理由による Google 側の認識ミス
- コンテンツの品質が低いため、Google が強制的に正規化してしまった
もちろん、他の理由も十分にありえますが、URL がわからない以上、特定は不可能です。
オフィスアワーで相談することを推奨します（非公開で URL を提示できます）
こちらのフォームから質問できます。
คำตอบที่แนะนำ
Google 検索セントラル•10/9/2567
- hreflang は自己参照も含めて、すべてのページで相互参照している
- rel="canonical" は自己参照
上記を確実に設定できていますよね？
hreflang については、こちらのツールでも検証してください。
異常が出始めた直前にサイトに何か変更を加えたでしょうか？
ตอบกลับ WEBメディアの構造化設定方法
Google 検索セントラル•9/9/2567
構造化データを更新しても、Gemini が現在に名称を認識する保証はありません。
とりあえず、Gemini はわきに置きます。
運営会社を、Google が検索でサポートする構造化データで指定するには、質問者さまのケースでは次の 2 つが適切でしょう。
組織構造化データは、トップページにだけマークアップすれば十分です（もしくは会社案内ページ）
記事構造化データは、各記事にマークアップし、運営会社を
author プロパティの Organization タイプを指定すればいいでしょう。なお、構造化データは必須ではありません。
マークアップしなくても、クロールとインデックス、ランキングに直接の影響はありません。
リッチリザルトなど、検索結果の表示に主に関係します。
คำตอบที่แนะนำ
ตอบกลับ 重複ページの制御について
Google 検索セントラル•5/9/2567
→フィーチャーフォン用全ページにnoindexを施そうと考えています。
noindex が妥当ですね。
ガラケーユーザーのアクセスが無視できるくらいの少なさなら、思い切って削除してもいいのかなと思います（メンテナンスも不要だし、大規模サイトならクロール効率の観点からも不要な URL は減らしたい。そして、いずれは完全に削除するでしょう）。
パラメータによる重複コンテンツは、tokoma noshi さんが提案したように、僕なら rel="canonical" で対処します。
ヒントとはいえ、パラメータ URL に関してはたいてい従ってくれはずです。
คำตอบที่แนะนำ
ตอบกลับ サーチコンソールのクロール済みインデックス未登録に新規記事が出る
Google 検索セントラル•2/9/2567
クロールして即座にインデックスされるわけではないので、「クロール済み - インデックス未登録」自体は問題ありません。
時間が解決します。
しかし、時間がたってもインデックスされないページが多い場合は、何らかの問題をサイトが抱えているかもしれません。
最近多いのは、コンテンツの品質が低いケースです。
低品質のためインデックスする価値がないと Google が判断することがあります。
インデックス状況が芳しくない状態が継続する場合はこちらのガイダンスを参照してください。
คำตอบที่แนะนำ
ตอบกลับ 中古ドメインによる重複コンテンツ
Google 検索セントラル•2/9/2567
rel="canonical" はヒントであって命令ではないので（とはいえ、Google 検索では https 優先ではありますが。ただ、それでもやっぱりリダイレクトが好ましいです）。
คำตอบที่แนะนำ
ตอบกลับ 新しいサイト名がインデックスに紐づかない
Google 検索セントラル•29/8/2567
それらのサイトと比較して、質問者さまのサイトの関連性が低いと Google が判断しているためと思われます。
「たんかつ」という指名検索で検索からのトラフィックを増やしたいのでしょうか？
そうであれば、他のサイトに引用されるような良質なコンテンツを長期にわたってたくさん公開する必要があります。
サイト内で「たんかつ」を連呼してもさしたる意味はありません（自己推薦ではなく、多くの第三者に「たんかつ」といえばこのサイトと認知される必要があります）。
ตอบกลับ 突然、所有者未確認の状態になって、正しく表示されなくなりました
Google 検索セントラル•29/8/2567
DNS レコードをご自身で設定なさったのなら簡単です。
ตอบกลับ 突然、所有者未確認の状態になって、正しく表示されなくなりました
Google 検索セントラル•28/8/2567
いただいた情報だけでは特定は難しそうです。
差し当たり、meta タグや HTMLファイル、Google アナリティクスなど別の方法で所有者確認してはいかがでしょうか？
ตอบกลับ ECサイトの商品一覧のtitle要素について
Google 検索セントラル•27/8/2567
10年前くらい
ご認識のとおり 10 年前の話ですよね。
title 要素はもちろん今でも評価のシグナルです。
ページの内容を理解したりやクエリとの関連性を評価するために用いられます。
ですが、10年前とは違い、ランキングに多大な影響を与えるかというとそういうことでもないのです。
現在の SEO は、特にテクニック的な何か（今回で言えば title タグのキーワード） 1 つをやればそれが（ランキングに）大きな影響を与えるというものではなくなっています。
คำตอบที่แนะนำ
ตอบกลับ ECサイトの商品一覧のtitle要素について
Google 検索セントラル•27/8/2567
ユーザーが見た時にどのように見えるかを考えるとよいのかなと思います。
僕もこの意見に賛成です。
ページ内容を反映させつつも、検索結果でユーザーにどのように認識させるかも重要です。
「大カテゴリ」を入れることに反対はしませんが、同時に必須ではないかなとも考えます。
ตอบกลับ ページの参照元箇所の特定
Google 検索セントラル•24/8/2567
たとえば毎秒ごととか。
サーバーに過負荷を与える影響を与えるほどなのかどうかをまず検証してください。
ตอบกลับ ページの参照元箇所の特定
Google 検索セントラル•21/8/2567
無視してもクロールとインデックス、ランキングに影響はありませんよ。
気分的に気持ち悪いとかですかね？
ตอบกลับ サイトの所有権の確認がすぐにできない場合の期限
Google 検索セントラル•20/8/2567
本人確認書類等を提出する本人確認
Search Console の話をしてますよね？
Search Console の所有者確認に書類を提出する必要はありませんよ（そもそも提出先が存在しない）
他のプロダクト/サービスとごちゃ混ぜになっている気がします。
คำตอบที่แนะนำ
Google 検索セントラル•20/8/2567
特に設定も必要ないので、サイトマップの URL を登録するだけですよ。
（サイトマップのファイル名は
wp-sitemap.xml）https://test.com の所有者であれば、A と B のサイトマップを送信できます。
ตอบกลับ サイトの所有権の確認がすぐにできない場合の期限
Google 検索セントラル•20/8/2567
他の本人確認等は完了している場合に、
「他の本人確認」とは何でしょうか？
Search Console の所有者確認に関係してくるのは、そのサイトの確認用トークンです。
他のプロダクトやサービスは関係ありせん。
サイトを公開した時点で所有者確認してください。
ตอบกลับ 不正に登録されたインデックスを削除したい
Google 検索セントラル•12/8/2567
不正に登録されたページは404エラーになっており
404を返していて、検索結果にも出ないようであれば、何も問題ありません。
Search Console の 404 が長期にわたってレポートに出てくるのは普通です（一時的な 404 かもしれず、数回の再クロールを繰り返すため）。
無視できます。
404 を返しているのに検索結果に出てくるページを発見した場合は、削除ツールから削除リクエストすることでインデックス削除を促進できます。
คำตอบที่แนะนำ
ตอบกลับ コンテンツがインデックスされるかどうか
Google 検索セントラル•9/8/2567
いったんインデックスが遅くなったサイトのインデックスを促進するのは簡単ではないし長い時間がかかることが通常です（要は、Google の低評価をひっくり返さなければならない）。
サイトマップや、トップページからのリンク、他のサイトからのリンクなどは URL の発見に役立ちます。
とはいえ、やっぱり最重要なのはコンテンツの品質です。
こちらのドキュメントもご参考に。
คำตอบที่แนะนำ
Google 検索セントラル•6/8/2567
レンダリング時に削除しているか、モバイルには配信していないか、チェックしてください。
（CDN もお使いのようなので、その辺の構成も）
ตอบกลับ 7月後半に順位が急落、コアアップデートでしょうか？
Google 検索セントラル•5/8/2567
ランキングに関するアップデート情報は、Google Search Status Dashboard で確認できます。
なおコア アップデートでなかったとしても、大きな順位変動が発生することは珍しくありません。
コア アップデートが実施されたからといって、そのための特別な対応が必要になるわけでもありません。
こちらのドキュメントもご参考に。
คำตอบที่แนะนำ
ตอบกลับ AMPページが有効なのかどうか
Google 検索セントラル•5/8/2567
しかし、現在 AMP は Google 独自のフレームワークではなく、OpenJS に移管し、いわばウェブ標準のテクノロジーになっています。
とはいえ、もともとモバイルウェブの高速化および UX 向上を目的としていた AMP ですが、現在はさらに新しい技術の登場でもはや廃れたテクノロジーと言ってもいいでしょう。
AMP でなければならない強いこだわりがない限りは、いまさら AMP を実装する価値はないと僕は考えます。
AMPはSEOへの効果はほぼないとは思いますが
「ほぼ」というよりゼロですね。
คำตอบที่แนะนำ
Google 検索セントラル•29/7/2567
> ①構造化を埋め込んでいるイベント詳細ページのURLを入れても問題ないでしょうか？
イベント登録ページの URL を代わりに使用します。
If the URL to join the event isn't available until after registering for the event, provide the registration URL where people can take the next steps to join your event.
> ②URLがなくてもリッチリザルトテストが有効になるようですが、なくても良いでしょうか？
オンラインイベントでは、
location.url は必須プロパティです。This property [location.url] is required if your event is happening online.
RRT で有効になるのは、物理イベントの場合は必須プロパティではないためだと思います（オンラインかどうかまでは、識別できていないと思われる）。
ドキュメントを参照すれば、すべての疑問は解決できますよ。
実際に、僕はドキュメントも参照しながら回答しています。
คำตอบที่แนะนำ