Googleのガイドラインが、隠しテキスト=スパムであるかのような書き方をしているため、長いことdisplay:none;の利用をためらっていた@web_shufuです。しかし、レスポンシブデザインの都合上使用する程度なら問題ないようです。 (さらに…)
投稿者: webshufu
-
【SEO都市伝説】display:none;でテキストを隠すと、本当にスパム判定されるのか
-
【10分で終了】facebook投稿時にサムネイルを表示するためのOGP設定-WordPressカスタマイズ
facebookでブログ記事を拡散したいなら必ず設定しないといけないのがOGPです。プラグインは使わずに、コピペするだけで設定が終わるスニペットを作ってみました。(HTML5用、header.phpに貼り付け)OGPとは
OGPはOpen Graph Protocolの略語です。ウェブページの内容をプログラムが把握しやすい形式で書いたものです。その形式は以下の通り
<meta property="og:title" content="ページタイトル"> <meta property="og:type" content="トップページはwesiteそれ以外はarticle"> <meta property="og:description" content="ページの概要"> <meta property="og:url" content="ページのURL"> <meta property="og:image" content="フェイスブックに投稿したときに表示するサムネイル画像のURL"> <meta property="og:site_name" content="サイト名"> <meta property="fb:admins" content="fb:adminsナンバー">このページの実際のOGP設定は以下のようになっています。
<meta property="og:title" content="【コピペで即使用可】WordPressのOGP設定はこれだけでOK!|ウェブシュフ"> <meta property="og:type" content="article"> <meta property="og:description" content="facebookでブログ記事を拡散したいなら必ず設定しないといけないのがOGPです。設定用のプラグインもありますが、プラグインは使わずに済むならそれに越したことはないので、コピペするだけで設定が終わるスニペットを作ってみました。"> <meta property="og:url" content="https://webshufu.com/setting-ogp-in-wordpress/"> <meta property="og:image" content="https://webshufu.com/top/wp-content/uploads/2013/01/2013-01-27_1723-ogp.png"> <meta property="og:site_name" content="ウェブシュフ"> <meta property="fb:admins" content="●●●●●●●●●●●●●●●●●●●●●●●">OGPを設定しないと不便
facebookのシェア投稿もOGPを利用しています。ですから、wordpressの記事をfacebookを通じて拡散したいなら、OGPを導入しないといけません。
ウェブシュフがOGPを導入していなかった頃は、ブログ記事をfacebookに投稿してもサムネイルが自動的には表示されずに、手動で画像を貼ったりしていました。
ここで「あ~面倒くせ」と思ったのがOGPを設定するきっかけでした。
og:titleの設定
ここからOGPの設定に入ります。色々説明していますが、手っ取り早くOGP設定を完成させたい人は、説明そっちのけでコピペに専念してください。
og:titleは<head>~</head>内の<title>~</title>と同じ設定にするのが自然です。
ウェブシュフの場合は、og:titleの設定のためのコードは以下の通りになります。(<head>~</head>内に貼り付けてください。)
<?php if ( is_home() ) { $title=get_bloginfo('name'); } else { $title=wp_title( '', false, 'right' ).'|'.get_bloginfo('name'); } if ( $paged >= 2 || $page >= 2) { if(is_home) { $title=$title.'-記事一覧-'.max( $paged, $page ).'ページ目|'; } else { $title=str_replace('|','-'.max( $paged, $page ).'ページ目|', $title); } } ?> <meta property="og:title" content="<?php echo $title; ?>">og:typeの設定
トップページはwebsiteそれ以外はarticleなので、<head>~</head>内に以下を記述すればOK。
<?php if(is_home()) { $og_type="website"; } else { $og_type="article"; } ?> <meta property="og:type" content="<?php echo $og_type; ?>">og:descriptionの設定
og:descriptionはそのページの概要なので、<head>~</head>内の<meta name=”description” content=”~” />の設定と同じ考え方で設定するのが自然です。
よって、og:descriptionの設定のためのコードは以下の通りになります。(<head>~</head>内に貼り付けてください。)
<?php if ( is_home() ) { $description=get_bloginfo('description'); } else if (is_category()) { $description=str_replace("\n", "", category_description()); } else if (is_page()) { $description=get_the_excerpt(); } else if (is_single()) { $description=get_the_excerpt(); } if ( $paged >= 2 || $page >= 2) { $description=""; } /***余分な</p>を取り除く***/ $description=str_replace("<p>", "", $description); $description=str_replace("</p>", "", $description); /***余分な<p></p>を取り除く(終)***/ ?> <meta property="og:description" content="<?php echo $description; ?>">og:urlの設定
og:urlはそのページの正式なURLなので、その意味するところはcanonical urlと同じです。
よって、og:urlの設定のためのコードは以下の通りになります。(<head>~</head>内に貼り付けてください。)
<?php if ( is_home() ) { $canonical_url=get_bloginfo('url')."/"; } else if (is_category()) { $canonical_url=get_category_link(get_query_var('cat')); } else if (is_page()||is_single()) { $canonical_url=get_permalink(); } if ( $paged >= 2 || $page >= 2) { $canonical_url=$canonical_url.'page/'.max( $paged, $page ).'/'; } ?> <meta property="og:url" content="<?php echo $canonical_url; ?>">og:imageの設定
og:imageはサムネイル画像を指定する場所です。ウェブシュフはこの記事と同じ考え方でog:imageを設定しました。
コードは以下の通りです。(<head>~</head>内に貼り付けてください。)
<?php $str = $post->post_content; $searchPattern = '/<img.*?src=(["\'])(.+?)\1.*?>/i';//投稿にイメージがあるか調べる if (has_post_thumbnail() && ! is_archive() && ! is_front_page() && ! is_home()) {//投稿にサムネイルがある場合の処理 $image_id = get_post_thumbnail_id(); $image = wp_get_attachment_image_src( $image_id, 'full'); $ogimage=$image[0]; } else if ( preg_match( $searchPattern, $str, $imgurl ) &&is_single()) {//投稿にサムネイルは無いが画像がある場合の処理 $ogimage=$imgurl[2]; } else {//投稿にサムネイルも画像も無い場合、もしくはアーカイブページの処理 $ogimage=get_bloginfo('url')."/top/wp-content/uploads/2013/01/2013-01-20_1952.png"; } ?> <meta property="og:image" content="<?php echo $ogimage; ?>">og:site_nameの設定
ここは、説明不要だと思います。
<meta property="og:site_name" content="<?php echo get_bloginfo('name'); ?>">fb:adminsの設定
fb:adminsの番号は、以下のようにして取得します。まず、フェイスブックにログインした状態でLike Button – Facebook開発者に行きます。
次に、下スクロールして、Step 2 – Get Open Graph Tagsの直下の入力フォームを見てください。(左図)
すると、「admin」の下の欄にはすでに数字が入っていると思います。これが、fb:adminsの番号です。
あとは、<head>~</head>内に以下を記述すればOK。
<meta property="fb:admins" content="今調べたfb:adminsの番号">DOCTYPE宣言直後に挿入する1行
最後に、DOCTYPE宣言直後、<head>の直前に次の1行を入れます。
<html lang="ja" prefix="og: http://ogp.me/ns# fb: http://www.facebook.com/2008/fbml">これで、facebookに記事を投稿すると自動的にサムネイルが表示されるようになります。
お疲れ様でした。
追記
2013/3/16追記:大き目のサムネイルを確実に表示する方法も参考にしてください。
追記:facebook投稿時に大きいサムネイル画像を100%確実に表示する方法

