タグ検索:web制作

Googleの検索結果に、「#○○ を含む投稿」というWebサイトやSNSを横断した、ハッシュタグの検索結果を表示する機能が実装された様です。SNSのヘビーユーザーの多くは、検索をする際にも普段愛用しているSNSから直接検索をするユーザーが多い様ですが、今回の機能追加でWebサイトや各種SNSを含め、一度の検索で幅広く情報収集が出来る様になりますので、便利に感じるユーザーも多いのではないでしょうか。

検索時に「#〇〇〇〇〇」と検索するだけ

Google検索時の文字列の頭に「#」(ハッシュ)をつけて検索するだけで、ハッシュタグに絞った検索結果を表示することができます。
ハッシュタグというと一般的には「X」「Instagram」「Youtube」「TikTok」「note」などのSNSを思い浮かべますが、自社サイトや自社ブログなどのオリジナルコンテンツも検索対象になる様です。
但しブログなどでハッシュタグとして運用されていても、表示上で頭に「#」がないものに関しては、ハッシュタグとして認識をしていない様ですので、検索対象に含めたい場合は「#」を付与する必要がありそうです。(実際のタグキーワード自体には「#」は不要ですが、表示上「#」が必要の様です)

・Google Japan Blog(Google 検索の便利な新機能のご紹介)
https://blog.google/intl/ja-jp/products/explore-get-answers/search-japan-nowcast-hashtag/

自社のWebサイトやブログにもハッシュタグに「#」をつけよう

自社Webサイトの制作時はもちろんですが、すでに運用しているWebサイトでもハッシュタグを利用している場合には、「#」を付けた方が望ましいということなのだと思いますので、可能であれば改修されてはいかがでしょうか。
今回のGoogleの機能追加を踏まえ、当サイトもハッシュタグの表示には「#」を付けて運用することにしました。従来ハッシュタグはそのWebサイト内での運用が前提のものが多いと思いため、システム的に「#」が無い状態で運用をされているケースもあると思います。もしご自身のWebサイトのハッシュタグの表示に「#」がない場合は、表示部分をカスタマイズして「#」を付けることをお勧めいたします。

最後に

今回の様にGoogleも細かく仕様が変更されておりますので、Webサイトを日々見直しながら世の中の動きに対応したものへ成長させていく事が大切です。弊社が運用するa-blog cmsでは、今回の様な細かな改善もコストを抑えた実現が可能です。
長期運用に対応可能なパフォーマンスの高いWebサイトに興味がございましたら、ぜひお気軽にお問い合わせください。


Google検索結果一覧でWebページの情報のそれぞれ1行目に「サイト名」が表示されている部分がありますが、こちらの表記が指定されている場合とドメインが表示されている場合があります。
SEO的には順位に影響はないと思われますが、検索をした際に伝わりやすい「サイト名」の方が、クリック率が上がる可能性がありますし、サイト名の下にはURLが記載されるため情報として重複しており「出来れば変更したい」とご相談いただく事があります。
そこで今回は「サイト名」の表示を指定する方法を考えてみました。

サイト名を決めるコツ

サイト名を変更するためには、まずサイト名を決定する必要があります。
Google検索セントラルを確認すると、サイト名の命名にはいくつかのポイントがありますが、サイト名はメタで指定されるページごとの<title>などとは違い、ひとつのサイトで共通のものになりますので、基本的には簡潔にサイト全体を表すものにする必要があります。

サイト命名時のポイント

  • ユーザーの誤解を招くことのない、独自性のある名前
  • 一般に認知されている簡潔な名前
  • 一般的な名称は使用しない(例/NG:「名古屋のWeb制作会社アイデアソース」 OK:「アイデアソース」)
  • ホームページ全体で一貫したサイト名にする
  • 代替名(alternateName/こちらは推奨です)

より詳細を知りたい方は、下記のGoogle検索セントラルをご確認ください。

・Google 検索に対してサイト名を指定する
https://developers.google.com/search/docs/appearance/site-names?hl=ja

決定したサイト名を指定する

Google検索セントラルを確認すると、Webサイト上で指定をする場合は構造化データを使うことが推奨されていますので、今回は構造化データを使って指定をしていきます。
サイト名を決める際に簡潔にとお伝えしましたが、このサイト名の部分が「name」になります。例えば「name」に「名古屋のWeb制作会社アイデアソース」と入れてみたところ、検索結果のサイト名には反映されませんでしたが、簡潔に「アイデアソース」としたところ無事反映されました。もし反映されずに悩んでいる方がみえましたら、欲張らずに簡潔にサイトを表す名称で指定されることをお勧めいたします。

