記事執筆者：認定SEOコンサルタント 三田健司
「見られたくないページは robots.txt でブロックしておけば大丈夫」。ホームページの運用を任されている方から、いまでも本当によく聞く言葉です。しかしこの理解は、残念ながら正しくありません。
robots.txt でブロックしたページが、そのまま検索結果に並んでしまう。これはGoogleの不具合でも例外的な事故でもなく、公式ドキュメントに明記されている仕様どおりの挙動です。
そして2026年7月末、この取り違えが原因とみられる出来事が世界的なニュースになりました。あるAIサービスの共有リンクが、意図せず検索結果に並んでいることが指摘されたのです。
本記事では、robots.txt と noindex がそれぞれ何をする仕組みなのかをGoogle公式ドキュメントに基づいて整理し、両者を併用すると何が起きるのかを解説します。そのうえで、中小企業のサイトで実際に起きやすい流出パターン、WordPressでの具体的な設定手順、すでに検索結果に出てしまったときの緊急対応までを、SEOコンサルティングの現場知見を交えてお伝えします。
2026年7月、共有リンクが検索結果に並んだ出来事
まずは、この話題が注目されるきっかけになった出来事から整理します。技術的にはごくありふれた設定ミスであり、だからこそ他人事ではありません。
何が起きたのか
2026年7月25日ごろから、あるAIチャットサービスの「共有リンク」が、Googleの検索結果から閲覧できる状態になっていることが海外メディアで報じられました。共有リンクとは、ユーザーが自分の会話内容を第三者に見せるために発行するURLのことです。
報道によれば、そこには履歴書や社内文書とみられる内容も含まれていたとされています。7月27日には検索結果に表示されなくなったとも報じられましたが、同日時点での設定の状態については報道の間で見解が分かれています。
ここで押さえておきたいのは、この共有リンク自体はもともと「リンクを知っている人なら誰でも見られる」仕様だったという点です。つまり、技術的には最初から公開ページでした。
問題は、運営側が検索結果に載せない意図で設定していたはずのルールが、機能していなかったことにあります。「誰にも見つからないだろう」という前提が、検索エンジンによって一瞬で崩れたわけです。
原因は「クロール拒否」と「インデックス拒否」の取り違え
Search Engine Journalが2026年7月27日に行った検証によると、該当ページは robots.txt で共有用のパスをブロックしたうえで、HTTPレスポンスヘッダーに X-Robots-Tag というインデックス拒否の指示を返していたと報告されています。一見すると二重に守っているように見える設定です。
ところが、この2つは組み合わせると打ち消し合ってしまいます。robots.txt でクロールを止めているため、検索エンジンはページの中身を取得できず、そこに書かれたインデックス拒否の指示を読むことができないからです。
なお、この件の原因については報道によって説明が異なり、そもそも指示自体が無かったとする記事もあります。ここでは特定のサービスの是非ではなく、robots.txt とインデックス拒否の指示が競合すると何が起きるのかという技術的な論点に絞って整理します。
Googleの公式ドキュメントには、この点がはっきりと書かれています。noindex を有効に機能させるには、そのページが robots.txt でブロックされておらず、クローラーがアクセスできる状態でなければならないという記述です。
そしてブロックされている場合、他のページからリンクされていればURLだけが検索結果に載る可能性がある、とも明記されています。まさに今回起きたとおりの現象です。
同じパターンは過去にも繰り返されている
この種の出来事は、今回が初めてではありません。2025年8月には別の生成AIサービスが共有チャットを検索結果から取り下げ、2023年にもチャット記録のインデックスをブロックする対応が行われています。
共通しているのは、いずれも「リンクを知っている人だけが見られる公開URL」だったという点です。発行された瞬間から、それは技術的にはインターネット上の1ページになります。
ここで特定の企業を批判する意図はありません。世界最先端の技術力を持つ組織でも起きているという事実こそが、この設定の落とし穴の深さを示しています。
中小企業のサイトにとっての教訓
「うちは大手のAIサービスではないから関係ない」と思われるかもしれません。しかし筆者が実際にサイト診断を行うと、同じ構造の設定は中小企業のサイトでも高い頻度で見つかります。
テスト環境をまるごと robots.txt でブロックしているケース、会員向けページをディレクトリごと Disallow しているケース。いずれも「クロールを止めれば検索結果からも消える」という誤解が土台にあります。
この誤解は、Web制作会社や社内のエンジニアの間でも根強く残っています。robots.txt は「検索結果に出さないための道具」ではないという一点を、まず正確に共有しておくことが出発点です。
robots.txtとnoindexは役割がまったく違う
ここからは、2つの仕組みがそれぞれ何をするものなのかを整理します。名前が似ているため混同されがちですが、担当している工程がそもそも異なります。
robots.txtは「見に来るな」という指示
robots.txt は、サイトの一番上の階層に置く小さなテキストファイルです。ここに Disallow と書いてパスを指定すると、検索エンジンのクローラー（サイトを巡回して情報を集めるプログラム）に対して「このURLは取得しないでください」と伝えられます。
つまり robots.txt が制御しているのは、あくまでクロールという工程です。サーバーへのアクセスを減らしたい、検索エンジンに巡回してほしくない領域がある、といった目的で使います。
重要なのは、robots.txt にはインデックス、つまり「検索結果に載せるかどうか」を決める力がないという点です。この工程はクロールの後に行われる別の処理であり、robots.txt の指示は届きません。
Googleは以前からこの点を繰り返し説明しています。robots.txt でブロックされたページでも、他のサイトからリンクされていれば、そのURLは検索結果に表示されうるという説明です。
noindexは「検索結果に載せるな」という指示
一方の noindex は、ページ側に書く指示です。HTMLの head 内に meta タグとして記述するか、HTTPレスポンスヘッダーに X-Robots-Tag として付ける、どちらかの方法で実装します。
Google公式ドキュメントによれば、Googlebot がそのページをクロールして noindex を読み取ると、他のサイトからリンクされているかどうかにかかわらず、そのページを検索結果から完全に除外します。ここが robots.txt との決定的な違いです。
meta タグで書く場合は、以下のような1行を head 内に置きます。全ての対応検索エンジン向けなら name に robots、Googleだけに効かせたい場合は googlebot を指定します。
<meta name="robots" content="noindex">PDFや画像など、HTMLではないファイルにも指示を出したい場合は、サーバー側でHTTPヘッダーを返す方法を使います。効果は meta タグと同じです。
X-Robots-Tag: noindex併用するとnoindexが読まれなくなる
ここまでを踏まえると、両方を同時に設定したときに何が起きるかは明快です。robots.txt がクロールを止めるため、ページの中にある noindex に検索エンジンが到達できません。
結果として、noindex は書いてあるのに機能しないという状態になります。そのうえで外部からリンクされていれば、URLとリンクテキストだけが検索結果に載ってしまいます。
Googleのマーティン・スプリット氏も、同じページに両方のルールを置くことは避けるべきだと説明しています。守りを厚くしたつもりが、実際には守りをゼロにしているという逆転が起きるためです。
この挙動は、すでにインデックスされてしまったページを消したい場面でも問題になります。慌てて robots.txt でブロックすると、かえって検索結果から消えなくなるという、直感に反する事態を招きます。
robots.txtにnoindexと書いても効かない
もうひとつ、古い情報が残っているために起きる勘違いがあります。robots.txt の中に Noindex: と書く方法です。
かつては一部で動作するとされていましたが、Googleは2019年9月1日をもってこの記述のサポートを完全に終了しています。現在の公式ドキュメントにも、robots.txt ファイルで noindex ルールを指定することはサポートしていないと明記されています。
古いブログ記事や社内マニュアルにこの方法が残っている場合は、すぐに書き換えておくことをおすすめします。書いてあっても何も起きないため、対策したつもりのまま放置されやすい記述です。
中小企業のサイトで起きやすい5つの流出パターン
ここからは、実際の診断現場でよく見つかるケースを紹介します。どれも悪意や手抜きではなく、善意の設定が裏目に出ているものばかりです。
パターン1｜テスト環境・ステージングサイトの公開
もっとも多いのがこれです。リニューアル用のテストサイトを本番と同じサーバーのサブドメインに置き、robots.txt で全体をブロックしているというケースです。
制作会社から共有されたテストURLが、社内のチャットやメールから外部に伝わり、いつのまにかどこかのページからリンクされる。すると、そのURLが検索結果に載ります。
本番公開前の価格表や、まだ社外に出していない新サービスの説明が入っていれば、そのまま情報漏えいになりかねません。テスト環境は robots.txt ではなく、Basic認証やIP制限で閉じるのが原則です。
さらに厄介なのが、公開時にテスト環境用の設定を本番に持ち込んでしまう逆パターンです。本番サイト全体に noindex が付いたまま公開され、数か月間まったく検索に出なかったという相談は、決して珍しくありません。
パターン2｜会員限定・パスワード配布ページ
取引先向けの資料ページや、セミナー参加者だけに案内するページ。「URLを知っている人だけ」という運用にしているサイトは非常に多くあります。
URLが複雑で推測されにくいことは、確かに一定の防御にはなります。しかし推測されにくいことと、発見されないことは別の話です。
参加者がそのURLを自社ブログやSNSに貼った瞬間、検索エンジンはリンクをたどってURLの存在を認識します。robots.txt でブロックしていれば中身は読まれませんが、URL自体は検索結果に出うる状態になります。
本当に見せたくない相手がいるなら、ログインまたはパスワード保護をかけてください。検索エンジン向けの指示は、あくまで検索結果の見え方を制御するものであり、アクセス制御の代わりにはなりません。
パターン3｜PDFや画像などのファイル
見落とされがちなのがPDFです。会社案内、価格表、申込書、過去の提案資料などをサーバーに置いたまま忘れている、というケースは相当な数にのぼります。
PDFはHTMLではないため、meta タグを書き込めません。noindex を効かせるには、サーバー側でHTTPヘッダーを返す設定が必要になります。
この対応が漏れているサイトでは、社内向けの資料がそのまま検索でヒットすることがあります。自社ドメインで site: 検索を行い、filetype:pdf を組み合わせて棚卸ししておくと安心です。
パターン4｜フォーム完了ページ・サンクスページ
お問い合わせ完了ページや資料ダウンロード完了ページも、検索結果に出したくないページの代表格です。ユーザーが検索から直接たどり着いても、何の役にも立ちません。
それどころか、計測用のタグが設置されていれば、コンバージョン数が実態より水増しされる原因にもなります。広告の費用対効果を判断する土台が狂ってしまうため、放置は避けたいところです。
ここは robots.txt ではなく noindex を使う場面です。クロールは許可したうえで、インデックスだけを拒否するのが正しい選択になります。
パターン5｜外部サービスが発行する共有リンク
2026年7月の出来事がまさにこれです。クラウドストレージ、資料共有ツール、オンラインホワイトボード、AIチャットなど、共有リンクを発行できるサービスは日常業務に溶け込んでいます。
これらのURLに対して、自社側でできる制御はほとんどありません。robots.txt も noindex も、そのドメインの所有者しか設定できないためです。
できることは、共有リンクを発行する対象を選ぶことと、不要になったら共有を解除することの2点に絞られます。公開の場に貼れない内容なら、共有リンクも発行しないという社内ルールを持つのが現実的です。
目的別｜正しい「見せない」設定の選び方
「見せない」という言葉には、実は3つの異なるレベルが含まれています。どのレベルを求めているかによって、選ぶべき手段は変わります。
検索結果に出したくないだけならnoindex一択
ページ自体は誰が見てもかまわないが、検索結果には表示させたくない。サンクスページ、印刷用ページ、社内向けの案内ページなどがこれにあたります。
この場合の答えは noindex だけを使うことです。robots.txt には一切書かず、クローラーが自由にアクセスできる状態を保ってください。
Googleがページを取得し、noindex を読み取り、インデックスから外す。この流れが成立して初めて、確実に検索結果から消えます。
誰にも見せたくないならアクセス制限をかける
機密資料、開発中のページ、個人情報を含むページ。これらは検索エンジン向けの指示ではなく、サーバー側で入口を閉じるのが正解です。
具体的にはBasic認証、IPアドレス制限、会員ログインのいずれかを使います。認証で保護されたページはクローラーも中身を取得できないため、内容がインデックスされることはありません。
この方法の利点は、検索エンジンだけでなく、URLを偶然知った第三者からも守れる点にあります。noindex は「検索結果に出さない」だけで、URLを知っている人のアクセスは防げません。
逆にいえば、noindex はセキュリティ対策ではないということです。ここを混同したまま運用しているサイトは非常に多く、診断のたびに指摘しています。
robots.txtを使うべき場面はどこか
ここまで読むと robots.txt が悪者のように見えるかもしれませんが、そうではありません。適した用途がきちんとあります。
代表的なのは、クロールの無駄を減らしたい場面です。検索結果に出す価値のない絞り込み検索の結果ページや、無限に生成されるパラメータ付きURLなどをブロックすることで、限られたクロールの回数を重要なページに振り向けられます。
また、サーバー負荷を抑える目的でも有効です。大量の画像や動画ファイルへのアクセスを制限したい、といった要件には robots.txt が向いています。
整理すると、robots.txt は「クロールの効率化」、noindex は「検索結果の制御」、認証は「アクセスの遮断」です。目的が違うため、代用は効きません。
AI検索やAIクローラーへの対応も同じ考え方
生成AIの学習用クローラーやAI検索向けのボットについても、基本的な構造は変わりません。robots.txt で個別のユーザーエージェントを指定してブロックする方法が広く使われています。
ただし、robots.txt はあくまで各事業者の自主的な遵守に委ねられた仕組みです。守られる前提で機密情報を置くのは危険であり、本当に見せたくないものは認証で閉じるという原則は変わりません。
また、AI検索での露出をコントロールしたい場合は、noindex やスニペット制御用の指示など、目的に合ったルールを選ぶ必要があります。ここでも「クロールを止める」と「表示を止める」の区別が出発点です。
WordPressサイトでの具体的な設定手順
ここからは、WordPressで運用しているサイトを想定した実装手順を紹介します。テーマやプラグインによって画面は多少異なりますが、考え方は共通です。
個別ページをnoindexにする
もっとも簡単なのは、SEO系プラグインの機能を使う方法です。多くのプラグインでは、投稿や固定ページの編集画面下部に検索エンジン向けの設定欄が用意されています。
そこで「検索結果に表示しない」に相当する項目をオンにすれば、そのページの head 内に noindex の meta タグが出力されます。テーマ側に同様の機能が備わっている場合もあるため、二重設定にならないよう注意してください。
プラグインを使わない場合は、テーマの functions.php で条件分岐を書き、対象ページだけに meta タグを出力する方法もあります。ただしテーマ更新で消える可能性があるため、子テーマでの実装が前提です。
サイト全体を非公開にするときの注意点
WordPressには「設定」から「表示設定」に進むと、検索エンジンでの表示を許可しないというチェックボックスがあります。制作中のサイトでよく使われる機能です。
ただしこの設定は、robots.txt での Disallow と noindex の両方を出力する挙動になることがあります。制作中は問題ありませんが、意図せず残ると本番公開後に検索結果へ出なくなるため、公開時のチェック項目に必ず入れてください。
実務でもっとも多い事故が、まさにこのチェックの外し忘れです。公開から1か月経っても検索に出ない原因の多くは、アルゴリズムではなくこの1つのチェックボックスにあります。
PDFなどのファイルに指示を出す
PDFにインデックス拒否を効かせるには、サーバー設定でHTTPヘッダーを返します。Apacheであれば .htaccess に、拡張子を条件にしたヘッダー追加の記述を加えるのが一般的です。
設定を反映したら、ブラウザの開発者ツールやコマンドラインで、実際に X-Robots-Tag が返っているかを確認してください。書いたつもりで反映されていない、というケースが少なくありません。
なお、サーバーの管理権限がない共有ホスティングでは、この設定を行えない場合があります。その場合は、そもそもファイルを公開領域に置かない運用へ切り替えるのが確実です。
設定できたかを必ず検証する
設定して終わりにせず、Googleが実際に何を受け取っているかを確認します。Search ConsoleのURL検査ツールを使えば、Googlebot がクロール時に受け取ったHTMLを表示できます。
ここに noindex の記述が含まれていれば実装は成功です。逆に robots.txt でブロックされている場合は、その旨が表示されるため、競合設定にも気づけます。
あわせて、Search Consoleのページインデックス作成レポートも確認しておきましょう。noindex によって除外されたページの一覧が確認でき、意図しないページが混ざっていないかを点検できます。
すでに検索結果に出てしまったときの緊急対応
ここからは、見せたくないページがすでに検索結果に載ってしまった場合の対応手順です。順番を間違えると、かえって消えにくくなるため注意してください。
手順1｜robots.txtのブロックを解除する
最初にやるべきは、robots.txt からそのURLの Disallow を外すことです。直感には反しますが、消すためにはまずクローラーに入ってもらう必要があります。
Googleの公式ドキュメントも、robots.txt がURLをブロックしている場合はファイルを編集してブロックを解除するよう案内しています。ここを飛ばすと、以降の手順がすべて空振りになります。
手順2｜noindexまたはアクセス制限を実装する
ブロックを外したうえで、noindex を実装します。ページの内容自体を見られたくない場合は、noindex ではなく認証をかけるか、ページを削除して404または410を返す判断も必要です。
ここで重要なのが、削除だけでは不十分な場合があるという点です。ページを消しても、検索結果にURLとタイトルが残っている期間が発生します。
手順3｜削除ツールで一時的に非表示にする
急いで検索結果から消したい場合は、Search Consoleの削除ツールを使います。申請が通ると、そのURLは検索結果から一時的に表示されなくなります。
ただしGoogle公式ヘルプによれば、これは約6か月間の一時的なブロックであり、インデックスから削除されるわけではありません。期間が過ぎれば、再び表示される可能性があります。
つまり削除ツールは時間を稼ぐための応急処置です。その6か月のうちに noindex やアクセス制限といった恒久対策を必ず完了させるという使い方をしてください。
手順4｜URL検査ツールで再クロールを依頼する
noindex は、Googleがページを再びクロールして初めて反映されます。公式ドキュメントには、ページの重要度によっては再訪までに数か月かかる場合があるとも書かれています。
そこでSearch ConsoleのURL検査ツールから、インデックス登録をリクエストします。これは登録を促す機能ですが、再クロールのきっかけとしても使われます。
反映のタイミングを正確に約束することはできません。急ぎの案件では、削除ツールと再クロール依頼を組み合わせて進めるのが現実的です。
手順5｜他の検索エンジンやキャッシュへの対応
忘れがちですが、検索エンジンはGoogleだけではありません。Bingにも同様の削除申請の仕組みがあり、必要に応じて個別に手続きが必要です。
また、公開されていた期間中に第三者が内容を保存していれば、こちらから消す手段はありません。だからこそ、出てしまってからの対応より、出さないための設計のほうが圧倒的に重要になります。
なお、個人情報の漏えいや権利侵害にあたる可能性がある場合は、対応を法的な観点からも検討する必要があります。判断に迷う内容については、弁護士など専門家にご相談ください。
再発を防ぐ社内ルールと定期点検
一度直しても、運用の中で同じ問題は繰り返し発生します。仕組みとして防げるように、チェックの型を作っておきましょう。
公開前チェックリストを作る
新規公開やリニューアルの直前に確認したい項目は、それほど多くありません。検索エンジンでの表示を許可しない設定が外れているか、robots.txt に不要な Disallow が残っていないか、この2点が最優先です。
あわせて、テスト環境のURLが本番のリンクやサイトマップに混ざっていないかも確認します。移行作業では、想定外の場所に旧環境のURLが残っていることがよくあります。
制作会社に依頼している場合でも、この確認は発注側でも行うことをおすすめします。公開当日の10分の確認が、数か月分の集客機会を守ります。
site:検索とレポートで定期的に棚卸しする
もっとも手軽な点検方法は、Google検索で site: に続けて自社ドメインを入力することです。自社サイトのどのURLが検索対象になっているかを、おおまかに一覧できます。
ここに見覚えのないURLや、テスト用のサブドメイン、古いPDFが並んでいないかを確認します。四半期に一度でも実施しておけば、事故の芽は早い段階で摘めます。
より正確に把握したい場合は、Search Consoleのページインデックス作成レポートを使います。インデックスされたページと除外されたページの内訳が確認でき、除外理由まで追えます。
共有リンクの扱いをルール化する
クラウドサービスやAIツールの共有リンクについては、技術ではなく運用で守るしかありません。社内で最低限のルールを決めておきましょう。
おすすめは、共有リンクを発行してよい情報の範囲をあらかじめ定義することです。顧客情報、契約内容、未公開の価格などは対象外とし、必要ならファイル添付や社内システムを使う運用にします。
あわせて、期限が来た共有リンクは解除する担当と頻度を決めておきます。発行しっぱなしを防ぐだけで、リスクは大きく下がります。
従業員が業務でAIツールを使う場面が増えている以上、この整理は待ったなしです。共有リンクは、発行した瞬間から公開ページと同じ扱いにする。この一文を社内ルールに加えるだけでも効果があります。
よくある質問（FAQ）
robots.txtとnoindexは併用してはいけないのですか
同じURLに対して両方を設定するのは避けてください。robots.txt でクロールを止めると noindex が読み取られず、検索結果から消えなくなるためです。
サイト内の別々のURLに対して、それぞれ適した方を使い分けるのは問題ありません。あくまで「同じページに両方」が避けるべき組み合わせです。
noindexを設定すればセキュリティ対策になりますか
なりません。noindex は検索結果への表示を止めるだけで、URLを知っている人のアクセスは防げません。
見られては困る情報を扱うページは、Basic認証やログインなどのアクセス制限で保護してください。検索エンジン向けの指示とアクセス制御は、まったく別の仕組みです。
noindexを設定してからどれくらいで消えますか
Googleがそのページを再クロールしたタイミングで反映されます。公式ドキュメントには、ページの重要度によっては数か月かかる場合があるとも記載されています。
期間を確約することはできませんが、URL検査ツールからの再クロール依頼で早まることがあります。急ぐ場合は削除ツールとの併用を検討してください。
robots.txtにNoindexと書く方法は使えますか
使えません。Googleは2019年9月1日をもって、robots.txt 内の noindex 記述のサポートを終了しています。
現在の公式ドキュメントにも、robots.txt での noindex 指定はサポートしていないと明記されています。古い手順書が社内に残っていないか確認しておきましょう。
PDFにnoindexを設定するにはどうすればよいですか
PDFにはHTMLの meta タグを書けないため、サーバーからHTTPレスポンスヘッダーとして X-Robots-Tag を返す方法を使います。効果は meta タグによる noindex と同じです。
サーバー設定を変更できない環境では、公開領域にファイルを置かない運用に切り替えるのが確実です。会員向け配布であれば、ログインの内側から配信する構成を検討してください。
サイトが検索結果にまったく出ないのですが原因は何ですか
公開直後であれば、WordPressの「検索エンジンでの表示を許可しない」設定が残っている可能性を最初に確認してください。実務ではこれが原因のケースが非常に多く見られます。
あわせて robots.txt の内容と、Search ConsoleのURL検査ツールでの表示も確認します。原因の切り分けができない場合は、専門家に診断を依頼するのが早道です。
まとめ｜「隠す」には3つのレベルがある
本記事の要点を整理します。robots.txt はクロールを止める仕組みであり、検索結果への表示を止める力はありません。
検索結果に出したくないなら noindex を使い、robots.txt では絶対にブロックしないこと。Google公式ドキュメントも、noindex が機能するにはページがブロックされていないことが必須だと明記しています。
そして、誰にも見せたくない情報はアクセス制限で守ること。noindex はセキュリティ対策ではなく、あくまで検索結果の見え方を制御する仕組みです。
2026年7月の出来事が示したのは、この区別があいまいなまま運用すると、意図しない情報が検索結果に並ぶということでした。クロールを止める・表示を止める・アクセスを止める、この3つを使い分けるのが、正しい設計の出発点です。
まずは自社サイトで site: 検索を実行し、見覚えのないURLや古いPDFが並んでいないかを確認してみてください。あわせてSearch Consoleのページインデックス作成レポートを開けば、いま何が検索対象になっているかを把握できます。
インデックス制御の点検・改善はアクセス・リンクへ
株式会社アクセス・リンクでは、全日本SEO協会認定SEOコンサルタントの資格を持つ代表・三田健司が、企業サイトのSEOコンサルティングとWordPressサイト制作を手がけています。Web制作歴は10年以上、延べ1,000件以上のサイトに携わってきました。
「検索結果に出したくないページが出てしまっている」「公開したのに検索に出てこない」「robots.txt の中身が正しいか判断できない」といったご相談に対応しています。現状の診断から実装、公開前チェックの仕組みづくりまでまとめてご支援いたします。
まずは現状の課題をお聞かせください。お問い合わせフォームからお気軽にご連絡いただけます。
記事執筆・株式会社アクセス・リンク 代表取締役
Webサイト制作歴10年以上の経験を元にSEOコンサルティングを行い、延べ1,000件以上のサポート実績を誇ります。個人事業主や中小企業向けのホームページ制作やSEOコンサルティングを得意としています。
（社）全日本SEO協会 認定SEOコンサルタント
コメント