SEOスコアを極力落とさずドメインを変更してみた

2017年にお名前.comで取得した「takuyakobayashi.jp」を使用していましたが、
コアサーバーで「takuyakobayashi.jp」を新たに取得し、ドメインを変更しました。

お名前.comは高い

ドメイン変更に至った理由:

  • お名前.comのドメイン更新費が高い。
  • お名前.comが「サービス維持調整費」を導入した。(上がり続けて今は22%になっている…)
  • .id(インドネシア)より.jpの方が良い。

一番の理由は、サービス維持調整費の導入で、.idのドメイン代が4,378円/年という強気価格で、サーバー代も安くはなく1,430円/月くらい払っていました。そこに20%増しはかなり痛い。

コスパ最強コアサーバー

コアサーバーでは、V2プランに加入している限り、.jpドメインの更新代がかからない(キャンペーン期間中に加入した場合)ので、圧倒的にランニングコストが抑えられます。しかもサーバー代も月額330円~(CORE-X)と激安です。
コアサーバーならお名前.comの1/3のコストでサーバーを運営できます。

自分が行ったドメイン変更作業

takuyakobayashi.jp(以下:)からtakuyakobayashi.jp(以下:)に変更する際に、できる限りSEOスコアを維持したい。
そのために行った方法は次の通りです。

1.「」に「」の複製をつくる

データベースやファイルをバックアップし、
」と「」に同じものが構築されている状態を作ります。

2.「」をサーチコンソールに追加

古い方「」がサーチコンソールに追加されている事が前提ですが、移行先の「」の方もサーチコンソールに追加します。

3. 「」に.htaccessで301リダイレクトを設定

」のルートに次のような.htaccessを追加し、URL構造を維持したまま「」に301リダイレクトさせるようにします。

RewriteEngine On
RewriteRule ^(.*)$ https://takuyakobayashi.jp/$1 [R=301,L]

4.サーチコンソールのアドレス変更ツールで移行を知らせる

サーチコンソールで「」のプロパティを開きます。

次に、設定→アドレス変更から移行先の「」プロパティを選択してアドレス変更を行います。

アドレス変更ツール – Search Console ヘルプ

いくつかサイトを運営しているので、サイトごとに同じ手順を行いました。

あとは待つだけ

以上の作業によって検索エンジンにアドレス変更が通知され、SEOスコアへの影響を最小限に移行させることができるはずです。

今回のように、URL変更を伴うサイト移転方法についてはGoogleがベストプラクティスをまとめてくれています。サイトを移転する方法 – 検索セントラル

青天の霹靂!AdSenseで制限を受ける「表示できる広告の数が制限されています」

昨日くらいからブログに自動広告がついていない事に気付き、AdSenseにログインしてみたら、こんな表示が:

表示できる広告の数が制限されています。詳しくは、ポリシー センターをご確認ください。

AdSense

「無効なトラフィックの問題」で広告配信が制限されたとのこと。

無効なトラフィックの問題とは

無効なトラフィックとは次の通りです。

  • サイト運営者様が、ご自身のライブ広告をクリックしてクリック数やインプレッション数を増やすこと
  • 1 人以上のユーザーが繰り返しクリックして、クリック数やインプレッション数を増やすこと
  • サイト運営者様がご自身の広告でのクリックを誘導すること(例: 広告をクリックするようユーザーを誘導するあらゆる言葉、大量の偶発的クリックを誘発する広告掲載など)
  • 自動クリックツールやトラフィック ソース、ロボット、その他の不正な行為を行うソフトウェア
https://support.google.com/adsense/answer/16737?sjid=8056973094815208343-AP

要は不正にクリックしたりインプレッションを増やす行為全般のこと。
全く心当たりがないどころか、むしろ疑いを掛けられないように細心の注意を払っていたつもりでしたが・・・

不正なクリックではなく急なPV増加のせいか?

AdSenseを見てみると、クリック数は変わらず、何故かPVが異常に伸びている様子でした。

普段見ないAnalyticsを見てみると、特定の記事のアクセス数が1日にして異常な伸び方をしていました。ユーザーの8割がモバイル端末で、ロケールは日本。参照元はほぼオーガニックサーチ。

サイト全体のアクセス数の推移

無効なトラフィックの原因はこの急なPV増加かと思うのですが、はっきりした原因は分からないので、様子を見るしかありません。

現状を報告

とりあえず、無効なクリックの連絡フォームから、不正行為は一切していない事や、急に伸びた記事がある事など、現状を報告しました。

