AIものさし

SEOの技術課題を見つける方法｜Semrushでサイト監査する流れ

Semrush Site Auditは、指定した範囲をcrawlerで確認し、見つかったtechnical issueを整理する診断ツールです。最初に決めるのは「Health Scoreを上げること」ではなく、どのURL群を、何ページ、どのcrawler条件で確認し、発見事項を誰がどう直すかです。

AIものさし編集部

Semrush Site Auditは、指定した範囲をcrawlerで確認し、見つかったtechnical issueを整理する診断ツールです。最初に決めるのは「Health Scoreを上げること」ではなく、どのURL群を、何ページ、どのcrawler条件で確認し、発見事項を誰がどう直すかです。公式マニュアルでは、domain/subdomain/subfolderのscope、Website・robots.txt sitemap・URL指定sitemap・URL file importなどのcrawl source、user agentやcrawl delayを設定できます。設定を誤ると重要ページを見落としたり、関係ないURLが大量に含まれたりします。

目次

Crawl前に監査対象を定義する

開始前に、目的を「商品ページのindex阻害を調べる」「移行後の主要Guideだけを再確認する」など一つに絞ります。次に対象hostとpath、国・端末、認証の要否、crawl上限、サイト側の負荷を記録します。

表は横にスクロールできます

決める項目確認内容誤設定時のリスク
Scopedomain / subdomain / subfolder対象外環境や別サイトまでcrawl
Crawl sourceWebsite、robots sitemap、URL、file import重要URLが発見されない
Page limit契約と監査目的に合う数上限到達後のURLが未検査
User agentMobile / Desktop等見たい表示条件と異なる
Crawl delay標準か低速かサイト負荷が不要に上がる
Exclusionsparameter、不要pathduplicate URLで件数が膨らむ

Semrushの公式設定ヘルプでは、scopeをdomain全体ではなくsubdomainやsubfolderへ絞る例が示されています。またWebsite crawlはホームページからリンクをたどるため、重要度順にページを選ぶ方法ではありません。sitemapやURL file importは、既知の重要URLを対象にしたいときの選択肢です。機能上限は契約で変わるので、記事に固定数を埋めず現在のProject設定と契約画面を確認してください。

最初のcrawl後は「件数」ではなくURLを確認

crawl完了後は総URL数を想定と比べます。対象より極端に多ければ、parameter、検索結果ページ、pagination、別subdomainが混入していないか確認します。少なすぎる場合はrobots、認証、リンク発見、sitemap読み込み、page limitを調べます。上限へ到達した場合は「全サイトを検査した」と扱わず、未検査範囲を記録します。

必要に応じて設定を変えて再crawlします。再crawlは計測条件が変わったことを記録し、前回と同じreportとして単純比較しないでください。特にcrawl source、user agent、limitを変更すると、検出URL集合が変わる可能性があります。

Issueを実害と修正可能性で選別する

Semrush Issues reportは検出事項をErrors、Warnings、Noticesへ分け、各issueの該当URL数や推移を表示します。公式の説明ではErrorsがもっとも深刻な区分、Warningsは中程度、Noticesは比較的軽く、NoticesはSite Health Scoreへ影響しないとされています。ただしseverityはサイト固有の被害を確定するものではありません。自サイトの重要URLと実際のHTTP・HTML・Search Console状況を確認します。

表は横にスクロールできます

観点優先度を上げる例確認方法
到達性重要URLがcrawl不能ブラウザ/HTTPでroute確認
Indexability意図しないnoindex、誤canonicalHTML head、robots、canonical
範囲多数の重要pageに同一異常対象URL一覧とtemplate確認
利用者影響表示や操作ができない実ページを確認
修正リスクredirect・robots等の広域変更stagingと代表URLで検証
軽微な最適化重要度の低いNotice後回しまたは記録のみ

AIものさしの判断では、Errorラベルだけで一括修正せず、URLの重要度×影響範囲×根拠×修正リスクを組み合わせます。スコア改善のために有効な設定を変えたり、無関係なissueを大量に隠したりしません。