構造化データの記述例

<!-- alternateNameは推奨/複数可 -->
<script type="application/ld+json">
{
	"@context" : "https://schema.org",
	"@type" : "WebSite",
	"name" : "アイデアソース",
	"alternateName" : ["IDEASOURCE", "ID"],
	"url" : "https://www.ideasource.jp/"
}
</script>

また、こちらの構造化データがないWebサイトの場合は、GoogleがWebサイトの情報(「og:site_name」「<title>」「見出し・内容」など)から総合的に判断している様です。

気をつけていただくポイント

サイト名の指定は、あくまでWebサイト側がGoogleに対して希望をするだけで、残念ながら必ずしもその内容が反映される訳ではない様です。もし指定をしても反映されない場合は、サイト名の見直しや、サイト全体としてそのサイト名が正しいとGoogleに判断される様に、Webサイト全体を調整する必要があるかもしれません。

また、今回利用した「Website」構造化データは「リッチリザルト」ではないため、リッチリザルトテストでは「アイテムが検出されませんでした」という結果になるかもしれませんが、特に問題はありませんのでそのままご利用いただいて大丈夫だと思います。

最後に

細かな対策事例ではありますが、検索結果でWebサイトを分かりやすく伝えるための手段として、ご紹介させていただきました。
頑張ってSEOで上位表示されても、クリックされなければWebサイトを見ていただくことは出来ません。こちらのサイト名表記を改善することで、少しでもクリック率を底上げする事ができれば嬉しいですね。同じ順位でも100回クリックされるより200回クリックされた方が良いですから、クリック数を増やすためのひとつの対策としてご検討いただければ幸いです。


Webサイトを運用していると、システムのバージョンアップや掲載内容の改修、またはサーバの移設など、様々なケースでWebサイトを一時的にメンテナンス画面に切り替え、運用を停止しなくてはいけない場面に遭遇します。理想的にはWebサイトの運用を止めずに、スムーズにメンテナンス作業が完了することが望ましいのですが、現実的には難しい場合が多々あります。

メンテナンスページを設ける方法として、一般的にはルート階層にメンテナンス内容を記載したファイル(index.htmlなど)を設置して、あとは.htaccessでリダイレクトをかけるなど、割とざっくりと対応しているケースもある様ですが、検索エンジンのクローラーが回ってきた場合に意図しない判断をされてしまう可能性があるため、正しい方法でメンテナンス画面を用意することが推奨されています。

.htaccessで503ページを用意する

Google検索セントラルを確認すると、「サイトのダウンタイムへの対処の仕方」には、下記の様に「503」を利用することが推奨されております。503を使うことによりGoogleにメンテナンス中であることが伝わるため、インデックスなどに影響が出る事もない様です。SEOを重要視されているWebサイトにとってインデックスは非常に重要ですので、Googleの推奨される方法で実装されることをお勧めいたします。

・サイトのダウンタイムへの対処の仕方
https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime?hl=ja

ページのリクエストに対して、HTTP ステータス コード 404 (Not Found) を返したり、エラー ページを表示しているのに 200 (OK) を返したりする方法は、ダウン タイムへの対処法としてお勧めできません。それよりも、HTTP ステータス コードとして 503 (Service Unavailable) を返すように設定した方が、検索エンジンのクローラに対してダウン タイムが一時的であることを伝えることができます

503でリダイレクトをかける場合、一般的にはhtmlを設置するroot階層の.htaccessに下記の様な記述で対応します。
(サーバの仕様により書き方が変わる場合がありますので、実施にはご利用中のサーバに合わせて記述してください)

#root階層にmaintenance.html(メンテナンスページ)を設置する場合
#自分のIPを除外する場合はIP箇所のコメントアウトを外してIPを設定してください
ErrorDocument 503 /maintenance.html
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} !/maintenance.html
#RewriteCond %{REMOTE_ADDR} !=000.000.00.00
RewriteCond %{REQUEST_FILENAME} !^(.*)\.(jpg|png|css)$
RewriteRule ^.*$ - [R=503,L]
</IfModule>

#メンテナンス終了予定日時
<IfModule mod_headers.c>
Header set Retry-After "Fri, 5 July 2024 7:00:00 GMT"
</IfModule>

a-blog cmsならシステムに503ページが用意されています



a-blog cmsには「管理ページ」のダッシュボードに、メンテナンス画面に切り替える機能が備わっております。
こちらからモードを切り替える事で「503」ページに転送できますので、簡単に切り替えが可能です。
503ページの内容を変更したい場合は、あらかじめ作成した503.htmlをサーバのhtmlを設置するroot階層にアップロードしておく必要がありますのでご注意ください。(root階層にファイルがない場合は、a-blog cmsが用意した定型のメンテナンスページが表示されます)

