ようこそ、ウラとボツへ

現在、新テーマ「Twentynineteen」のテスト中です。ご不便をおかけするかもしれません。m(__)m

特にプラグインについては、最終更新日が12月12日以前の記事は新テーマで未テストです。ボチボチ進めます。

テスト環境の「Untold Stories」では、英語環境でよりオリジナルに近い形でテスト中です。

カテゴリー、Twentynineteen記事一覧

    カテゴリー、モンスターハンターワールド記事一覧

      カテゴリー、イギリス記事一覧

        最新記事

        • いい大人が「箱」目当てに衝動買いしたビスケット christmas shortbread - tinイギリスのコイン型の缶入りのクリスマスショートブレッドを衝動買いしてしまいました。いい大人が入れ物目当てで買い物するなんて、どうなのよ。っと思いつつ、その上記事にまでしてしまっています。笑。
        • なんか「薩摩」が複数形になっているんですけどw satsumas地名「薩摩」は、固有名詞なので、大文字スタートの「Satsuma」が教科書的な英語ですが、イギリスでは「satsumas」という複数形を持つ可算一般名詞になっています。1薩摩、2薩摩と数えるのだと思うのですが、1薩摩はミカン1個分です。笑。
        • 「ガイラパイプ睡眠」に1年分の物欲を消費した Taroth Pipe Sleep - Notes毎年ちょっと贅沢な買い物をする絶好の機会として楽しみにしている「ブラックフライデー」。欲しいモノが浮かびません。今年は「ガイラパイプ睡眠」が欲しくなり、それでかなり苦労しました。その結果、物欲が枯渇してしまったようです。
        • モンハンあるある?「は?、それ、あたるの!?」 giant vigorwaspHorizon Zero Dawnをトロコンしたので、モンハンワールドを覗いたら、アーロイの重ね着装衣がもらえるイベントがありました。早速、チケット集めに出かけて、モンハンの「当たり判定」の洗礼を受けました。あはは。
        • 初心者ハンター、王ゼノで「緊急回避」を学ぶ MHW Dive Evasionワールドでモンハンデビューしたとはいえ、もうハンターランクが450を越えている。なのに今更「緊急回避」を知りました。いや、歴戦王ゼノ・ジーヴァの青色の床で乙りまくるまで知る必要がなかったんですよね~。ごく稀に何故かコケてるのが、回避行動だったなんて。爆笑。

        筆者のリライト宿題帳

        • ワードプレスが”真っ白”になったら、即刻cPanel ワードプレスが”真っ白”になって、何もできなくなる時ありますよね。私のケースでは、ほとんどがfunctions.phpを触っている時に起こります。 そういう時は、即刻レンタルサーバー側の管理画面へログインして、コントロールパネルからリカバリーを行うようにしています。 再ログインをしても管理画面から”真っ白” ページの表示が真っ白ならまだしも、ログイン直後の管理画面から真っ白というのは、ワードプレスならではではないでしょうか? 逆に言えば、FC2、Blogger、Seesaaでは、HTMLとCSSはカスタマイズできても、サイトの仕組み自体は既にある枠組みの中に収まっているので、管理画面から触れなくなることはありませんでした。 ワードプレスでも、コードにエラーがある場合、保存できなかったり、ページが崩れていたり、表示されたページにエラーメッセージが出たりのレベルで済むことが多いです。 でも稀に、編集画面にすら戻れない、再ログインしても無意味なレベルに真っ白になることがあります。 そういう時は、即刻、レンタルサーバーのcPanel(コントロールパネル)へ直行しています。 リカバリー1、cPanelでバックアップファイルをリカバリー 私が最も簡単だと思って、頻用しているのは、この方法です。 ただ元に戻すだけ。です。 コントロールパネルの第一画面、メニューの中にBackup Manager→Restore(元に戻す)というのがあるのでそれを選びます。 元に戻せるのは、FileとDatabaseです。Fileがプログラムファイルなどで、Databaseが記事や画像データです。 カスタマイズしている時に問題が発生した場合は、Fileを元に戻せばOKです。 Backup Type: Fileを選ぶ 更新したいファイルのバージョン日付を選ぶ public_htmlを選んで、矢印マーク(下図) 元に戻す先は「current destination」を選ぶ ワードプレスに再ログインする 私の場合は、いつからこうなっているのかわからない出元不明のエラー(プラグインの更新など自分で書いていない更新)をもとに戻すことが多いです。 リカバリー2、コントロールパネルからファイル修正する 何がダメだったか、どう修正したらよいのかがハッキリしている場合は、サーバー側からファイルの修正をすることもできます。 コントロールパネルの第一画面、メニューの中にFile Managerというのがあるのでそれを選びます。 問題個所まで階層を降りて、ファイルを探せれば、ピンポイントで直接編集ができます。 functions.phpを使いこなしたい! ワードプレスでは、HTML(ページ内容)、CSS(ページ装飾)の他にphp(ページ構成)の編集ができ、すごく面白いです! 特にfunctions.phpに適切に記述ができれば、出来ることが広がって、さぞ楽しいだろうな~と思います。 学習がボチボチしか進まずもどかしいです。
        • ワードプレス、Yoastで”サーチコンソール”と連携 ワードプレスサイトと”サーチコンソール”の連携 検索流入型のブログサイト作りに非常に重用している”サーチコンソール”。 “サーチコンソール”側にサイトを登録する(=プロパティーの登録)際に、サイトの所有者の確認を求められます。所有権の確認は、Yoastだけでなく、Jetpackでもできますし、サーチコンソール側にていろいろな認証方法が提案されています。 私は、SEOプラグインYoastを使って、ワードプレスと連携させました。 Yoastの初期設定でサーチコンソールと連携 私はYoastの初期設定の際に、併せて行いました。 GOOGLE 認証コードを取得するをクリックし Googleアカウントを選択 許可 コードをコピー ここに認証コードを入力してくださいにペースト 認証ボタンをポチ 次へ ただ誘導されるに従っただけです。 Yoastの初期設定、何故かここだけ日本語です。(笑) 後からサーチコンソールと連携 初期設定の際に設定しなかった場合は、Yoast→General→Open Configuration Wizardにて再設定できます。 便利です。 Yoastでクロールエラーのトラッキング 私は、管理画面にてクロールエラーの管理作業を行っています。 上の設定が終わると、Yoast SEOのメニューに”Search Console”が追加されます。 ここにサーチコンソールでのクロールエラーが流れてくるようになるので、ワードプレスの管理画面から処置を行うことができます。 Create redirect (リダイレクトを設定、Yoast有料版)、 View (閲覧、当該URLへジャンプ)、 Mark as fixed (修正済みとする) これ、いろいろ試しすぎて404まみれの私には、本当に凄く便利です。 この他、「検索トラフィック」や「検索での見え方」などの機能もサイト作りに有用なのですが、Yoastは拾ってきてくれませんから、結局は自分でサーチコンソールにログインして見に行きます。 クロールエラーはすぐに処置すべし! クロールエラー(404)は、Google的にはペナルティーにはならないそうですが、実際のビジターにご不便をおかけすることになるので、私はすぐに処置するようにしています。 処置法は、大体の場合、正しいページへの「Redirect設定」です。稀に新しいページを作ったりもします。 実際の処置が終わったら、上の図の、Mark as fixedをポチッとしておけば、サーチコンソールと連携して同じ場所を更新してくれます。 これがワードプレス側で作業できることは、時短かつ便利で、重宝しています。
        • 恐怖!クロールエラー「404(見つかりません)」が大量発生 サーチコンソールにGoogle先生からメッセージが届いていました。大量の”クロールエラー”が発生したようです。 クロールエラー、404(見つかりません)とは クロールエラーと言っても、数種類あります。私が経験したことがあるのは、サーバーエラーと見つかりませんです。 今回、大量発生したクロールエラーは、みつかりませんの方です。 エラーコードが404なので、404エラーで意味が通じちゃうほどです。 ページが削除されたり、URLが変更されたりすると、サーバーが「みつかりません」(404エラー)を返します。 クロール中に発見されたこのエラーは、サーチコンソールのクロールエラーに記録されます。 そして、これが大量発生すると、グーグル先生からメールが届きます。 ユーザーの利便性 下記が、グーグル先生からいただいたメッセージです。 Google Search Consoleのメッセージより引用 https://noronoron.com/ で 404(見つかりません)エラーを返す URL の数が著しく増加したことが Googlebot で検出されました。これはサービスの停止や設定エラーを示している可能性があり、その場合にはユーザーの利便性が低下していることになります。結果として、こうした URL は Google 検索結果には表示されなくなります。該当する URL が完全に存在していない場合は、特に何かしていただく必要はありません。 404エラーがたくさんあること自体は、Googleのペナルティーの対象にはならないと言われます。 但し、私がすごく気になるのは、ユーザーの利便性の方です。Googleがクロールしているという事は、既になくなってしまったページが検索結果に表示される可能性があります。そのページをクリックしてしまった人は、ボットと同様に404メッセージにランディングします。 これ、イヤじゃないですか? 該当するURLが完全に存在していない場合は、特に何かしていただく必要はありません。なんて書いていますが、ページが削除されたと最終的に認知してくれるまで結構時間がかかるみたいで、404エラーが繰り返し検出されます。 このため、ボットが発見した段階でササっと処置しておきたいものです。 グーグルおススメの処置法3ステップ 受け取ったメッセージに示されていた処置法は3ステップです。 問題URLの特定→修正→修正確認。って、普通ですね。 問題URLの特定 サーチコンソールのクロール→クロールエラー→(PC/スマートフォン)→見つかりません。で問題があったURLがリスト表示されています。 私はYoast SEOのSearch Consoleでワードプレス側から確認しています。 詳しくは、関連記事「ワードプレス、Yoastで”サーチコンソール”と連携」のYoastでクロールエラーのトラッキングをご参照ください。 Yoastのこの機能は、飽くまでサーチコンソールとの連携結果なので、検出タイミングがサーチコンソール依存です。もっと早く404エラーを検知したい場合は、Redirectionの404s機能がおススメです。 詳しくは、関連記事「プラグイン”Redirection”を使い倒して、404エラーの処置」の404sの機能をご参照ください。 404エラー修正 URLを残す場合 これが何気に一番難しいんですけれど… 404エラーが出ている時点で、そのページが存在していないことが多く、ページを作ることになるパターンです。 なくなったページがリカバーできるなら良いのですが、ない場合、書き直しです。笑。 私の場合、サーバーホスティング側での問題だったことがありません。 URLを残さない場合 日本語URLを英数字URLへ変更した場合、タグをカテゴリーに変えたことでURLが変わってしまった場合、アーカイブページを無効にした場合などは、ほとんどをRedirectによって処置します。 やり方は、関連記事「プラグイン”Redirection”を使い倒して、404エラーの処置」のRedirectsの機能をご参照ください。 そのうえで、参照元のリンクを探せれば修正しておきます。元のURLの一部を管理画面で検索すれば、その用語を含んだアンカーテキストも含めて結果表示してくれます。 何気に便利なのがYoastの内部リンクカウンターで、発リンクが出ている記事をクリックすると、参照元のリンクに行きつくことが多いです。 普通はグーグルアナリティクスやMozでやるみたいですけれど、↑の方が手っ取り早いです。 修正を確認する Google先生からのメッセージには、Fetch as Googleを使うようにおススメされます。 もとのURLを残す場合は、Fetch as Googleの結果が、緑色のチェックマークと共に完了となり、HTTPレスポンスの結果が200 OKとなっているハズです。 リダイレクトがかかっている場合、Fetch as Googleの結果に、オレンジのビックリマークと共にリダイレクトされましたというステータスが表示されます。HTTPレスポンスの詳細も確認できます。 こんなことに毎日ボチボチ取り組んでいるわけですが、自分のブログ運営の計画性のなさにガッカリします。