直す前にIssueの実体を再現する

  1. issue詳細を開き、該当URL・検出内容・Semrushの説明を確認。

  2. 同じURLをブラウザまたはHTTPで開き、現在も再現するか確認。

  3. 影響ページが同じtemplateか、個別コンテンツかを分類。

  4. 原因が自サイトの制御か、crawler制限・誤検出かを切り分け。

  5. 修正案、rollback方法、影響routeを短く記録。

  6. 修正可能な代表URLで先に直し、再crawlで消えたことを確かめる。

Crawlerが見るHTMLとJavaScript実行後の画面は一致しない場合があります。公式設定ではJS renderingを有効にできる契約条件が示されています。JS renderingが使えない場合、画面上は見える内容の不検出を直ちにSEO問題と断定せず、HTML・Search Console・別の検査手段を照合します。

失敗を原因別に切り分ける

表は横にスクロールできます

症状原因候補次の確認
crawlページが想定より少ないsitemap未指定、robots、認証、page limitcrawl logと発見source
対象外URLが多数scope広すぎ、parameter、別subdomainallow/disallowとURL一覧
Audit自体が失敗serverがSiteAuditBotを拒否サーバーlog、bot許可条件
JS部分のissueが不安定HTML-only crawl、JS rendering差rendering設定と静的HTML
Warningが減らないtemplate共通原因、再crawl未実施影響URL群と最新crawl日時
Scoreだけ改善しない非対象noticeや重みの影響issue別の実害を優先

Semrush公式設定にはcrawler user agentやcrawl delay、robots.txt、認証が必要な領域の扱いが記載されています。サーバー側設定を変更する場合は、監査ツールの結果だけでなくアクセスログとサイト運用者の承認を使います。crawlを許可するための変更が本番負荷やsecurityを損なうなら、実施しません。

修正後の受入条件

再crawl後、issueが消えたかだけで終わらず、対象の代表URLを再確認します。

  • URLがHTTP 200または意図したstatusを返す。

  • canonicalが正しいhostとURLを指す。

  • robots/noindexが意図どおり。

  • CSS・JSなど必要resourceが読み込まれる。

  • 重要ページがscope内で検査された。

  • 修正前後で対象URL・crawl条件が記録されている。

  • Search Console等、別の実測データと矛盾しない。

Site Healthは診断の補助であり、検索順位やtrafficの保証ではありません。修正した内容、未解決issue、保留理由、次回crawl日を残します。

AIものさしの判断

Site Auditはissueをゼロにするためではなく、重要URLの到達・index・利用を妨げる問題を見つけるために使います。まずscopeとcrawl sourceを決め、URL集合を確認し、実害のあるissueから検証して直します。scoreだけを追わず、修正後も実ページ・canonical・robotsを照合してください。

監査結果を修正依頼へ変換する

Issue一覧をそのまま開発者へ渡すと、原因の異なるURLがひとまとめになり、危険な一括修正につながります。各Issueについて少なくとも「該当URL、再現結果、影響範囲、期待状態、修正担当、検証方法」を記録します。

チケット例（架空）

  • Issue: 重要Guideのcanonicalが別hostを指す

  • 対象: 代表URLと同じtemplateを使うページ

  • 再現: HTML headを確認し、実際のURLとcanonicalを比較

  • 期待: 承認済みのcanonical contractに一致

  • 修正: template責任者がstagingで変更

  • QA: representative route、sitemap、redirect、Search Consoleの順に再確認

  • 停止条件: 既存URLやindexabilityを広範囲に変える必要がある

これは作業記録の例で、特定サイトの実測Issueではありません。

Crawl結果を次の監査へ活かす

Site Auditのreportを保存するときは、crawl日、scope、source、user agent、page limit、render設定、除外pathを一緒に残します。次回に同じ条件で実行できない場合は、単純な件数差を改善・悪化として報告しません。再crawl後にissueが残っていても、実ページでは解消済みならcrawler条件やcacheを調べます。反対にissueが消えても、URLがcrawl対象から外れただけでないか確認します。

サイトの変更が大きい場合、全件crawlより先に、代表ページと重要templateを選んだ限定auditを実施し、問題の範囲を把握してから全体へ広げる方法があります。これはcrawl limitを避けるだけでなく、誤った共通修正を防ぐためです。

確認日：2026-10-10