追記(7/12午前):一週間経過しましたが、送信したメッセージに対する返信はありません。

広告のトラフィックの責任はサイト運営者にある

広告のトラフィックの最終的な責任はサイト運営者にある為、
サイト運営者は積極的な防止策を講じる必要があるとされています。

広告のトラフィックについての最終的な責任は AdSense サイト運営者様にあります。このため、広告のトラフィックを念入りに監視して、アカウントが AdSense ポリシーを遵守しており、無効なトラフィックが発生していないことを確認する作業が不可欠です。以下のヒントを実践したうえで、疑わしい操作が見られた場合は、Google にお知らせください

https://support.google.com/adsense/answer/1112983?sjid=8056973094815208343-AP

それを怠ったことによって生じた不都合は、サイト運営者が悪いと言われてしまっても仕方ありませんね。

神に祈るしかない

こちらに非が無い以上、現状を報告する以外に成す術はありません。

これで、もしアカウント停止になってしまったら、自然災害に見舞われたと思うしかありません。

何か進捗があったら追記します。

追記(7/12午後):「現在、問題はありません」になりました

広告制限から9日後、管理画面のポリシーセンターを確認したところ、制限の表示は消えて「現在、問題はありません」という表記になっていました。

やったこととしては、

他に思い当たる原因:

  • 執筆中、リロードしては直しを繰り返していたので、サーバーのログには自分のリクエストが大量にありました。PV稼ぎと間違われたのかも。
  • インストールから4年経つFirefox:一部Webサイトで正常な動作をしないケースが増えてきたので、なんらかのバグで不正なリクエストなどが送られていたかもしれません。

それら以外にもいくつかの要素が重なって今回の規制を受けたのかもしれません。

Firefoxをリフレッシュし、ブログにログイン中は広告を表示しないように設定しました。

最悪、永久追放も覚悟していましたが、元に戻って良かったです。

突然「Instagramフィードで重大な問題」が出たので直す:Smash Balloon Instagram Feed

インスタグラムの埋め込みに「Smash Balloon Instagram Feed」というWordPressプラグインを使用していましたが、ページ右下に突然このようなエラーがでました。

「Instagramフィードで重大な問題」

このエラーはログインユーザーのみに表示されているようです。

この問題を解決」から管理画面に飛ぶと、次のような表示が:

エラー:アクセストークンが無効か、有効期限が切れています。フィードは更新されません。
APIエラー100: Tried accessing nonexisting field (media_product_type) on node type (Media)

自分の環境では次の手順で解決しました。

  1. 「Smash Balloon Instagram Feed」プラグインを更新
  2. インスタグラムにログイン
  3. ソースを再接続

1.「Smash Balloon Instagram Feed」プラグインを更新

管理画面→プラグイン→「Smash Balloon Instagram Feed」プラグインを更新します。

バージョン6.1.5が利用可能になっていました。

2.インスタグラムにログイン

https://www.instagram.com/

インスタグラムにログイン済みの場合はそのままでOKですが、他社のアカウントにログインしていた場合は大変なので確認しましょう。

3.ソースを再接続

WordPressに戻り、「Smash Balloon Instagram Feed」プラグインの設定画面から「再接続」を押します。

すると、最初に設定したときのようなウィザードが開始されるので進めていきます。

  1. Add a new Source: Personal
  2. Connect your Instagram Account: Connect with Instagram
  3. Instagram ~の情報を引き続き共有しますか? 許可する
  4. Security Confirmation: Yes,it is my domain

一通り完了すると管理画面にリダイレクトして戻ってきます。その際に「ソースが無効」が消えていたら成功です。

video要素のロード完了後に再生を行う

結論

ソースコードはこちら。
ローディング表示を実装したい場合はvideo要素の裏に表示させておくことで対応してください。

<script>
window.addEventListener('DOMContentLoaded', (event) => {
  var video = document.querySelector('video');

  if (video.readyState >= 3) {
    // ビデオの読み込みが既に完了している場合
    document.body.classList.add('loaded');
    video.play();
  } else {
    // ビデオの読み込みが完了するまで 'canplaythrough' イベントを監視
    video.addEventListener('canplaythrough', function() {
      document.body.classList.add('loaded');
      video.play();
    });
  }
});
</script>
<style>
  video {
    transition: .2s opacity;
  }
  body:not(.loaded) video {
    opacity: 0;
  }
  body.loaded video {
    opacity: 1;
  }
</style>
<video src="path/video.mp4" loop muted playsinline></video>