CPIは503が利用できないらしい

今回メンテナンスページを表示するサーバがCPIだったのですが、調べたところCPIでは.htaccessの503エラーの操作についてサーバ側で制限がかかっており、ユーザー側では503用ページを設定することが出来ない事が分かりました。
CPIでメンテナンスページを表示する場合は、302のリダイレクトなどでメンテナンスページへ転送するなど、他の手段を使う必要があるようですのでご注意ください。

・CPI .htaccess の設定方法
https://developers.google.com/search/blog/2011/01/how-to-deal-with-planned-site-downtime?hl=ja

この様に.htaccessに制限がかかっている場合もありますので、ご利用のサーバを事前に調べておくことをお勧めいたします。

#CPIでサイト全体のアクセスをmaintenance.htmlに302リダイレクトをする場合
#root階層にmaintenance.html(メンテナンスページ)を設置
Options +SymLinksIfOwnerMatch
RewriteEngine On
RewriteCond %{REQUEST_URI} !/maintenance.html$
RewriteRule ^(.*)$ /maintenance.html [R=302,L]

最後に

メンテナンスページを表示するという単純な作業が、思わぬところで「Googleからのインデックスを削除されてしまう」場合があると思うだけでドキッとします。メンテナンス中は時間との戦いです。メンテナンス自体の作業に追われ余裕がない事も多いと思いますので、ぜひ事前にしっかりと準備をして、心に余裕をもって対応されることをお勧めいたします。(自分自身への忠告も込めて…)

メンテナンスページ自体は人が見るだけですが、その裏でWebサイトの評価を落とさない様に、この様な情報を頭の片隅にでも覚えておいていただければ幸いです。


以前こちらのブログ「名古屋のWeb制作会社としてもうすぐ15年になります」でも書きましたが、本日2024年7月1日で創業15年が経ち、16期目がスタートいたしました。

2007年に名古屋のWeb制作事業者として個人事業主で創業し、2年後の2009年に法人化して現在に至ります。
これもお取引いただいているお客様をはじめ、仲良くさせていただいている方、そして弊社のスタッフや関係者の方など、皆様のお力添えがあり続けてこられたのだと思います。本当にありがとうございます。

移り変わりの早いWeb業界

弊社の主な営業品目として企業様の「Webサイト制作」があります。
主に企業のコーポレートサイトを制作させていただく事が多いのですが、店舗・医院・協会、イベント・キャンペーンサイトなど様々な種類のWebサイトを制作してきました。

最近ではAI化の流れも進んでおり、弊社でも少しずつAIで対応可能な部分は作業に導入していたりします。まだまだ未知数なところもありますが、この流れは避けられないものだと思いますので、効率よく利用しお客様の利益につながる様に、上手く利用できればと思っています。(と言いましても、まだ単純な作業をAIに置き換えて検証をしている様な状態ですが…)

創業当時のWeb業界のことを思い出してみますと、企業にWebサイトがあることは当たり前の世の中でした。次の段階としてcmsを導入し「簡単・便利にWebサイトを更新できる様にして、Webサイトを通してユーザーや顧客に訴求しましょう」という流れだった様に思います。TwitterなどのSNSはもちろんありましたが、まだアカウントを持って運用をしているのは個人が多く、企業がSNSで発信をしているケースは少なかった記憶がありますので、企業がWeb上で情報発信する際には、自社のWebサイトを活用するという感じでした。

スマートフォンもまだiPhoneが出た頃(日本ではiPhone 3Gが2008年に登場しました)で、トレンドに敏感な周りの方がガラケーからiPhoneへ乗り換えている頃でした。そんな時代ですので、WebサイトもメインはPCサイトで一緒に携帯サイトを作るという感じで、PCでのIEハック(IEでのレイアウト崩れを防ぐ処理)なども主流でした。思い出すと懐かしくなりますね…。そんな時に現れた救世主が「jQuery」でした。ブラウザの差異を吸収してくれる優れもので、jsでのフロントエンドの実装が急展開で進むきっかけになった様に思います。

SEOも以前はキーワード文字を詰め込み、外部サイトで大量に被リンクを稼ぐ様な方法が主流で、現在ではNGになる様な杜撰な対策がメインでした。弊社はその様なSEO対策は受け入れられず、当時のSEO対策については一切お引き受けすることはございませんでした。ただ、SEOは本当にこの15年でまともになり、Web制作の現場として納得をして実装が出来る非常に良い環境になりましたので、今は積極的にSEOのご相談も承っております。