facebookにブログ記事を投稿すると、今までに比べて大きいサムネイルが表示されるようになりました。とはいっても、正しい手順を踏まないと表示されないようなので、これなら間違いないという方法をご紹介します。 (さらに…) -
コピペでOK!TweetのWordPressへの貼り付け【改訂版】
wordpressにtweetを貼り付けるのはとても簡単で、乱暴に言えば「URLをコピペするだけ」です。その方法を紹介します。(以前に一度まとめた記事ですが、Twitterのアップデートに合わせて内容を書き換えました。) (さらに…) -
SNSに実名アカウントがないと様々な面で不利、SEOにも悪影響
原則として実名登録を求められるfacebookがユーザーを増やして以降、twitterなど他のSNSでも実名で活動する人が増えています。これは、SNSに実名アカウントがないと様々な面で明らかに不利になりつつあるからです。この動きはSEOにまで及んでいます。
「自分」を晒す個人の増加
facebookのユーザー数は依然として伸び続けています。下の図は、ついに伸びが鈍化?Facebookの都道府県別ユーザーデータ2013年1月版 | ソーシャルメディア集客ラボに掲載されたグラフです。

不正アカウントがないという強引な仮定の元では、日本人の7人に一人程度はfacebookに実名アカウントを持っていることになります。また、facebook以外のSNS、例えばtwitterでも、実名でアカウントを使い、顔写真すら掲載しているユーザーが明らかに増えてきました。
ソーシャルメディア上で実名・顔写真を載せるなど「自分」が明白に特定されるレベルにまで個人情報を晒して活動することは、もはや特殊なことではなく一般化してきているのです。
自分の実名・顔写真を晒す理由
それでは、なぜSNS上に個人情報を晒すのかといえば、晒すメリットがあるからです。当然ですよね。
メリット:ネットを通じた信頼獲得の効率化
普通、人というのはよく知らないものというのは信用できません。信頼に値するかどうか判断しようがないからです。
したがって、信用を獲得するには、自分のことをよく知ってもらう必要があります。
そのためには、個人情報もなるべく多く出したほうがいいのです。特に顔写真があるとないとでは、信用の獲得にずいぶん差が出ます。
もちろんSNSを通じて様々な情報や考え方を発信することも自分のことを知ってもらうことにつながりますが、それだけで終わるのとそこに外見や名前などの個人情報も付加して発信するのとでは大きな違いが生まれます。
また、交友関係を明らかにすることで親近感や信用を得られることもあります。
ソーシャルメディア上で個人情報を明らかにすると、ネットを通じた信頼獲得が効率的になるのです。
デメリットもある
ただし、個人情報を発信するということにはデメリットもあります。
住所や電話番号をうっかり公開してしまえば、わずらわしい勧誘や、ストーカー・窃盗等の犯罪に巻き込まれることもあります。
また、せっかく自分をさらけ出しても、その内容によっては信用ではなく不信や疑惑を獲得してしまう場合もあります。
極端な例ですが、公開したプロフィールに性犯罪歴などがあると、ほとんどの場合は信頼されないどころか排除されるでしょう。
デメリット<メリット
しかし、自分の個人情報をネット上に晒す人にとっては、信頼の獲得を効率化できるというメリットが、デメリットを上回っているのです。
実名・顔写真を出さない者に対するマイナスイメージ
ところで、実名・顔写真など「自分」をネット上に晒している人は、そうしない人を見下す可能性があります。例えば
- 顔写真出せないのは自信がないからだろう
- 経歴を詳しく書けないのは隠したい過去があるからだろう
- もしかして前科もちかも
- 交友関係を公開しないのはやばいヤツとつながってるからかも
- 結局、自分を出せない臆病者
- そもそもSNSを使うことすらできないのかも
このように、実名・顔出しのSNSアカウントを持たないことは、さほど無理なくネガティブなイメージとつなげることが出来ます。
このように、実名・顔写真など「自分」をネット上に晒している人は、そうしない人を「自分に自信がなく、知られては都合の悪い何かがあるからそうしないのだ」と評価しても何の不思議もないのです。
実名・顔出しのSNSアカウントを持たないことはとても不利なことになってしまいました。
実名アカウントがないと就職活動に不利
大企業・有名企業の採用活動では大量の応募者を機械的・効率的に絞り込む手法を常に探しています。
応募者一人ひとりをじっくり吟味するのが理想ですがそんなことをしている時間はありません。
そういう方たちにとってSNSの顔出しアカウントの有無を基準に応募者をふるいにかけるのは割と合理的な行動です。
実名・顔出しのSNSアカウント持たない人が「自信がなく何か隠している可能性がある」ということで門前払いされてもさほど不思議でないような気がします。
実名アカウントがないと恋人探しでも不利
実名・顔出しのSNSアカウントを持っている人は、実名・顔出しのSNSアカウントを持っていない異性について「自分に自信がなく、知られては都合の悪い何かがあるから実名・顔出しのSNSアカウントを持たないのだ」と考える可能性があります。
こうなると、実名・顔出しのSNSアカウントを持っていないことで恋人探しも不利になります。
恋人や結婚相手の条件に「SNSで実名アカウントを持っている人」というのが含まれるようになっても不思議ではない感じがします。
実名アカウントがないとSEOでも不利
SEOについては、現状ですでに、実名・顔出しでGoogle+にて活動することが有利に働きます。
検索結果内の著者情報 – ウェブマスター ツール ヘルプ
実名・顔出しでGoogle+で活動している人のコンテンツを「優秀なコンテンツ」として目立たせることをはっきり書いています。これに加えて、googleは検索順位にAuthor Rank(オーサーランク)という指標を導入予定であることを発表しました。
Author Rankは、あるコンテンツの著者への評価を数値化したもので、これまで良質のコンテンツをリリースしてきた著者のコンテンツをより高く評価するようなものになるようです。
そして、著者への評価の要素として、Googleが信頼性に足ると判断したSNSでの活動というのが含まれることが予想されています。(2013年のSEOで重要になるかもしれない『Author Rank(アウターランク)』とは? | Facebookアプリ/ソーシャルメディア Hivelocity ハイベロシティ)
最後に
最近、検索結果で顔が表示されるブロガーさんが増えてきた気がします。
ウェブシュフも、ネット上での活動を徐々に実名化していこうかと考えています。
-
【ほぼコピペのみ】WordPressのcategoryページで、各投稿から画像を抜き出してサムネイル表示する方法
ワードプレスでカテゴリーページやトップページで投稿のサムネイルを表示させたいけど、その都度サムネイルを設定するのが面倒だったウェブシュフです。このたび、ネット上の情報のおかげさまで、この作業を半自動化できたので報告します。 (さらに…) -
WordPressカテゴリーページのURLからカテゴリーベースを取り除くプラグイン
ワードプレスのカテゴリーページのURLには、ドメインとカテゴリslugの間に/category/などのカテゴリーベースが挿入されてしまいます。ウェブシュフはこれが大嫌いなので、取り除いてみました。 (さらに…) -
全文転載による寄稿は寄付と同じ!SEO的には自殺行為

