IE11対応が辛い、というときの一つの切り札として.
Moving users to Microsoft Edge from Internet Explorer - Microsoft Edge Development | Microsoft Docs
Microsoftの https://edge.microsoft.com/neededge/v1 にて、EdgeにリダイレクトしてほしいURLが管理されており、このURLをIE11で開くとブラウザ側でIEには非対応な旨の表記がされる。
出典元のページにもあるが、必要情報を記入して指定されたMicrosoftのメールアドレスへ連絡をすることで審査がされ登録されるとのこと。
Mixed Contentsが指すものは何で、何が問題なのか。
MDNの説明が的確なので引用すると以下
ユーザが HTTPS を通じてページにアクセスすると、ユーザとウェブサーバとの接続は TLS で暗号化され、盗聴や中間者攻撃から保護されます。HTTPS のページの中に通常の平文の HTTP で送られてくるコンテンツが含まれている場合、混在コンテンツと呼ばれます。このようなページは部分的にしか暗号化されておらず、盗聴者や中間者攻撃者が暗号化されていないコンテンツにアクセスできてしまいます。つまり、ページは安全ではありません。 -混在コンテンツ - ウェブセキュリティ | MDN
例えば、ページそのものがhttpsでやり取りされているが、その中のimgタグやsrcタグなどで指定されているURLがhttpであったりする場合がこれにあたる。
ひとつのページ内にhttpとhttpsが混在すると、ページ上はhttpsで通信しているため秘匿されていると思いきや、個々の要素の取得がhttpで通信していることでその通信で秘匿情報（ブラウザが通信時に等しくheaderに入れるような情報やcookieなど）が漏れ出してしまう危険があるため、「パッと見としては安心できそうだが実は安全ではない」という状態が作られてしまう。
そのため、各ブラウザはこの混在する状態が発生しないように対応をしており、それが副次的な問題となる。
各ブラウザ（Chrome,Firefox,Edge,Safari）はMixed Contentsとなる状態を現状許容をしていない。
そのためhttpsのページ内にhttpで記述されたものがあればそのコンテンツは取得できない、もしくは処理ができない状態となる。このため利用するユーザからすると一部の情報が見えない歯抜けの状態となり、コンテンツ提供として問題が発生する。
Mixed contentsは何度も記載したとおり、httpsのページにhttpに内容をソースとする記述があることが問題なので、ちゃんとページ内で利用するリソースに関してはちゃんとhttpsで統一することで回避できる。
知らなかったのでメモ。
Terms & Conditions – DoubleClick for Publishers – Small Business
Using the Program, You are permitted to serve without charge up to (A) (i) 90 million impressions per month to non-video ad units if You are located in the United States of America, Canada, Australia, or New Zealand; (ii) 200 million impressions per month to non-video ad units if you are located in the Russian Federation, Slovakia, Czech Republic, Greece, Slovenia, Lithuania, Romania, Poland, Ukraine, Hungary, Croatia, Bosnia and Herzegovina, Cyprus, Kenya, Morocco, Estonia, Latvia, Bulgaria, Turkey, Lebanon, Israel, United Arab Emirates, Saudi Arabia, Egypt, South Africa, Mexico, Argentina, Chile, Columbia, Guatemala, Uruguay, Peru, India, Taiwan, Malaysia, Korea, Hong Kong, Indonesia, Pakistan, Thailand, Philippines, China, Vietnam, Bangladesh, or Sri Lanka; or (iii) 150 million impressions per month to non-video ad units if You are not located in any of the countries listed in the preceding clauses (i.e., clauses (A)(i) and (A)(ii)); and (B) 800,000 video advertisement impressions per month (collectively (A) and (B), "Impression Limits").
上の内容を噛み砕いて無償枠の話を読み解くと
ということになり、日本は一番最後のものに該当するので、1億5千万回までとなる。
仕様が単一にまとまっているものではないので、利用できるものをまとめる
今回焦点を当てるのは Google と Bing 。
YahooJapanはすでにGoogle検索を利用しているので今回は考慮しない。
| 値 | 説明 | Bing | |
|---|---|---|---|
| all | インデックスの登録に制限を設けない。既定値。 | ○ | ? |
| noindex | 検索結果のインデックスに登録させない。 | ○ | ○ |
| nofollow | ページ内のリンク情報を辿らせない。（どういうことかは関連リンク参照） | ○ | ○ |
| noarchive | 検索結果にキャッシュ表示をさせない | ○ | ○ |
| nosnippet | 検索結果にてサムネイルやページのプレビューを生成させない | ○ | ○ |
| max-snippet: [number] | 検索結果にてテキストスニペットに使われる最大文字数をnumberに設定できる。0の場合はnosnipepetと同義、-1を指定すると特段リミットを設定しません。 | ○ | ○ |
| max-image-preview: [setting] | 検索結果のページプレビューサイズに関して設定をすることができる。 none が 画像プレビューを表示させない、 standard はデフォルトのサイズ、large はスタンダードと同等かそれ以上に大きいサイズをプレビュー表示させます。 |
○ | ○ |
| max-video-preview: [number] | 検索結果で動画を表示する際の最大秒数をnumberに設定できる。0を指定すると動画は使わず静止画となり、-1を指定すると制限は特にかけないことになる | ○ | ○ |
| noodp | Open Directory Projectに登録させない記述だが、プロジェクト自体が2017年に運用が停止しているのでGoogleでは意味のあるタグとして認識されなくなった。 | - | ○ |
| nocache | noarchiveと同義 | - | ○ |
| none | noindexとnofollowを同時指定（ noindex,nofollow )と同義 |
○ | - |
| notranslate | 検索結果でこのページを翻訳させない | ○ | - |
| noimageindex | 検索結果で指定されたページの画像をインデックスさせない | ○ | - |
| unavailable_after: [date/time] | 検索結果に、date/timeで指定した日時以降は表示させない | ○ | - |
標準的な記述方法は以下
<meta name="robots" content="noindex">
複数のものを指定したい場合は , で並べる
<meta name="robots" content="noindex,noarchive">
リダイレクトの仕方次第ではページ評価が下がるのでは、というところでそこに関する内容をまとめる
とあるページが移転したときにリダイレクトとして
window.location.href('https;//example.com') のような記述）この2つの方法において、Googleからの評価は同等であるか？ということ
Googleに不正なリダイレクトに関しての記述がある
不正なリダイレクト | 検索セントラル | Google Developers
その中に以下の記述がある
JavaScript を使用したリダイレクトが正当な行為にあたる場合もあります。たとえば、ユーザーのログイン後に内部ページにリダイレクトする場合は、JavaScript を使用しても問題ありません。JavaScript やその他のリダイレクト手法を使用したサイトが Google のガイドラインに沿っているかどうかを確認する際には、その目的を考慮してください。サイトの移転にあたっては 301 リダイレクトが最適ですが、ウェブサイトのサーバーにアクセスできない場合は、この目的で JavaScript によるリダイレクトを使用することもできます。
とのことで、明確に同列とは語られてはいないが、JavaScriptで対応することで不利になるような話は書いていない
Googleの検索周りの質問などに答えるジョンミューラーがQuestionに答える#AskGoogleWebmastersの動画内で問答があった。
上記の動画では
Can Google evergreen Chromium detect client-side Javascript redirects? I'm not able to submit GSC indexing request to pages tha have client-side JS redirect to a subscription page.
というchromium製のbotになったときにJSのリダイレクトは検知できるかという質問だったが、この中でサーバーのリダイレクトと同等に追跡できるとしている。
ドキュメントとしての側面、Google側の案内としての側面からしてもサーバーリダイレクトの評価とJSでのリダイレクトの評価に差異がないような作りとして考えて問題がないと思われる
Asia/Tokyo 等の文字列定義ってどこにあるのかを調べる。
上記のページに記載がある
The Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules.
機械的に和訳すると以下
タイムゾーンデータベース（tzまたはzoneinfoと呼ばれることが多い）には、世界の代表的な多くの場所のローカルタイムの歴史を表すコードとデータが含まれています。このデータベースは定期的に更新され、タイムゾーンの境界、UTCオフセット、サマータイムのルールなど、政治的機関による変更を反映しています。
上記の出典ページに行くと、タイムゾーンデータが固められた圧縮ファイルがあり、その中に各タイムゾーンの定義情報が格納されている。
なお、管理をどのように行うかはRFCにまとまっている。
RFC 6557: Procedures for Maintaining the Time Zone Database
ファイルの情報が一次ソースではあるが、wikipediaにリスト状で見れる形になっているので、探すときはこちらの方便利
List of tz database time zones - Wikipedia
「レビュー後に修正したやつがapproveしてないのにマージされている！！！」みたいのを防ぐための設定
ブランチのTOP > Settings > Branches > Add rule のボタンを押すとブランチ運用のルールを設定できる。
その中でブランチのマージに必要な最低人数を設定できる設定があるが、そこに加えて
Dismiss stale pull request approvals when new commits are pushed
というルールがあり、これが有効化されていると、コミットが修正されるとapproveしている状況が強制的に解除される。
公式ドキュメントから画像を転載すると以下の部分を設定すると反映される。