そういえば、個人的にはこの頃からWebサイトを作る際のコーディングにはエディターしか使わなくなりました。
2000年頃はhtmlのレイアウトはテーブル組みが主流だったため、その流れでDWなどのソフトを使っていましたが、2009年頃からはほぼエディターだけでhtml/css/jsなどは済ませています。

Webサイトに求められるものや、作り方自体も変わっていますので、変わったことを言い出すとキリがないのですが、この様に変化の流れが早いWeb業界で生き残っていく為に、これからも日々精進していきたいと思います。

近くの御器所神社さんへお礼に

15年間のお礼と今期1年良いお仕事ができます様にと、職場近くの御器所神社さんへ参拝に行ってきました。
初心忘れずまた1年頑張ろうと思います。


御器所神社さんの外観

最後に

懐かしい話も出ましたが…変化の早いWeb業界だからこそ、時代のニーズを捉えながらチャンレンジし、私たちを選んでいただいたお客様に喜んでいただける様に、結果の出る成果物を求めていきたいと思います。良いご提案ができる様に、新しい取り組みや検証なども頑張ってまいりますので、今後ともどうぞ宜しくお願いいたします。


自社Webサイトやお客様のWebサイトなど、弊社では複数のWebサイトのSEOランキングを日々計測しています。
当たり前ですが、どのWebサイトもサイト構成やデザイン、掲載内容、更新頻度、Core Web Bitals の対策具合は異なっています。

もちろん一番良いのは、a-blog cms(CMS)を常に最新にして、サーバ環境も最新に(または定期的に見直し)、Core Web Bitalsを改善しつつ諸々の対策、そして何よりしっかりと目的を持って定期的にWebサイトを更新をしていただく事です。これが一番効果が出ますし、日々の更新の中で常に改善が出来ますので、実際のビジネスのスピードに合わせたWebサイトの運営ができ、検索順位だけでなくユーザーにとっても有益なWebサイトになります。

ただ、複数管理させていただいているWebサイトの中には、普段あまり更新をしないWebサイト(年に数回程度)もあります。そんな普段更新をしないWebサイトでも、下記の対策を行ったことで順位が改善しているものがあります。

SEOの改善に行った対策

  • a-blog cmsを最新版にバージョンアップ
  • 最新サーバに乗り換え
  • PHPを8.x以降に(できればPHP8.3)/PHP関連の各メモリ割り当てを増加(できれば2G程度)
  • a-blog cmsとサーバのキャッシュ関連の適切な設定
  • Core Web Bitalsを改善
  • 構造化データの導入・見直し
  • Search Consoleの情報を元に「インデックス/重複/canonical」などの調整

Webサイトの基礎が活きる

サイトごとに狙うキーワードのシェアや競合サイトなども違いますし、サイト自体のGoogleの評価も変わってきますので一概には言えませんが、サーバの環境やWebサイト構造など、Webサイトの基礎の部分を見直し改善すると、あまりサイトを更新していなくても一定の評価が上がると感じています。

上記の様な見直しや改善は、全て結果的にWebサイトのパフォーマンスやセキュリティなどの向上につながります。パフォーマンスやセキュリティの改善は、効果があることをGoogleも公表していますが、日々実測していると経過が分かりますので非常に面白いです。

また、Core Web Bitalsにはユーザービリティやアクセシビリティに関する項目もあるため、例えSEO目的の対策であったとしても、結果的にはWebサイトやそのユーザーに対して非常に有益な施策だと言えると思います。

Core Web Bitalsに関しては以前にも「Web制作会社がおこなうSEO施策とCore Web Bitalsの改善」「SEOとは「UXを高めていく事」という時代になったのだと思う」で書いておりますので、興味がある方はぜひご覧ください。

最後に

もしSEOで検索順位を上げたくても効果が出ない場合は、ぜひこの辺りの改善も視野に入れてみてはいかがでしょうか。
Webサイトやサーバが数年前の環境のままでしたら、改善はしても悪くなることはないと思います。
上記の施策だけでしたら、Webサイトに掲載している内容に変更を加えませんので、この施策で順位が悪化することはないと思いますので、評価を全体的に底上げする意味でも効果的だと思います。

a-blog cmsでのWebサイト運用にはノウハウもございますので、「Webサイトが見てもらえない」など、Webサイトの効果に疑問を感じたり、何かWebサイトの事でお困りでしたら、是非お気軽にご相談ください。