詳細

video要素を背景として使用する場合、次のようなコードを使用すると思います。

<video src="path/video.mp4" autoplay loop muted playsinline></video>

これには次のような問題があります。

  • ロード中は表示されない
  • 十分にバッファされるまでの間、最初のフレームが静止画として表示される

環境によって挙動は異なると思いますが、自分が確認したのが上記です。
ロード中に表示されない件は、video要素の背景にローディングのエフェクトを隠しておけば良いとして、問題なのは二番目のバッファされるまでの間、最初のフレームが静止画として表示される件。
これはautoplay属性がそのような挙動を示すようだったので、autoplay属性を消してjavascriptで再生の制御をすることにしました。

var video = document.querySelector('video');
// videoの読み込み完了時に発火
video.addEventListener('canplaythrough', function() {
  // bodyにloadedクラスをつける
  document.body.classList.add('loaded');
  // 再生
  video.play();
});

しかし、上記コードではcanplaythroughが発火しない場合がありました。

どうやら、キャッシュを読みこんだ際はcanplaythroughなどのイベントは取得できないようで、
再生が開始されない不具合がありました。そこで次のコードになりました。

<script>
window.addEventListener('DOMContentLoaded', (event) => {
  var video = document.querySelector('video');

  if (video.readyState >= 3) {
    // ビデオの読み込みが既に完了している場合
    document.body.classList.add('loaded');
    video.play();
  } else {
    // ビデオの読み込みが完了するまで 'canplaythrough' イベントを監視
    video.addEventListener('canplaythrough', function() {
      document.body.classList.add('loaded');
      video.play();
    });
  }
});
</script>
<style>
  video {
    transition: .2s opacity;
  }
  body:not(.loaded) video {
    opacity: 0;
  }
  body.loaded video {
    opacity: 1;
  }
</style>
<video src="path/video.mp4" loop muted playsinline></video>

WordPressのテーブルプレフィックスを変更する方法

wp-config.phpを開き、「$table_prefix = ‘wp_’;」を
任意のプレフィックス「$table_prefix = ‘newprefix_’;」に変更します。

次に、データベースのプレフィックスの変更します。
以下は「wp_」を「newprefix_」にリネームするSQLコマンドです。phpmyadminでGUIで変更してもOK。

RENAME table wp_commentmeta TO newprefix_commentmeta;
RENAME table wp_comments TO newprefix_comments;
RENAME table wp_links TO newprefix_links;
RENAME table wp_options TO newprefix_options;
RENAME table wp_postmeta TO newprefix_postmeta;
RENAME table wp_posts TO newprefix_posts;
RENAME table wp_terms TO newprefix_terms;
RENAME table wp_termmeta TO newprefix_termmeta;
RENAME table wp_term_relationships TO newprefix_term_relationships;
RENAME table wp_term_taxonomy TO newprefix_term_taxonomy;
RENAME table wp_usermeta TO newprefix_usermeta;
RENAME table wp_users TO newprefix_users;

newprefix_optionsテーブルを開き、次のレコードを探して「wp_」から「newprefix_」に変更します。

  • option_nameが「wp_user_roles」 → newprefix_user_roles
  • option_nameが「wp_capabilities」 → newprefix_capabilities

newprefix_usermetaテーブル内のレコードも同様に変更します。

  • meta_keyが「wp_capabilities」 → newprefix_capabilities
  • meta_keyが「wp_user_level」 → newprefix_user_level

注意: 変更前にデータベースのバックアップを作成することを強くおすすめします。
プレフィックスを変更した場合、関連するプラグインやカスタムテーマに影響を与える可能性があります。特に、直接テーブル名を指定しているカスタムコードやクエリがある場合は、変更したプレフィックスに合わせて修正する必要があります。

backgroundでSVGを利用して色を弄る

SVGをbackgroundで使って色を自由にいじる方法。

1. SVGのコードをUTF8でパーセントエンコーディングする。
ツール:https://tech-unlimited.com/urlencode.html

2.次のようにbackground-imageに指定する。

background-image: url(data:image/svg+xml;charset=utf8,%3Csvg%20xmlns%3D~略~fill%3D%22%23FFFFFF%22%);

3.「fill=”#FFFFFF“」に相当する部分、FFFFFFがカラーコードなのでここを自由に変更する。

WordPressで他のユーザーの投稿やメディアを表示しないようにする

WordPressで他のユーザーの投稿やメディアライブラリのファイルを表示しないようにする方法です。

functions.phpに以下を追記:

// postで他者の投稿を見えなくする
function hide_other_posts($wp_query) {
  global $current_screen, $current_user;
    
  if($current_screen->id != 'edit-post') return;
  
  if($current_user->roles[0] == 'administrator') return;

  $wp_query->query_vars['author'] = $current_user->ID;
}
add_action('pre_get_posts', 'hide_other_posts');

// メディアライブラリで他者の投稿を見えなくする
function show_only_authorimage( $where ){
  global $current_user;
    if( $current_user->roles[0] != 'administrator' ){
      if( isset( $_POST['action'] ) && ( $_POST['action'] == 'query-attachments' ) ){
        $where .= ' AND post_author='.$current_user->data->ID;
      }
    }
  return $where;
}
add_filter( 'posts_where', 'show_only_authorimage' );

// postのアクセス限定
function show_owned_posts_only( $views ) {
  global $current_user;
  if($current_user->roles[0] != 'administrator') {  
    unset($views['all']); // すべて
    unset($views['mine']); // 所有
    unset($views['draft']); // 下書き
    unset($views['publish']); // 公開済み
    unset($views['pending']); // 保留中
    unset($views['trash']); // ゴミ箱
  }
  return $views;
}
add_filter('views_edit-post', 'show_owned_posts_only');

// ダッシュボードの項目を消す
function remove_dashboard_widget() {
  global $current_user;
  if( $current_user->roles[0] != 'administrator' ){
    remove_meta_box( 'dashboard_site_health', 'dashboard', 'normal' ); //サイトヘルスステータス
    remove_meta_box( 'dashboard_right_now', 'dashboard', 'normal' ); //概要
    remove_meta_box( 'dashboard_activity', 'dashboard', 'normal' ); //アクティビティ
    remove_meta_box( 'dashboard_quick_press', 'dashboard', 'side' ); //クイックドラフト
    remove_meta_box( 'dashboard_primary', 'dashboard', 'side' ); //WordPressニュース
    remove_action( 'welcome_panel', 'wp_welcome_panel' ); //ようこそ
  }
}
add_action('wp_dashboard_setup', 'remove_dashboard_widget' );

// サイドメニューのダッシュボードを消す
function remove_menus() {
  if( $current_user->roles[0] != 'administrator' ){
    remove_menu_page( 'index.php' ); // ダッシュボード
  }
}
add_action( 'admin_menu', 'remove_menus', 999 );

参考サイト:

ChromeでWordPress管理画面に入ると何度もBASIC認証を求められる時の対処法

BASIC認証で保護されたWordPressのサイトで、Chromeで管理画面に入って画面遷移をすると、何度もBASIC認証を求められる。

401を返すものがあるとBASIC認証画面が出てしまう

WordPress管理画面に居る状態で、右クリック要素の検証でネットワークタブを見ながらF5を押すと、401を返すリクエストがあった。

favicon.icoとREST API。

faviconは.htaccessで除外をしてやればOK。

<Files "favicon.ico">
    AuthType none
    Satisfy any
</Files>

REST APIについては「SiteGuard」プラグインの「ユーザー名漏洩防御」→「REST API無効化」にチェックが入っていたので外したらBASIC認証は出なくなった。

「M PLUS Rounded 1c」「M PLUS 1p」がWindowsでジャギるのを修正する方法

Webフォント「M PLUS Rounded 1c」「M PLUS 1p」をWindowsで表示すると↓の画像のようにギザギザに表示されます。

だけど、大きめのフォントサイズだとアンチエイリアスが効く様子。

16px程度だとギザギザになる。

修正する方法1:CSSでジャギーを治す

CSSで「M PLUS」系Webフォントのジャギ―を治すには次のように指定します:

transform: skewX(0.03deg);

transformを使用して0.03°平行四辺形に変形させます。
見た目には変化ありませんが、これを指定した瞬間にアンチエイリアスが目覚めます。

「rotate(0.03deg)」も効きますが、「skewX(0.03deg)」の方が表示の変化が少ないです。

修正する方法2:「M PLUS 1」や「M PLUS2」に置き換える

ちらっとGoogleFontsを見てみたら、次の3つが追加されていました。

  • M PLUS
  • M PLUS 2
  • M PLUS 1 Code

フォントサイズを小さくしてプレビューしてみるとそれら二つはジャギってません。

「M PLUS Rounded 1c」や「M PLUS 1p」は卒業して、
「M PLUS」「M PLUS 2」「M PLUS 1 Code」等に置き換えましょう。