当サイトは運営から11年目になるところですが、今回はSearch Consoleを使用してみることにしました。
当ドメインを取得した2010年当時、いわゆる中古ドメインが流行しておりまして、SEO対策上のメリットがあるとのことで使用していたのですが、現在では逆にこの中古ドメインが悪影響を及ぼしていると感じています。
もしかすると前所有者のバックリンクが残っているのではないかと感じており、まずはサイトの状態を確認するためにSearch Consoleに登録してみました。
バックリンクを確認してみたところ、合計で20本程度でしょうか、前運営者の被リンクが残っていたため、これらは全て否認ツールでリンク無しの状態にしました。
10年ほど更新していたものの、思っていたほどのアクセスはなく、がっかりしてしまいましたが、ただ単に更新するだけではアクセス数は増えていかないようです。
また、Google Analyticsもあるようなので、次はそちらの方も利用してみたいと思います。
当サイトでは第１回、第２回とアクティブビューの向上に努めて参りましたが、シリーズ第３回目となる本日は最近話題のコアウェブバイタルの視点から視認率の向上にトライしてみようと思います。
■前回までの取り組みの様子
第１回（ロゴ縮小による施策）
第２回（ページ分割よる施策）
第３回（広告掲載数の削減による施策）
コアウェブバイタルにはLCPの指標がありますが、こちらはサイトの高速表示を測定する指標であり、2.5秒以下が良好とされています。
つまり、ファーストビューでの最大コンテンツがレンダリングされるまでの時間が速ければ速いほどよいわけですが、非同期の広告についてはワンテンポ遅れて表示されるケースが多いです。
特に、ヘッダー部分の広告については、表示されるまでにユーザーがコンテンツ部分へとスクロールしてしまい、実際には視認されていないケースが多いです。そのため、一番目立つヘッダー部分だからといって視認率が高いわけではありません。
このユーザーのスクロールの動作を考慮に入れた場合、ファーストビューの最下部に配置し、ページにアクセスした際に広告の頭がちらっと見える程度の配置がもっとも視認率が高くなる傾向があります。
ただし、ヘッダー部分についても広告が瞬時に表示される場合には逆にアクティブビューが高くなります。
そして、この「広告が瞬時に表示される」ためには、広告スクリプトのダウンロードサイズが小さければ小さいほどよいわけですが、広告の掲載数を少なくするのもひとつの方法です。
特に、視認率の低い、あまり見られていない広告については、掲載していても意味がないため、ダウンロードサイズを抑えるためにも削除してしまうことをおすすめします。
広告の掲載数を削除することで表示スピードが改善され、視認率が向上すれば、広告単価が上がることにより、収益の向上が見込まれるかもしれません。
以前までGoogleのサイト内検索を利用していたのですが、新しくリニューアルされたためか表示がおかしくなっていたので、自分でカスタマイズしてみました。
カスタムサーチのデザインを変更する際、HTMLフォームを利用してカスタマイズする方法が一般的かと思いますが、今回はJavascriptタイプのサイト内検索をCSSでカスタマイズしています。
このカスタマイズ方法についてですが、Chromeのデベロッパーツールなどでカスタム検索のID要素などを調べ、サイトのCSSで表示を調整するという方法です。
ただ、カスタム検索のデフォルトのスタイルがHTMLタグに直で記述されているため、サイトのCSSに記載するだけでは上書きされません。スタイル適用の優先度はHTMLタグに直接記載したstyle属性の方が高いため、CSSに記述した内容は適用されないからです。
そのため、わたくしはCSSに「!important」を多用して強制的に上書きしてみましたが、この方法でうまくいきました。
あくまで参考までになりますが、CSSを以下のようにカスタマイズしてみました。
検索結果をサイト内で表示するか、それともGoogleにするかで１行目などのコードが違いますが、おおむね、以下のような感じでカスタマイズしていけばよいと思います。
.gsc-control-cse {padding: 0 !important;}
table.gsc-search-box {border-left: none !important;border-top: none !important;}
table#gs_id50 {border-left: none !important;border-top: none !important;}
table.gsc-search-box td {border-right: none !important;border-bottom: none !important;}
.gsc-search-button-v2 {border-color: #ccc !important;background-color: #666 !important;}
わたしがやったのは、ボーダーをなくし、検索ボタンを白黒にしてシンプルな形で表示しましたが、ほかにもボーダーを丸くしたりするとよいかもしれません。
新しいタイプのサイト内検索の方がGoogleのブランドロゴがかっこいいため、最新のものを使用してカスタマイズした方が良いかと思います。ちなみに、ブランドロゴは必ず表示しなければならないため、デフォルトの「ENHANCED BY Google」の表示を消すのはＮＧになります。
また、アドセンスのサイト内検索で収益化している場合、カスタマイズによって規約違反になってしまうのかは不明ですので、通常の一般的なカスタム検索を利用されることをおすすめします。
自サイトではレスポンシブウェブデザインやHTTPSには対応しているものの、新しい技術である「AMP化」や「構造化データ」には対応していないため、今年はこの二つに対応しようと取り組んでいます。
そこで、ざっくりテストしてみたのですが、AMP化についてはルーチン化された単純作業が多いため、比較的取り掛かりやすいのですが、構造化データはページごとに個別の対応が必要になるため、かなり時間がかかる印象を感じました。
そのため、まずはサイトをAMPに対応しつつ、AMPへの対応が終わったら構造化データ化に着手するのが最善と思います。
そもそも、このAMPと構造化データの違いについてですが、AMPについてはモバイル環境での高速化のための技術であり、一方の構造化データについてはセマンティックウェブの仕組みであるため、根本的には全く違う技術になります。
AMPはGoogleのサーバーを使用することに加え、ランディングページをキャッシュで表示させるため、モバイル環境でも高速なウェブ表示が可能になる技術です。
一方、構造化データについては、セマンティックにコンテンツの意味を伝えるものになります。
例えば、チーズケーキの記事を公開した際、それがチーズケーキのレシピを意味するものなのか、喫茶店でのメニューを意味するものか、あるいはお取り寄せグルメの商品を意味するものか、検索エンジンが判断できないわけではないとは思いますが、判断がしにくいです。
その際、「レシピ」の構造化データを取り入れると、明確に一義的に「レシピ」のコンテンツであることを訪問者に伝えることができるメリットがあります。
どちらかといえば、AMPよりも構造化データの方が重要度が高い気もしますが、最近ではどちらもマストSEOの必須の要素であるため、両方に対応しておくとよいでしょう。
また、実際に書く際の順序はどちらが先かについてですが、某大手サイトのHTMLソースを確認してみると、「構造化データのjson」→「amp-customのCSS」→「styleのボイラープレート」→「ampの定型文」の順序になっていました。
そのため、構造化データについてはAMPよりも前に記載しておくことをおすすめします。
レスポンシブウェブデザインが登場し始めた頃、当初はPCサイトが主体でモバイルは副次的な扱いでした。そのため、まずはPCサイト用のCSSを先に記述し、その後ろの方でメディアクエリを使ってモバイル専用のCSSを記述する書き方だったと思います。
その後、モバイルユーザーが急増し、今やネットにアクセスする割合の半分程度がモバイル経由になってきています。
そのため、Googleでのインデックスもモバイルファーストとなり、現在ではモバイル版のページが主体になりました。これに伴い、CSSの記述についても、PC版を先に書くのではなく、モバイル版のCSSから書き始めるのがよいと考えています。
このCSSを書き変えるコツについてですが、まずはスマホ用の最小の「モバイル版のCSSのみ」を単体で完成してしまうことをおすすめします。
その次に「PC用のCSS」も単体で完成してしまうことをおすすめします。おそらく、このPC用については現在のCSSがそのまま使えるはずです。
次に、この二つを合体させて両方を併用して記載しておけばよいでしょう。
個人的にはスマホ用の記述を上書きするような書き方はしたくないため、それぞれを独立させた形で記載することにしています。
例えば、以下のように記述していたとします。
h1 {font-size:18px;}
@media screen and (min-width:481px) {h1 {font-size:28px;}}
この場合、スマホでアクセスした場合にはフォントサイズの18pxが適用され、PCからアクセスした場合には18pxが上書きされて28pxが適用されます。
個人的にはこのような上書きはしたくないため、以下のようにそれぞれを独立して書くことにしています。
@media screen and (max-width:480px) {h1 {font-size:18px;}}
@media screen and (min-width:481px) {h1 {font-size:28px;}}
もともとブラウザのデフォルトのCSSがあるため、どのみち上書きされることに変わりはありませんが、あまりコロコロ変わるようだとスマートではありません。
CSSの記述が多少長くなるよりも、ブラウザ側で再計算する必要がないように書く配慮が必要かと思います。おそらくは最終的に計算された結果、レンダリングが開始されるはずなので、そう大した違いはないかと思いますが、できるだけシンプルに記述することをおすすめします。
保有ドメインをオークションサイトで出品しているのですが、中には評価額が数十万円を超えるものもいくつかあり、どのくらいで売れるのだろうかと楽しみにしています。
最近はビットコインが高騰して話題になっていますが、個人的にはドメインの方が実用性がありますし、よほど価値があると感じています。
ビットコインバブルのようにドメインバブルもやってこないかなと考えていますが、売れなければ売れないでそのまま保有して気長に出品するのが一番良いと思います。
４文字ドットコム、４文字orgなども持っており、ある程度の価格で売れるケースもあるようが、やはり.comの場合は人気が高いです。.netや.orgはかなり値打ちが下がってしまい、そのほかの.infoなどはレアなドメイン名でもそれほど値はつきません。
基本的なスタンスとしては、sedoやgodaddyで売りに出しつつも、アフィリエイトサイトで利用できるようなら自分で使うもよしという考えです。
売ってもせいぜい数十万円にしかなりませんし、それに対してサイト収入の場合は月100万、200万も夢ではなく、実際その程度の収益になったこともありますが、売れなければ、自分で使うという選択もアリだと思います。
売りたいのを焦って二束三文で売るよりも、富裕層が買ってくれるまで気長に待つ、それが一番いいのではないかなと考えています。その間のワクワク感も楽しめますし、納得のいく価格を設定しつつ、１年、２年単位で気長に売りにだしておけばよいと思います。