By: SEOPlanter 大手媒体からの寄稿依頼など全く受けたことがないので、「うらやまけしからん」くらいな羨望のまなざしで見ていたウェブシュフです。でも、既存記事を全文転載する形での寄稿は、SEO的にはデメリットが大きすぎて検討に値しないような気がしてきました。
本来の「寄稿」とは
本来の「寄稿」とはコトバンクによると以下のような意味らしいです。
依頼されて、新聞や雑誌などに原稿を書いて送ること。
つまり、依頼されてから、依頼元の媒体のためだけに原稿を書く(書き下ろす)わけです。
自ブログにも同じ記事が収録されていることなどあってはならないことです。
既存記事の全文転載
ところが、ネットメディアの隆盛にともない、本来の寄稿とは全く異なる「既存記事の全文転載」を、あたかも寄稿であるかのように取り扱うメディアが現れました。
その名は「ガジェット通信」です。@getnews_kikoというアカウントすら持っています。
ガジェ通では、ガジェ通的におもしろい記事を見つけた場合、著者の許可を得て全文転載し、そのことを「寄稿」と言っているようです。
「寄稿」という言葉に対するガジェ通の解釈は、辞書に載っているものとはずいぶん違う「既存記事の全文転載」となっているようです。
全文寄稿=コピーコンテンツ作成
ところで、このガジェ通さんからの「既存記事の全文転載」許可願いですが、うっかりOKするとSEO的にはとんでもないことになるようです。
OKすると自ブログにあるオリジナル記事と全く同じ文章がガジェ通に載ることになります。
これは見事なコピーコンテンツの発生で、これから始まる悲劇の序曲が流れ始めました。
なにしろ、googleでは以下のような声明を出してコピーコンテンツの撲滅に本腰を入れ始めたところなんですから。
[img-link url=”https://webmaster-ja.googleblog.com/2012/10/google-search-algorithm-change.html” title=”Google ウェブマスター向け公式ブログ: 独自コンテンツをより高く評価するために”]
中でも日本のユーザーの方から寄せられるご意見の中には、独自のコンテンツを持つサイトが、ほかのサイトからのコピーで構成されるサイトに埋もれてしまい、見つけづらいというご意見が多数ありました。(中略)
Google は今後とも、ユーザが有用な独自コンテンツを見つけやすくなるよう、アルゴリズムの改善を進めてまいります。googleは独自なコンテンツを優遇するわけではない
上の声明から、Googleは、似たようなコンテンツが複数あるときに、独自で有用なコンテンツを優遇しようとしていることがわかります。
すると、オリジナル記事と「既存記事の全文転載」によってできた記事がある場合、独自に書かれた記事であるはずのオリジナル記事が、検索結果でも優遇されるような気がしますよね。
でも、現実にはそれと全く逆のことが起こっています。
[img-link url=”http://fut573.com/data/google/kenga/” title=”ガジェット通信に寄稿した記事はGoogle先生にどう扱われるのか | 資料庫”]記事タイトルで検索した結果にもかかわらず、3/4もの高確率でオリジナル記事が1位を獲得できていません。普通ならほぼ100%1位であるはずなのに、悲しすぎる結果です。
逆にガジェット通信のほうは、「既存記事の全文寄稿」すなわち「許可を得たコピー記事」にもかかわらず、7割以上の割合で1位獲得、それ以外の場合でも2位というすばらしい結果です。
独自コンテンツがコピーコンテンツに負ける悲しい現実がここにあります。
googleはあくまで有用なコンテンツを優遇する
なぜこんなことが起きるかというと、それはgoogleがユーザーを重視しているからです。
googleにとってユーザーというのは検索する人です。決してコンテンツを作る人たちではありません。
検索に対するニーズって言うのはいつの時代でも「1分1秒でも速く使える情報を速く探してね♪」です。「オリジナルを探してね」ではないはずです。
つまり、検索する人にとっては有用>独自なんです。
「有用」と「独自」のうちgoogleは「有用」をより重視しているはずです。
普通はオリジナル記事こそ最も高評価
とはいっても、タイトルも内容もそっくりな複数の記事がある場合、googleも大抵はオリジナル記事を最も高く評価します。
「どれがオリジナル記事か」は、記事が公開された日時などでかなり正確に判定できるようです。
ほとんどのコピー記事は検索結果にすら表示されません。
ところが著名なサイトが相手だと…
しかし、コピー記事が著名なサイトに掲載された場合、オリジナル記事よりも検索結果の上位に表示されることがあります。
これは、googleがオリジナル記事の判定を間違えたからではありません。オリジナル記事を正しく把握していながらも、著名なサイトに掲載されたコピー記事のほうを高く評価しているのです。
ウェブシュフは、ブロガーとしては「ふざけるな!!」と思います。
でも、一般に人というのは、同じ内容のコンテンツであれば、著名な媒体から発信されたものほど信用し有用だと評価する傾向があるからです。検索ユーザーとしてのウェブシュフにもそういう性癖が多少ともあるのは否めません。
googleが検索ユーザーの立場に立っているなら、この傾向を取り入れて、ガジェ通などの有名サイトに掲載された「全文寄稿」記事を高く評価するのは当然であるとも感じます。
検索結果から消える可能性も
しかし、問題は、「全文寄稿」がオリジナルより高く評価されるという程度ではすまないことが多いということです。
記事タイトルでの検索結果が、「全文寄稿」が1位でオリジナルが2位という程度なら、寄稿したブロガーとしては許容範囲だと思いますが、実際には20位以下になることが多いようです。
こうなると検索エンジンからのアクセスは全く見込めず、Googleからペナルティーを受けたも同然です。
寄稿先からの流入はわずか
ところで、ガジェ通などの有名メディアに寄稿するとき、思わず期待してしまいそうなのが寄稿先からのアクセスです。
しかし、「全文転載」では一向に期待できません。
[img-link url=”http://d.hatena.ne.jp/hagex/20121217/p10″ title=” ガジェット通信に記事を転載されたが……! – Hagex-day info”]…少なすぎです。たとえ僅かずつでもかなりの長期間にわたって期待できる検索エンジンからのアクセスを犠牲にするには、あまりにも少ないです。
既存記事の全文転載はSEO的自殺行為
そういうわけで、ガジェ通などの大手メディアに既存記事を全文丸ごと寄稿するのはSEO的には自殺行為です。
SEO的なデメリット無しで大手メディアに出たいなら、以下の方法が無難かと思います。
- 元記事へのリンク付きで記事の一部転載のみ認める
- 本来の意味での寄稿依頼が来るように精進する
最後に
なお、以上の内容はグーグルに確認しようがないという意味で妄想の域を出ません。ご利用は自己責任で。
-
【WordPressサイト限定】リダイレクトのための.htaccessへの記述を表計算ソフトとget_postsで効率化
前の記事で、WordPressのパーマリンク構造を変更した話をしましたが、そのときに避けて通れないのが面倒なリダイレクト作業です。しかし、ExellやOpenOfficeなどの表計算ソフトとget_posts関数を使えば、リダイレクト作業はある程度効率化できます。リダイレクトとは
リダイレクトは、あるURLへのアクセスを自動的に別のURLに転送する仕組みのことです。
サイトのコンテンツのURLを変更した際、以前のURLから現在のURLに転送する手段としてよく利用されます。
以前のURLから現在のURLにリダイレクトを行うには、以前のURLのドメイン直下に置いた.htaccessに、以下のような記述をしないといけません。
「Redirect permanent」+「半角スペース」+ (以前のURLのうち「http://ドメイン」を除いた部分)+「半角スペース」+ (「http://ドメイン」を含む現在のURL)
たとえば、http://example.com/test/start/のURLをhttp://example.com/end/goal/に変更したときは、http://example.com/.htaccessに以下のように記述します。
Redirect permanent /test/start/ http://example.com/end/goal/このように、変更前のURLと変更前のURLを並べればいいので、リダイレクトの記述は簡単ですね。
ただ、変更前のURLには「http://ドメイン」を含まないことには注意しましょう。
作業用下書き投稿を用意
ここから、実際に作業に入ります。後々のためにパーマリンク構造変更前のURLを取得したいのですが、この作業は、下書きの投稿を作業台として行います。
作業台の作成
まず、管理画面で「投稿」→「新規追加」の順にクリックして「投稿の編集」画面に行きます。
次に、適当なタイトルをつけて「下書きとして保存」ボタンを押してください。
作業台のID
これで、作業台は完成です。このとき、作業台にしている下書き投稿の投稿のIDを確認しておいてください。IDはアドレスバーの?post=直後の数字です。以下の画像の例では、IDは755になります。

パーマリンク構造変更前の各投稿のURLを取得
次に、使用しているテーマのsingle.phpを、管理画面のテーマ編集やテキストエディタで開いてください。(single.phpがなければ投稿を表示するのに使うテンプレートファイルを開いてください。)
single.phpの末尾に以下のコードを貼り付けてください。
<?php if(is_single('○○')){?> <ul> <?php global $post; $args = array( 'numberposts' =>10000); $myposts = get_posts( $args ); foreach( $myposts as $post ) : setup_postdata($post); ?> <li><?php the_permalink(); ?></li> <?php endforeach; ?> </ul> <?php } ?>そして、「○○」を、先ほど確認したIDに書き換えて保存します。(テキストエディタで編集した場合はFTPアップロードも忘れないでください。)
そして、作業台にしている下書き投稿のプレビューを押すと、

パーマリンク構造変更前の各投稿URLの一覧リストが現れます。

このURLの一覧リストはすべてコピーしてください。表計算ソフトにコピペ
ここで、表計算ソフトを立ち上げます。表計算ソフトは、ExellでもOpen OfficeでもGoogle Driveのスプレッドシートでもかまいません。
ここで表計算ソフトを使うのは、以下のような形でセルを埋めることで、リダイレクトの記述を効率的に作成するためです。

表計算ソフトが立ち上がったら、先ほどコピーしたURLリストをC1セル(一番上の行の左から3番目のセル)に貼り付けてください。
すると、以下のような感じになります。(画像はGoogle Driveのスプレッドシート)

置換機能で「http://ドメイン」を取り除く
次に、表計算ソフトの置換機能で「http://ドメイン」を取り除きます。
Google Driveのスプレッドシートを使っている場合は、「編集」→「検索と置換」の順にクリックすると以下のようなウィンドウが開きます。
検索:のところに「http://ドメイン」を入力し、置換:のところは空欄にします。

そして、「すべて置換」を押すと、「http://ドメイン」の部分(https://webshufu.com)がすべて消えます。

これで、リダイレクトの記述のうち、C列(以前のURLのうち「http://ドメイン」を除いた部分)については、完成しました。Redirect permanentと半角スペースを挿入
リダイレクトの書式は以下の形でした。

C列が完成したので、A・B・D列を入力します。ただし、入力は、C列のセルに(以前のURLのうち「http://ドメイン」を除いた部分)が入力されている場合のみ行います。- A列には「Redirect permanent」を入力
- B列・D列には半角スペースを入力
コピペなどを駆使するとあっという間に終わりますよね。すると、以下のように、リダイレクトの記述はE列を除いて完成します。

パーマリンク構造を変更
ここで、ワードプレスの管理画面に一旦戻って、パーマリンク構造を適宜変更します。
パーマリンク構造変更後の各投稿のURLを取得
パーマリンク構造変更後、作業台にしている下書き投稿のプレビューを再度表示し、最新の内容に更新してください。
すると、各投稿のURLの一覧が、パーマリンク構造の変更を反映したものになっているはずです。
このURLの一覧リストはすべてコピーしてください。
表計算ソフトにコピペ
コピーしたURLリストを表計算ソフトのE1セルに貼り付けてください。すると、リダイレクトの記述がほぼ完成します。(下の図はGoogle Driveのスプレッドシート)

.htaccessにコピペ
あとは、表計算ソフト上の記述を.htaccessにコピペするだけです。
リダイレクトの記述をすべてコピー
表計算ソフト上で、Ctrl(コントロール)キーとAキーを同時に押してリダイレクトの記述を全選択後、Ctrl(コントロール)キーとCキーを同時に押してコピーします。
.htaccessに貼り付け
テキストエディタで、新規ファイル作成を選択した後、Ctrl(コントロール)キーとVキーを同時に押して、コピーしておいた内容を貼り付けます。そして、.htaccessという名前をつけて、保存します。
.htaccessをドメイン直下にアップロード
最後に、保存した.htaccessファイルを、FTPソフトでドメイン直下にアップロードします。
これで、リダイレクトの記述が完成しました。
-
XAMPP上にWordPressを設置後、TOP以外のページが表示されない場合の対処法

XAMPPにwordpressのローカルテスト環境を作ると、トップページ以外の全ページが、何故か「Object not found!」となって、表示されなくなる場合があります。その解決法の備忘録です。 (さらに…) -
googleカスタム検索窓の設置手順
以前にTwentyTwelveのヘッダーにgoogle検索窓とsocialbuttonを設置という記事を書いたのですが、「検索窓を設置するためのコードがわからん」というお声を頂きました。そこで、googleカスタム検索窓の設置手順を書きます。
アカウント作成・ログイン
Googleに行って、右上の「ログイン」ボタンを押す。
アカウントを持っていない人
次の画面で、右上の「アカウント作成」ボタンを押し、必要事項を記入します。
登録したメールアドレスに重要情報が届くのでこれらを利用してログイン。
アカウントを持っている人
メールアドレスとパスワードを入力してログイン
カスタム検索エンジン作成
googleカスタム検索に行って「カスタム検索エンジンの作成」をクリック。すると下のような画面になります。

①名前:適当
②説明:適当
③言語:日本語が無難
④検索するサイト:「検索対象ドメイン/」と打ち込みます。たとえば、当サイトを検索対象にするなら「webshufu.com/」と入力します。
⑤エディション:ただがいいならスタンダード。そして、「次の利用規約を読んだうえで同意します」にチェックを入れて「次へ」を押すと下のような画面になります。

好きなデザインを選んで、「次へ」をクリックします。すると以下のようにコードが表示されます。

これをコピーして、検索窓を設置したい場所に、貼り付けると検索窓の設置が完了します。しかし、このままだと検索窓のサイズや位置の細かい調整が出来ません。そこで…
検索要素 V1 コードに切り替え
先ほどのコードの下の方にある「基本」というリンク文字をクリックします。

次の画面でサイドバーのコード取得をクリック。

すると、「検索要素 V1 コードに切り替え」の文字が画面下の方に現れるのでクリックします。

次の画面に現れているコードをコピーして、検索窓を設置したい場所に貼り付けます。

これで、サイズや位置の細かい調整が出来るようなgoogleカスタム検索窓を設置できるようになりました。