Кэш сайтов гугл: Sorry, this page can’t be found.

Google и другие поисковые системы загружают и сохраняют копии проиндексированных веб-страниц. Если веб-страница не работает, вы можете легко просмотреть последнюю копию, сохраненную в кеше Google.

Если вы пытаетесь получить доступ к веб-странице из поиска Google, доступ к кешированной копии получить довольно легко. Просто нажмите кнопку «Назад» в веб-браузере, когда веб-страница не загружается. Нажмите стрелку справа от адреса веб-страницы и нажмите «Сохраненная копия», чтобы просмотреть старую копию.

Если страница загружается долго, вы можете нажать ссылку «Только текст» в верхней части кешированной страницы. Веб-страница загрузится мгновенно, но вы не увидите никаких изображений. Это необходимо, когда сервер веб-сайта отключен, и ваш браузер не может загружать изображения веб-страницы.

Вы также увидите дату и время, когда Google создала эту кэшированную копию, отображаемую в верхней части страницы.

Также есть быстрый способ просмотра кэшированной копии Google любой веб-страницы без предварительного поиска в Google.

Просто подключите следующий адрес в адресную строку, заменив site.ru/page.htm полным адресом веб-страницы, которую вы хотите.

http://webcache.googleusercontent.com/search?q=cache:
site.ru/page.htm

Не забудьте убрать «http: //» или «https: //» из начала адреса веб-страницы. Итак, если вы хотите посмотреть копию данной страницы, просто скопируйте в адресную строку следующий адрес (предварительно убрав пробел и копирайт):

http://webcache.googleusercontent.com/search?q=cache: 
juice-health.ru/internet/606-dostup-k-veb-stranice

Если вы получаете ошибку 404 значит такой страницы в кэше пока нет.

Хотя тут я рассказал про Google Cache, поисковая система Яндекс также имеет свою подобную функцию. Если вы используете Яндекс, вы также можете щелкнуть стрелку справа от адреса и нажать «Сохраненная копия», чтобы просмотреть копию из кеша Яндекс.

Интернет-архив Wayback Machine также позволяет просматривать старые копии веб-страницы. В тех случаях, когда Google Cache предлагает вам только одну, самую последнюю сохраненную копию, Wayback Machine предлагает несколько старых версий веб-страницы, возвращающихся гораздо дальше, чтобы вы могли видеть, как выглядела веб-страница несколько лет назад.

Чтобы использовать Wayback Machine, перейдите на страницу https://web.archive.org. Вставьте полный адрес веб-страницы, которую вы хотите просмотреть, в поле и нажмите «Обзор истории». Например, вы можете скопировать и вставить этот адрес из адресной строки вашего браузера, если веб-страница не загружается.

Если вы просто хотите просмотреть последнюю сохраненную в кэше копию веб-страницы, вы можете нажать на дату в верхней части страницы архива.

Если вам нужна более старая копия, вы можете выбрать год и нажать дату в календаре, чтобы просмотреть веб-страницу, как она выглядела в эту дату.

Вы можете щелкнуть ссылки, которые появляются на странице после загрузки, чтобы просмотреть другие веб-страницы по мере их появления в эту дату. Этот инструмент позволяет просматривать целые веб-сайты, которые исчезли или сильно изменились.

Возможно, вы также слышали о CoralCDN (в последнее время не всегда работает). CoralCDN особенно полезен для просмотра кэшированных копий веб-страниц, которые оказались недоступны из-за внезапного высокого трафика. Вышеупомянутые два инструмента должны помочь вам получить копию любой страницы за любое время.

Читайте также

Очистка кэш редиректов в Google Chrome браузере и не только

В веб-разработке бывают моменты, когда ты, вроде бы, все делаешь правильно, но глюк на сайте не проходит. Кэш браузера – наверное, один из самых популярных подобных нюансов. Недавно я столкнулся с некой вариацией этой проблемы – оказывается Chrome и остальные веб-браузеры, кэшируют информацию о редиректах. Так что, если вы настраиваете 301 редирект, а ничего не происходит, возможно, проблема именно в этом. Сегодня разберемся как очистить кэш редиректов Google Chrome без удаления всех данных.

Само по себе автоматическое кэширование в браузерах – штука полезная, но в ходе разработки вебсайтов, есть смысл его отключать, т.к. ты постоянно вносишь какие-то правки, и каждый раз чистить кэш хлопотно. Обычно в таких ситуациях хватает нажатия Ctrl+F5 (для CSS-стилей так точно), но с редиректами эта фишка, почему-то не прокатывает. Chrome и другие локально сохраняют информацию о них на какое-то время и повторный HTTP запрос не будет отправляться для того же URL.

В общем, столкнувшись в очередной раз с этой проблемой, нашел полезную статью по теме где собраны все возможные варианты решения текущей задачи. Ими и поделюсь ниже.

Режим Инкогнито

Наиболее простой подход – использовать Incognito Mode, очищающий кэш браузера каждый раз после его закрытия. Преимуществом метода можно назвать то, что он применим для всех популярных нынче программных продуктов, т.к. есть и в Opera, и Firefox.

В Хроме его включить можно следующим образом:

К сожалению, работа в данном формате не решает проблему в “основном” веб-браузере. В таком случае есть смысл рассмотреть какой-то из вариантов ниже. Кстати, Incognito-режим можно использовать для посещения сайтов по типу TopCasinoExpert и других из этой тематики, которые недоступны в некоторых странах.

Очистка всего кэша

Самый радикальный метод – вообще удалить весь кэш. Для его реализации в Google Chrome нужно:

1. Зайти в меню – выбрать “Настройки” (Settings) – в самом низу страницы будет опция “Дополнительные” (Show advanced settings).

2. После клика увидите доп.параметры, где в блоке «Конфиденциальность и безопасность» (Privacy) ищете опцию «Очистить историю» (Clear browsing data…).

3. При нажатии на этот пункт меню появится всплывающее окно, в котором обязательно надо отметить пункт “Изображения и другие файлы, сохраненные в кеше” (Cached images and files).

Остальные отметки активируете по желанию в зависимости от того, какую именно инфу вы хотите удалить. Также разрешается выбрать временной диапазон: последний час, 24часа, 7дней, 4недели или за всем время.

4. После задания параметров нажимаете на кнопку “Удалить данные”.

В данном случае вместе с очисткой кэша редиректов в Google Chrome удалится и другая информация, отмеченная вами. Кроме того, действие применится ко всем абсолютно сайтам, а не только к тому, над которыми работаете. Поэтому есть смысл использовать более “тонкий” подход.

Удаление кэша браузера для отдельного URL

Кроме Chrome метод подходит и для Firefox, IE, Edge (алгоритм действий там аналогичный). Преимущества также в том, что все изменения применяются только к конкретному сайту/URL. Вот что нужно сделать:

1. Нажимаете SHIFT+CTRL+I дабы открыть инструменты разработчика Chrome Devtools (о которых я уже когда-то рассказывал).

2. Переходим во вкладку “Network”, где отмечаем галочку “Disable cache”. Важно! Инструмент должен быть открытым все это время иначе выполнить следующие шаги у вас не получится.

3. Затем в адресной строке браузера вводите URL-адрес сайта и нажимаете Enter.

4. Нажимаете на иконку обновления страницы и удерживаете ее пока не появится всплывающее окно. В нем кликаете по пункту “Очистка кэша и жестка перезагрузка” (Empty Cache and Hard Reload).

5. Сразу после того, как страница веб-сайта будет перезагружена, вы можете снять метку возле опции “Disable cache” в инструментах разработчика.

Используем Chrome Fetch API

Это слегка “экзотический подход”, но тоже работает. Вам надо:

1. Перейти на сайт www.google.com или любой другой с non-restrictive CORS policy (если честно хз, что это, поэтому остановлю выбор на Гугле).

2. Нажимаете сочетание клавиш SHIFT+CTRL+J для открытия консоли Google Chrome.

3. Далее в ней пишете следующий код:

fetch('https://www.вашсайт.com', {method: 'post'}). then(() => {})

fetch(‘https://www.вашсайт.com’, {method: ‘post’}).then(() => {})

Разумеется, в данном примере нужно заменить URL сайта на свой (обратите внимание, что ссылка пишется полностью с https/http.

Итого. Если говорить о текущей задаче, то очистить кэш в Google Chrome для редиректов мне помог третий вариант. Последний не пробовал, но пару человек из оригинальной статьи подтвердили его работоспособность. Что касается всех остальных ситуаций (обновить CSS файлы, например), то для этого хватает классического Ctrl+F5. Хотя, мне кажется, есть смысл вообще отключать кэширование браузера в ходе веб-разработки. Что думаете по этому поводу?

Как кэшировать сайт в Google | Small Business

Поисковая система Google основана на результатах, которые Googlebot или пауки генерируют при сканировании Интернета. Ссылки на ваш сайт или ссылки на вашем сайте на другие сайты помогают Google найти ваш сайт и кэшировать его «естественным образом», чтобы они могли его проиндексировать. Чтобы ускорить этот процесс или обновить кеш для вашего веб-сайта, потому что вы изменили много контента, Google предлагает способ отправить им свой сайт, чтобы индексация и кеширование происходили быстрее.Таким образом клиенты могут получить доступ к текущей информации на вашем сайте через кеш Google, даже если ваш сервер временно отключится.

Использование Google’s Webmaster Tools

Войдите на веб-страницу Google Webmaster Tools, используя свою учетную запись Google (ссылка в разделе «Ресурсы»).

Щелкните сайт в списке, который вы хотите, чтобы Google кэшировал. Если у вас нет сайта в вашем списке, нажмите кнопку «Добавить сайт» и введите сайт в поле всплывающего диалогового окна.Нажмите кнопку «Продолжить» и пройдите один из процессов проверки, чтобы доказать, что вы управляете этим сайтом или являетесь его владельцем.

Щелкните раскрывающееся меню «Состояние», выберите «Просмотреть как Google» и введите в поле страницу своего веб-сайта, которую Google должен сканировать. URL сайта уже напечатан перед полем. Чтобы Google кэшировал главную страницу вашего сайта, оставьте поле пустым.

Нажмите кнопку «Получить» и разрешите роботу Googlebot сканировать сайт. После успешного сканирования нажмите кнопку «Отправить в индекс» и «ОК» в появившемся диалоговом окне.Google обновляет кеш для новых страниц, которые еще не просканированы, и страниц, которые изменились с момента последнего сканирования. Таким образом Google позволяет получать 500 страниц в неделю и 10 страниц с включенными ссылками.

Использование Google’s Public Site Submission

Перейдите на веб-страницу Google Crawl URL (ссылка в разделе «Ресурсы»).

Введите полный URL-адрес сайта, включая «http: //», в поле.

Введите два слова в поле CAPTCHA и нажмите кнопку «Отправить запрос».

Ссылки

Ресурсы

Советы

• Если у вас есть новый сайт, который Google должен добавить в свой индекс, вы также можете отправить для него карту сайта в Инструментах Google для веб-мастеров.

Предупреждения

• Google не дает никаких гарантий относительно того, сколько времени потребуется для индексации и кеширования вашего сайта.

Писатель Биография

Марисса Роберт окончила Университет Бригама Янга по специальности английский язык и литература.Она имеет большой опыт написания маркетинговых кампаний, бизнес-справочников и руководств, а также написания, корректуры и редактирования внештатных писем. Живя во Франции, она переводила рукописи на английский язык. Она публиковала статьи на различных веб-сайтах, а также периодически ведет два блога.

Как найти старые веб-сайты и выполнить поиск по кешированным страницам Google

Что нужно знать

• Способ 1. Найдите слово или веб-сайт. В результатах поиска щелкните треугольник над заголовком страницы и выберите в меню Кэшировано .
• Метод 2: Введите cache: [название сайта] в поле поиска строчными буквами без пробелов и нажмите Введите .

Есть два способа просмотреть кешированную версию страницы в Google. Выполните регулярный поиск на сайте для настольных компьютеров, а затем откройте оттуда кешированную версию или добавьте одно слово в поиск Google на настольных или мобильных сайтах, чтобы немедленно открыть кешированную версию.

Выполните обычный поиск в Google

Использовать обычный поиск Google для поиска кэшированной страницы так же просто, как выполнить обычный поиск и затем щелкнуть ссылку в результатах поиска, чтобы открыть кешированную страницу.

1. Найдите слово, фразу или весь веб-сайт.

2. Найдите в результатах конкретную страницу, для которой вам нужна кешированная версия.

3. Щелкните треугольник над заголовком страницы и выберите Кэшировано .

При нажатии на ссылку Cached часто отображается страница в том виде, в котором она была в последний раз проиндексирована в Google, но с выделенными ключевыми словами для поиска. Этот метод чрезвычайно полезен, если вы хотите найти конкретную информацию без необходимости сканировать всю страницу.

Если поисковый запрос не выделен, используйте сочетание клавиш Ctrl + F (Windows) или Command + F (Mac), чтобы найти слово (слова).

Прямо в кэш

Вместо этого вы можете перейти к делу и перейти непосредственно к кэшированной странице, добавив cache: непосредственно перед поиском Google.

1. Откройте новое поле поиска Google и введите cache: (включая двоеточие).

2. Введите URL-адрес страницы, для которой вы хотите увидеть кешированную версию. Например, введите cache: lifewire.com строчными буквами без пробелов. Не используйте стандартные «http» или «https», которые появляются в начале URL-адресов.

3. Нажмите Введите , чтобы сразу открыть кешированную страницу.

Когда Google индексирует веб-страницы, он сохраняет снимки их содержания, известные как кэшированные страницы.URL-адреса периодически обновляются новыми кэшированными изображениями. Используйте этот трюк с мощным поиском Google, чтобы открыть кэшированное изображение страницы и найти нужную информацию.

Ограничения кешей

Имейте в виду, что в кеше отображается время последней индексации страницы, поэтому иногда изображения не отображаются, и информация будет устаревшей. Однако, в зависимости от того, что вы ищете, это может не вызывать беспокойства.

Некоторые страницы инструктируют Google с помощью протокола, называемого robots.txt, чтобы сделать исторические страницы недоступными. Дизайнеры веб-сайтов также могут сделать страницы закрытыми от результатов поиска Google, удалив их из индекса сайта (также известное как «запрет на индексирование»).

Google хранит только самый последний кеш страницы, поэтому, если вы пытаетесь получить доступ к действительно старой странице — возможно, к той, которая сильно изменилась или долгое время находилась в автономном режиме, — попробуйте Wayback Machine.

Спасибо, что сообщили нам!

Расскажите, почему!

Как использовать кеш Google для восстановления веб-страницы

В случае, если вам нужно восстановить файл, а у вас нет локальной резервной копии, вы можете использовать кеш Google в качестве альтернативы.

Когда Google сканирует ваш сайт, он делает снимок вашей страницы. Этот снимок показывает, как выглядел ваш сайт, когда Google его просканировал, и доступен для просмотра с помощью ссылки «Сохранено в кеше» в результатах поиска Google. Короче говоря, при восстановлении страницы с использованием кеша Google используется HTML-код, сохраненный Google при сканировании вашего сайта, для восстановления файла, который вам нужно восстановить.

Обратите внимание: :
Действия, описанные ниже, не гарантируются. Этот метод рекомендуется использовать только в крайнем случае.Кеш Google не будет работать на php или других страницах с использованием сценариев на стороне сервера, поскольку Google не может видеть ваш php-код, а только сгенерированный html.

1. Найдите в Google site: example.com . Обязательно замените example.com своим доменным именем и не вставляйте пробелов между site: и example.com.
2. Вы увидите список всех страниц, просканированных Google и находящихся на сайте example.com. Щелкните ссылку Cached рядом со страницей, которую необходимо восстановить.
3. Вверху страницы Google отобразит сообщение, подобное следующему:

Это кеш Google https://www.example.com/. Это снимок страницы, появившейся 14 декабря 2009 г. в 22:29:21 по Гринвичу.

Указанная дата снимка — это дата, когда Google просканировал ваш сайт. Если ваша страница правильно отображается под этим сообщением, вы можете использовать HTML-код в кеше Google, чтобы попытаться восстановить файл.

Посмотреть исходный код страницы.В большинстве браузеров вы можете щелкнуть правой кнопкой мыши и выбрать View Page Source. Исходный код — это HTML-код, который используется для отображения вашего веб-сайта. Выберите весь код в источнике страницы и скопируйте / вставьте его в тестовый файл в своей учетной записи. Например, если вы пытаетесь восстановить index.html, поместите код в файл с именем index_test.html. Google добавляет несколько строк вверху страницы, поэтому вам нужно удалить первые несколько строк кода вверху. Эти первые несколько строк — это то, что Google использует для отображения информации вверху кэшированной страницы, например, даты снимка.

4. Протестируйте новый файл в своем браузере. В этом примере вы хотите протестировать example.com/index_test.html. Если эта версия вашей страницы в кеше Google подойдет вам, переместите исходный файл в сторону и вместо этого поместите тестовый файл на место. В этом примере вы должны переименовать index.html во что-нибудь еще, например index.html.bak, а затем переименовать тестовый файл index_test.html в index.html.

Обзор кэширования | Cloud CDN | Google Cloud

Кэшируемый ответ — это HTTP-ответ, который Cloud CDN может хранить и быстро извлекать, что позволяет ускорить загрузку. Не все ответы HTTP кешируемый.

Режимы кэширования

В режимах кэширования вы можете контролировать факторы, определяющие, Cloud CDN кэширует ваш контент.

Cloud CDN предлагает три режима кеширования, которые определяют, как кэшируются, соблюдает ли Cloud CDN директивы кеширования, отправленные origin и как применяются TTL кеша.

Доступные режимы кэширования показаны в следующей таблице:

Инструкции по настройке см. В разделе Настройка кеша. режим.

Статическое содержимое

Статический контент — это контент, который всегда один и тот же, даже когда к нему обращается разные пользователи. CSS, который вы используете для стилизации своего сайта, JavaScript для предоставления интерактивность, видео и графическое содержание обычно не меняются для каждого пользователя в течение заданный URL ( ключ кеша ), и, таким образом, получить выгоду от кеширования через Глобальная пограничная сеть Cloud CDN.

Когда вы устанавливаете режим кеширования для кэширования всего статического контента, Cloud CDN автоматически кэширует ответы для следующего:

• веб-ресурсов, включая CSS ( текст / css ), JavaScript ( application / javascript ) и все веб-шрифты, включая WOFF2 ( font / woff2 )
• изображений, включая JPEG ( изображения / jpg ) и PNG ( изображения / png )
• видео, включая H.264, H.265 и MP4 ( видео / MP4 ) +. Аудиофайлы, включая MP3 ( изображения / MPEG ) и MP4 ( аудио / MP4 )
• Отформатированные документы, включая PDF (заявка / pdf )

В следующей таблице приведены сводные данные.

Cloud CDN проверяет заголовок HTTP-ответа Content-Type , который отражает MIME тип обслуживаемого контента.

Обратите внимание на следующее:

• Программное обеспечение веб-сервера вашего источника должно установить Content-Type для каждого отклик. Многие веб-серверы автоматически устанавливают заголовок Content-Type , включая NGINX, Varnish и Apache.

• Cloud Storage автоматически устанавливает заголовок Content-Type загружать, когда вы используете Облачная консоль или инструмент gsutil для загрузки контента.

• Если ответ кэшируется на основе его типа MIME, но имеет Cache-Control заголовок ответа private или no-store , или Set-Cookie заголовок (см. полный список правил), он не кешируется.

Cloud CDN не использует расширения файлов в пути URL для определения является ли ответ кешируемым, потому что многие действительные кешируемые ответы не отражены в URL-адресах.

Если вы хотите кэшировать типы содержимого text / html и application / json , вы должны установить явные заголовки Cache-Control в ответ, будучи осторожно, чтобы случайно не кэшировать данные одного пользователя и не передать их всем пользователям.

Кэшируемое содержимое

Cloud CDN кэширует ответы, которые соответствуют всем требованиям в эта секция. Некоторые из этих требований указаны в RFC. 7234, и другие специфичен для Cloud CDN.

Cloud CDN может периодически изменять точный набор условий при который кэширует содержимое.Если вы хотите явно запретить Cloud CDN от кэширования вашего контента, следуйте рекомендациям в RFC 7234, чтобы определить, как указать гарантированно некэшируемый ответ. Также некэшируемый контент на основе раздела исходных заголовков.

Текущая реализация Cloud CDN сохраняет ответы в кеше, если все следующее верно.

Для серверных сегментов облачного хранилища следующие способы удовлетворить эти требования:

• Сделайте вашу корзину общедоступной.Это подход, который мы рекомендуем для общедоступного контента. С этим настройки, любой в Интернете может просматривать и перечислять ваши объекты и их метаданные, исключая ACL. Рекомендуемая практика — посвящать конкретные ведра для общественных объектов. Для получения дополнительной информации см. Рекомендуемая архитектура корзины.

• Сделайте личность общедоступные объекты. Мы не рекомендуем такой подход.

По умолчанию, когда вся корзина является общедоступной или отдельные объекты общедоступные и отдельные объекты не указывают метаданные Cache-Control , Cloud Storage назначает заголовок Cache-Control: public, max-age = 3600 объект.Вы можете установить разные значения, используя Cache-Control метаданные.

Для примера, показывающего, как настроить внешний балансировщик нагрузки HTTP (S) с серверной частью ведро, см. Настройка Cloud CDN с помощью серверной части. ведро.

Максимальный размер

Cloud CDN устанавливает максимальный размер для каждого ответа. Любой ответ с тело больше максимального не кэшируется, но доставляется в клиент.

Максимальный размер зависит от того, поддерживает ли исходный сервер байт. диапазон запросов.

Почти все современные веб-серверы (включая NGINX, Apache и Varnish) поддерживают запросы диапазона байтов.

Некэшируемый контент на основе исходных заголовков

Есть проверки, блокирующие кеширование ответов.Cloud CDN может периодически менять точный набор условий, при которых он кэширует контент, поэтому, если вы хотите явно запретить Cloud CDN от кеширования вашего контента, следуйте рекомендациям стандарта (RFC 7234), чтобы определить, как указать гарантированно-некэшируемый ответ.

Текущая реализация Cloud CDN не кэширует ответ, если он не соответствует требованиям к кэшируемому контенту или, если есть из следующего верно.

Если Cache-Control: no-store или private присутствует, но содержимое все еще кэшируется, это происходит по одной из следующих причин:

• Подпись URL настроена.
• Режим кеширования Cloud CDN настроен на принудительное кэширование всех ответов.

Предотвращение кеширования

Для предотвращения кэширования личной информации в Cloud CDN кеши, выполните следующие действия:

1. Убедитесь, что режим кеширования Cloud CDN не установлен на FORCE_CACHE_ALL Режим , который безусловно кэширует все ответы.
2. Включите заголовок Cache-Control: private в ответы, которые не должны хранится в кэше Cloud CDN или в Cache-Control : no-store заголовок в ответах, который не должен храниться ни в каком кэше, даже в веб- кеш браузера.
3. Не подписывать URL-адреса, которые предоставляют доступ к частным Информация. Когда доступ к контенту осуществляется с помощью подписанного URL-адреса, он потенциально подходит для кэширования независимо от директив Cache-Control в отклик.
4. Для запросов источника (заполнения кеша), которые включают запрос авторизации заголовок, Cloud CDN кэширует только ответы, которые включают общедоступный , необходимо повторно проверить директивы управления кешем или s-maxage , когда режим кеширования установлено значение USE_ORIGIN_HEADERS или CACHE_ALL_STATIC .Это предотвращает случайное кэширование пользовательского контента и / или контента, который требует аутентификация. Режим кеширования FORCE_CACHE_ALL не имеет этого ограничение.

С помощью настраиваемых заголовков ответов вы можете указать заголовки, которые внешний балансировщик нагрузки HTTP (S) добавляет к проксируемым ответам. Пользовательские заголовки ответов позволяют отразить кеш статус для ваших клиентов, географические данные клиентов и ваш собственный статический ответ заголовки.

Список заголовков см. В разделе «Переменные, которые могут отображаться в заголовке». значение.

Инструкции см. В разделе Работа с настраиваемым ответом. заголовки.

Ключи кэша

Каждая запись в кэше Cloud CDN идентифицируется кешем ключ . Когда запрос поступает в кеш, кеш преобразует URI запрос в ключ кеша, а затем сравнивает его с ключами кэшированных записей. Если он находит совпадение, кеш возвращает объект, связанный с этим ключом.

Для серверных сервисов Cloud CDN по умолчанию в качестве ключа кеша используется полный URI запроса.Например, https://example.com/images/cat.jpg — это полный URI для определенного запрос на объект cat.jpg . Эта строка используется как ключ кеша по умолчанию. Только запросы с этим точным совпадением строки. Запросы на http://example.com/images/cat.jpg или https://example.com/images/cat.jpg?user=user1 не совпадают.

Вы можете изменить, какие части URI используются в ключе кеша. В то время как имя файла и путь всегда должны быть частью ключа, вы можете включать или опускать любые комбинация протокола, хоста или строки запроса при настройке ключа кеша.Использование ключей кеширования описывает, как настроить ваш ключи кеша.

В дополнение к включению или исключению всей строки запроса вы можете использовать части строки запроса с помощью списков включения и списков исключения.

Для серверных сегментов ключ кеша состоит из URI без протокола, хоста или строки запроса.

Таким образом, для заданного сегмента серверной части следующие URI разрешаются в один и тот же кэшированный объект:

• http://example.com/images/cat.jpg
• https://example.com/images/cat.jpg
• https://example.com/images/cat.jpg?user=user1
• http://example.com/images/cat.jpg?user=user1
• https://example.com/images/cat.jpg?user=user2
• https://media.example.com/images/cat.jpg
• https://www.example.com/images/cat.jpg

Строка запроса включает список

Вы можете выборочно контролировать параметры строки запроса Cloud CDN включается в ключи кеша.Например, если вы создаете список включения пользователь , затем https://example.com/images/cat.jpg?user=user1&color=blue создает ключ кеша https://example.com/images/cat.jpg?user=user1 , который также соответствует https://example.com/images/cat.jpg?user=user1&color=red .

Чтобы использовать эту опцию, вы должны включить строку запроса, указать непустой список включения, а не задают список исключения.

URL с разным порядком одинаковых параметров запроса приводят к разным ключи кеша.Следующие два URL-адреса имеют разные ключи кеша, даже если они одинаковые параметры запроса:

• https://example.com/images/cat.jpg?user=user1&color=red
• https://example.com/images/cat.jpg?color=red&user=user1

Строка запроса исключает список

Вы можете выборочно контролировать параметры строки запроса Cloud CDN игнорирует, используя список исключений. Например, если вы создаете список исключений из пользователя , все параметры строки запроса , кроме пользователя , используются в ключе кеша.

С настроенным списком исключений и входом https://example.com/images/cat.jpg?user=user1&color=blue , Cloud CDN создает ключ кеша https://example.com/images/cat.jpg?color=blue , который также соответствует https://example.com/images/cat.jpg?user=user2&color=blue , но не https://example.com/images/cat.jpg?user=user1&color=red .

Чтобы использовать эту опцию, вы должны включить строку запроса, указать непустой список исключений, а не задают список включения.

Директивы управления кешем

директивы управления кешем HTTP влияют на поведение Cloud CDN, как описано в следующей таблице.

Н / Д означает, что директива не применима к запросу или ответу.

Там, где это возможно, Cloud CDN старается соответствовать RFC (HTTP RFC 7234), но поддерживает оптимизацию для разгрузки кеша и минимизирует влияние, которое клиенты могут иметь процент попаданий и / или общую исходную нагрузку.

Для ответов, использующих заголовок HTTP / 1.1 Expires :

• Значение заголовка Expires должно быть действительной HTTP-датой, как определено в RFC 7231.
• Значение даты в прошлом, недопустимая дата или значение 0 указывает, что содержание уже истекло и требует повторной валидации.
• Если в ответе присутствует заголовок Cache-Control , Cloud CDN игнорирует заголовок Expires .

Наличие действительного, будущего заголовка Expires в ответе позволяет ответ кэшируется и не требует указания других директив кеширования.

Протокол HTTP / 1.0 Заголовок Pragma , если он присутствует в ответе, игнорируется и передается клиенту как есть. Клиентские запросы с этим заголовком передаются источнику и не влияют на то, как ответ обслуживается Облачный CDN.

Модель Vary заголовок указывает, что ответ варьируется в зависимости от клиента заголовки запросов. Помимо URI запроса Cloud CDN учитывает Разные заголовки , которые исходные серверы включают в ответы. Например, если в ответе указано Vary: Accept , Cloud CDN использует одну запись кеша для запросы, которые указывают Accept: image / webp, image / *, * / *; q = 0.8 и еще один для запросы с указанием Принять: * / * .

Стол в Списки разделов некэшируемого содержимого заголовки Vary , которые позволяют кэшировать контент. Другое Изменение значений заголовка предотвратить кэширование содержимого.

Режим кэширования FORCE_CACHE_ALL не , а отменяет это поведение. Модель Vary заголовки важны, чтобы избежать заражения кеша между несколькими возможными источниками ответы сервера.Для FORCE_CACHE_ALL было бы опасно вызывать эти ответы для кеширования.

Различные заголовки иногда используются при обслуживании сжатого содержимого. Cloud CDN не сжимает и не распаковывает ответы, но может обслуживать ответы, сжатые исходным сервером. Если ваш исходный сервер выбирает следует ли обслуживать сжатый или несжатый контент в зависимости от значения Accept-Encoding Заголовок запроса , убедитесь, что в ответе указано Vary: Accept-Encoding .

Срок действия и запросы на проверку

В режиме кэширования USE_ORIGIN_HEADERS каждая запись в кэше Срок действия кэша Cloud CDN определяется параметром Cache-Control: s-maxage , Cache-Control: max-age и / или Срок действия истекает заголовки в соответствии с RFC 7234. Если присутствует более одного, Cache-Control: s-maxage имеет приоритет над Cache-Control: max-age и Cache-Control: max-age имеет приоритет над Срок действия истекает .

В режиме кэширования CACHE_ALL_STATIC к исходным заголовкам обращается по умолчанию для определения свежести. Если их нет, любой статический контент считается свежим.

В режиме кэширования FORCE_CACHE_ALL все ответы серверной части считается свежим.

Когда Cloud CDN получает запрос, он ищет соответствующий запись в кеше и проверяет ее возраст. Если запись в кеше существует и достаточно свежа, ответ может быть получен из кеша.Однако, если срок годности пройден, Cloud CDN пытается повторно проверить запись в кеше, связавшись с один из ваших бэкэндов. Это делается перед отправкой ответа, если вы включить службу во время устаревания, в в этом случае повторная проверка выполняется асинхронно.

Cloud CDN повторно проверяет кэшированные объекты старше 30 дней. Это позволяет автоматически аннулировать и удалять устаревшие, созданные пользователем кешированный контент. Когда значение max-age или s-maxage превышает 30 дней (2,592,000 секунд), Cloud CDN обрабатывает значение, как если бы оно было 2,592,000 секунд.Нижестоящие клиенты по-прежнему видят точные значения max-age и s- maxage , даже если они превышают 30 дней.

Cloud CDN может попытаться использовать информацию из кешированного ответа заголовки для проверки записи кэша с помощью серверной части. Это случается, когда верны оба следующих утверждения:

• Ранее кэшированный ответ имеет заголовок Last-Modified или ETag .
• Клиентский запрос — это запрос GET , который не содержит If-Modified-Since или If-None-Match header.

Cloud CDN выполняет эту проверку немного по-разному в зависимости от был ли ответ кэширован с использованием диапазона байтов запросов:

• Если ответ был кэширован с помощью запросов диапазона байтов, Cloud CDN инициирует отдельный запрос проверки, который включает If-Modified-Since и / или If-None-Match заголовки .
• В противном случае Cloud CDN добавляет If-Modified-Since и / или If-None-Match Заголовки соответствуют запросу клиента и пересылают измененный запрос на бэкэнд.

Если кешированная копия все еще актуальна, серверная часть может проверить существующую запись в кэш, отправив ответ 304 Not Modified . В этом случае серверная часть отправляет только заголовки ответа, но не тело ответа. Облачный CDN вставляет новые заголовки ответов в кеш, обновляет срок действия, и передает клиенту новые заголовки и кешированное тело ответа.

Если ранее кэшированный ответ не имеет Last-Modified или ETag заголовок, Cloud CDN игнорирует запись в кеше с истекшим сроком действия и пересылает клиентский запрос к бэкэнду без изменений.

Срок действия записи в кэше — это верхняя граница того, как долго запись в кэше остается действительной. Нет гарантии, что запись в кеше останется. в кеше до истечения срока его действия. Записи в кеше для непопулярного контента могут быть выселены, чтобы освободить место для нового контента. Независимо от указанного срока время, записи кеша, к которым нет доступа в течение 30 дней, автоматически удаляются.

Для получения дополнительной информации см. Выселение и истечение срока.

Настройки TTL и отменяют

Вы можете точно настроить поведение Cloud CDN в зависимости от того, как долго Cloud CDN ждет перед повторной проверкой содержимого.

Для получения дополнительной информации см. Использование настроек TTL и отменяет.

Поддержка запросов диапазона байтов

Ответ, удовлетворяющий следующим критериям, указывает, что источник сервер поддерживает запросы диапазона байтов:

• Код состояния: 200 OK или 206 Частичное содержимое
• Заголовок: Диапазон приема: байты
• Заголовок: Content-Length и / или Content-Range
• Заголовок: ETag с сильным валидатором
• Заголовок: Последнее изменение

Cloud Storage поддерживает запросы диапазона байтов для большинства объектов.Тем не мение, Облачное хранилище не поддерживает запросы диапазона байтов для объектов с Content-Encoding: gzip метаданные, если клиентский запрос не содержит Accept- Кодировка: заголовок gzip . Если у вас есть объекты Cloud Storage размером более 10 МБ, убедитесь, что у них нет Content-Encoding: gzip метаданные. Для получения информации о том, как редактировать метаданные объекта, см. Просмотр и редактирование метаданных объекта.

Популярное программное обеспечение веб-сервера также поддерживает запросы диапазона байтов.Проконсультируйтесь со своим веб-сайтом документацию по серверному программному обеспечению для получения подробной информации о том, как включить поддержку. Для большего информацию о запросах диапазона байтов см. HTTP Технические характеристики.

Когда исходный сервер поддерживает запросы диапазона байтов, Cloud CDN кеш отказывается сохранить кешируемый ответ, когда он запрашивается, если выполняется одно из следующих условий:

• Тело ответа неполное, поскольку клиент запросил только часть содержание.
• Тело ответа превышает 1 МБ (1 048 576 байт).

Когда это происходит, и в противном случае ответ удовлетворял бы нормальному требования к кэшируемости, кеш записывает, что источник сервер поддерживает запросы диапазона байтов для этого ключа кеша и пересылает источник ответ сервера клиенту.

При промахе кэша кеш проверяет, известно ли, что исходный сервер поддерживает запросы диапазона байтов. Если известно, что запросы диапазона байтов поддерживаются для ключ кеша, кеш не пересылает клиентский запрос внешнему балансировщику нагрузки HTTP (S).Вместо этого кеш запускает собственное заполнение кеша диапазона байтов. запросы недостающих частей контента. Если ваш исходный сервер возвращает запрошенный диапазон байтов в ответе 206 Partial Content , кеш может сохраните этот диапазон для будущих запросов.

Кэш хранит ответ 206 Partial Content только тогда, когда он получен в ответ на запрос диапазона байтов, инициированный кешем. Потому что кеш не инициирует запрос диапазона байтов, если ранее не было записано, что исходный сервер поддерживает запросы диапазона байтов для этого ключа кеша, данного кеша не хранит контент размером более 1 МБ до второго раза, когда доступ к контенту.

Запрос свертывания (объединения)

Сворачивание запроса (также называемое объединением ) активно сворачивается несколько управляемые пользователем запросы на заполнение кеша для одного и того же ключа кеша в одном источнике запрос на граничный узел. Это может значительно снизить нагрузку на источник, и применяется как к запросам элемента , так и к запросам (ответы получены напрямую) и чанк запросов, где Cloud CDN использует запросы Range для получения более крупных объектов. эффективно.

Свертывание запроса включено по умолчанию.

Свернутые запросы ведут себя следующим образом:

• Свернутые запросы регистрируют как клиентский запрос, так и (свернутый) запрос на заполнение кеша.
• Лидер свернутого сеанса используется для создания запрос на исходное заполнение.
• Запросить атрибуты, не являющиеся частью ключа кеша, такие как User-Agent или Accept-Encoding заголовок, отражают только лидер свернувшейся сессии.
• Запросы, у которых нет того же ключа кеша, не могут быть свернуты.

На следующей диаграмме показано, как объединяются запросы:

Для сравнения, с отключенным сворачиванием запросов или для запросов, которые не могут быть объединенных, количество исходных запросов и ответов может быть равно количество клиентов, пытающихся получить объект, который в данный момент не кэширован.

Для всех типов запросов сворачивание включено по умолчанию.Для запроса товара типов можно отключить сворачивание. Мы рекомендуем отключить сворачивание для элемента запросы в сценариях с высокой задержкой, например при показе рекламы, если источник нагрузка не рассматривается.

В следующей таблице обобщены поведение и возможности настройки по умолчанию для разные типы запросов.

Для отключить сворачивание запроса элемента с помощью Cloud SDK для серверной корзины ссылающийся на сегмент Cloud Storage:

gcloud

Используйте gcloud compute backend-services или backend-buckets Команда :

gcloud compute backend-services update  BACKEND_SERVICE_NAME  \
    --no-request-coalescing
 

Чтобы включить сворачивание запроса элемента в серверной корзине с помощью Cloud SDK:

gcloud

Используйте команду gcloud compute backend-buckets :

gcloud compute backend-buckets update  BACKEND_BUCKET_NAME  \
    --request-coalescing
 

Чтобы включить сворачивание запроса элемента с помощью Cloud SDK для серверной службы, включая группы виртуальных машин и настраиваемые источники:

gcloud

Используйте команду gcloud compute backend-services :

gcloud compute backend-services update  BACKEND_SERVICE_NAME  \
    --request-coalescing
 

Запросы, инициированные Cloud CDN

Если исходный сервер поддерживает запросы диапазона байтов, Cloud CDN может отправлять несколько запросов на ваш исходный сервер в ответ на один запрос клиента.Cloud CDN может инициировать два типа запросы: запросы проверки и запросы диапазона байтов.

Если ответ, указывающий, что исходный сервер поддерживает запросы диапазона байтов для определенного ключа кеша истек срок действия, Cloud CDN инициирует запрос на проверку, чтобы подтвердить, что контент не изменился и что ваш исходный сервер по-прежнему поддерживает запросы диапазона для содержимого. Если ваше происхождение сервер отвечает ответом 304 Not Modified , Cloud CDN переходит к обслуживанию содержимого, используя диапазоны байтов.Иначе, Cloud CDN перенаправляет ответ вашего исходного сервера на клиент. Вы контролируете время истечения срока действия с помощью Cache-Control и Expires . заголовки ответов.

При промахе кеша Cloud CDN инициирует запросы на заполнение кеша для набор диапазонов байтов, которые перекрывают клиентский запрос. Если некоторые диапазоны контент, запрошенный клиентом, присутствует в кеше, Cloud CDN обслуживает все, что может, из кеша и отправляет байт диапазон запрашивает только отсутствующие диапазоны на ваш исходный сервер.

Каждый запрос диапазона байтов, инициированный Cloud CDN, указывает диапазон который начинается со смещения, кратного 2 097 136 байтам. С возможным За исключением последнего диапазона, каждый диапазон также составляет 2 097 136 байт. Если содержание не кратно этому размеру, окончательный диапазон меньше. В размер и смещения, используемые в запросах диапазона байтов, могут измениться в будущем.

В качестве примера рассмотрим запрос клиента на байты от 1 000 000 до 3 999 999. содержимого, которого нет в кеше.В этом примере Cloud CDN может инициировать два запроса GET, один для первого. 2 097 136 байт содержимого и еще 2 097 136 байт для вторых. Этот приводит к заполнению кэша 4 194 272 байта, даже если клиент запросил только 3 000 000 байт.

Когда вы используете корзину Cloud Storage в качестве источника, каждый запрос GET оплачивается как отдельная операция класса B. С вас взимается плата за все запросы GET, обрабатываемые облачным хранилищем, включая любые запросы, инициированные Cloud CDN. Когда ответ обслуживается полностью из кеша Cloud CDN, запросы GET не отправляются Облачное хранилище, и вы не платите ни за какое облачное хранилище операции.

Когда Cloud CDN инициирует запрос проверки или диапазон байтов запрос, он не включает специфичные для клиента заголовки, такие как Cookie или Пользовательский агент .

В облачном ведении журнала httpRequest.userAgent поле , Cloud-CDN-Google означает, что запрос инициирован Cloud CDN.

Обход кеша

Обход кэша позволяет запросам, содержащим определенные заголовки, обходить кеш, даже если содержимое было ранее кэшировано.

В этом разделе представлена ​​информация об обходе кеша с заголовками HTTP, например, Pragma и Авторизация . Эта функция полезна, когда вы хотите убедитесь, что ваши пользователи или клиенты всегда получают последний контент только что с исходного сервера. Возможно, вы захотите сделать это для тестирования, настройки промежуточные каталоги или скрипты.

Если указанный заголовок совпадает, кеш обходится для всех режимов кеширования. настройки, даже FORCE_CACHE_ALL .Обход кеша приводит к большому количеству кеш промахивается, если указанные заголовки являются общими для многих запросов.

Прежде чем начать

• Убедитесь, что Cloud CDN включен; инструкции см. Использование Cloud CDN.

• При необходимости обновите до последней версии Cloud SDK:

  обновление компонентов gcloud
   

  Примечание. Убедитесь, что вы используете gcloud SDK версии 324.0.0 или более поздней версии.

Настройка обхода кеша

Можно указать до пяти имен заголовков HTTP.Значения нечувствительны к регистру. Имя заголовка должно быть допустимым полем заголовка HTTP. токен. Имя заголовка не должно появляться более одного раза в списке добавленных заголовков. Для правила о допустимых именах заголовков, см. Как настраиваемые заголовки Работа.

Консоль

1. В консоли Google Cloud перейдите на страницу балансировки нагрузки .

   Перейти на страницу балансировки нагрузки

2. Щелкните имя внешнего балансировщика нагрузки HTTP (S).
3. Щелкните Редактировать Редактировать.
4. В конфигурации Backend выберите backend и нажмите Edit редактировать.
5. Убедитесь, что выбрано Включить облако CDN .
6. В нижней части окна щелкните Дополнительные конфигурации .
7. В разделе Обход кеша в заголовке запроса щелкните Добавить заголовок .
8. Введите имя заголовка, например Pragma или Authorization .
9. Нажмите Обновить .
10. Нажмите Обновить еще раз.

gcloud

Для серверных сегментов используйте серверные сегменты gcloud compute создать или подсистемы вычислений gcloud команда обновления с флагом --bypass-cache-on-request-headers .

Для серверных служб используйте серверные службы gcloud compute. создать или серверные службы gcloud для вычислений команда обновления с флагом --bypass-cache-on-request-headers .

gcloud compute backend-buckets (create | update)  BACKEND_BUCKET_NAME 
    --bypass-cache-on-request-headers =  BYPASS_REQUEST_HEADER 
 

gcloud compute backend-services (создать | обновить)  BACKEND_SERVICE_NAME 
    --bypass-cache-on-request-headers =  BYPASS_REQUEST_HEADER 
 

Например:

gcloud compute backend-services обновить my-backend-service
    --bypass-cache-on-request-headers = Прагма
    --bypass-cache-on-request-headers = Авторизация
 

api

Для серверных сегментов используйте Метод: backendBuckets.вставлять, Метод: backendBuckets.update, или Метод: backendBuckets.patch Вызов API.

Для серверных служб используйте Метод: backendServices.insert, Метод: backendServices.update, или Метод: backendServices.patch Вызов API.

Например:

ПАТЧ https://compute.googleapis.com/compute/v1/projects/  PROJECT_ID  / global / backendBuckets
 

Добавьте следующий фрагмент в тело запроса JSON:

"cdnPolicy": {
  "bypassCacheOnRequestHeaders": [
    {
      "headerName": строка
    }
  ]
}
 

Отключение обхода кеша

Что дальше

Как загрузить весь сайт из Google Cache?

— Полная локализация Archivarix CMS на 13 языков (английский, испанский, итальянский, немецкий, французский, португальский, польский, турецкий, японский, китайский, русский, украинский, белорусский).
— Экспорт всех текущих данных сайта в zip-архив для сохранения резервной копии или передачи на другой сайт.
— Показать и удалить поврежденные zip-архивы в инструментах импорта.
— Проверка версии PHP при установке.
— Информация по установке CMS на сервере с NGINX + PHP-FPM.
— В поиске при включенном экспертном режиме отображается дата / время страницы и ссылка на ее копию в WebArchive.
— Улучшения пользовательского интерфейса.
— Оптимизация кода.

Если вы являетесь носителем языка, на который наша CMS еще не переведена, мы приглашаем вас сделать наш продукт еще лучше. Через сервис Crowdin вы можете подать заявку и стать нашим официальным переводчиком на новые языки.

Новая версия Archivarix CMS.
— Поддержка интерфейса командной строки для развертывания веб-сайтов прямо из командной строки, импорта, настроек, статистики, очистки истории и обновления системы.
— Поддержка зашифрованных паролей password_hash (), которые можно использовать в CLI.
— Экспертный режим для включения дополнительной отладочной информации, экспериментальных инструментов и прямых ссылок на сохраненные в WebArchive снимки состояния.
— Инструменты для неработающих внутренних изображений и ссылок теперь могут возвращать список всех отсутствующих URL-адресов вместо удаления.
— Инструмент импорта показывает поврежденные / неполные zip-файлы, которые можно удалить.
— Улучшена поддержка файлов cookie, чтобы соответствовать требованиям современных браузеров.
— Параметр для выбора редактора по умолчанию для HTML-страниц (визуальный редактор или код).
— Вкладка «Изменения», отображающая различия текста, по умолчанию отключена, может быть включена в настройках.
— Вы можете вернуться к определенному изменению на вкладке «Изменения».
— Исправлен URL-адрес карты сайта XML для веб-сайтов, созданных с субдоменом www.
— Исправлено удаление временных файлов, которые были созданы в процессе установки / импорта.
— Более быстрая очистка истории.
— Удалены неиспользуемые фразы локализации.
— Переключатель языка на экране входа в систему.
— Обновлены внешние пакеты до последних версий.
— Оптимизировано использование памяти для вычисления различий текста на вкладке «Изменения».
— Улучшена поддержка старых версий расширения php-dom.
— экспериментальный инструмент для исправления размеров файлов в базе данных, если вы редактировали файлы непосредственно на сервере.
— экспериментальный и очень сырой инструмент экспорта плоской структуры.
— экспериментальная поддержка открытого ключа для будущих функций API.

Первое июньское обновление Archivarix CMS с новыми удобными функциями.
— Исправлено: раздел истории не работал, если в php не было включено расширение zip.
— Новая вкладка «История» с подробностями об изменениях при редактировании текстовых файлов.
— Инструмент редактирования .htaccess.
— Возможность очистки резервных копий до нужной точки отката.
— Раздел «Отсутствующие URL-адреса» удален из инструментов, поскольку он доступен из панели управления.
— Мониторинг и отображение свободного места на диске в панели управления.
— Улучшена проверка необходимых расширений PHP при запуске и начальной установке.
— Незначительные косметические изменения.
— Все внешние инструменты обновлены до последних версий.

Обновление, которое оценят веб-студии и те, кто использует аутсорсинг.
— Отдельный пароль для безопасного режима.
— Расширенный безопасный режим. Теперь вы можете создавать собственные правила и файлы, но без исполняемого кода.
— Переустановка сайта из CMS без необходимости вручную удалять что-либо с сервера.
— Возможность сортировки пользовательских правил.
— Улучшенный поиск и замена для очень больших сайтов.
— Дополнительные настройки для инструмента «Метатег видового экрана».
— Поддержка доменов IDN на хостинге со старой версией ICU.
— При первоначальной установке с паролем добавлена ​​возможность выхода.
— Если при интеграции с WP будет обнаружен .htaccess, то правила Archivarix будут добавлены в его начало.
— При загрузке сайтов по серийному номеру используется CDN для увеличения скорости.
— Прочие мелкие улучшения и исправления.

Это и многие другие косметические улучшения и оптимизации скорости.

Веб-сайт показывает ошибку 404 в кэше Google

Если вы один из тех владельцев веб-сайтов, которым трудно просматривать кешированную версию в Google, то этот пост для вас.К концу этого поста вы узнаете, как просмотреть точную дату сканирования, несмотря на то, что на вашем веб-сайте появляются ошибки 404 в веб-кеше Google.

Прежде чем перейти к обещанному решению, давайте рассмотрим некоторые вопросы, найденные в различных новостях, на форумах и в списках форумов, с широким диапазоном мыслей и аргументов.

• Ошибка 404 кэша Google будет влиять на ваш рейтинг поиска или нет.
• Как исправить ошибку 404 кеша Google.
• Как решить ошибку 404 кеша Google.
• Я получаю ошибку 404 при проверке кеширования старых веб-сайтов.
• Мой веб-сайт не показывает «опцию кеширования» в результатах поиска.
• Мой сайт не отображается в поиске Google, но мои результаты были очень хорошими для поиска по определенному ключевому слову.
• Что мне делать, чтобы мой сайт вернулся на первое место в Google?

Прежде чем продолжить, хотим вас заверить, ребята —

Это может случиться.

И кеш Google 404 — это проблема Google, а не вашего сайта! Вы, должно быть, заметили, что эти ошибки не появляются в Yahoo или Bing.Это только в Google. И это не повлияет на ваш рейтинг в поисковых системах.

Согласно недавнему обсуждению с Reddit, Джон Мюллер из Google сказал: «если ваша ссылка на кеш в Google возвращает ошибку 404, это не означает, что ваш рейтинг в Google будет поврежден». Кроме того, он поясняет, что поиск 404-й ошибки в Google Cache является внутренней проблемой сервера Google Cache и не влияет на индексацию или ранжирование веб-страницы.

И, с точки зрения Google, отсутствие ссылки кеша не является фактором низкого качества или фактором ранжирования.

Все еще есть сомнения!

Позвольте нам помочь вам увидеть точные данные кеша независимо от того, возникает ли у вас ошибка кеширования 404 для вашего веб-сайта. Выполните следующие действия:

Мы также получаем ошибку кеширования Google 404, и мы искали метод, чтобы узнать, действительно ли это ухудшает наш рейтинг или страницы нашего сайта деиндексируются из базы данных Google. Мы провели исследование и обнаружили, что эти ошибки не имеют ничего общего с индексированием или рейтингом ключевых слов; это просто проблема с кеширующим сервером Google.И мы нашли способ узнать дату последнего кеширования и версию наших страниц.

Так что держитесь крепче и следуйте этим простым шагам.
Шаг 1
В поиске Google.com

Шаг 2
Мы искали

Шаг 3
Перейдите к URL / URL, для которых вы хотите увидеть последнюю версию сканирования и дату

Шаг 4
Мы проверяем дату и версию последнего сканирования для одного из URL-адресов нашего веб-сайта —

Шаг 5
Выберите раскрывающийся список рядом с URL-адресом — см. Пример ниже

Step 6
Вы получите этот URL, внимательно проверьте эту ошибку —

Шаг 7
Теперь найдите <«J:»>

Шаг 8
Удалить коды / фразы после <«J:»>

Шаг 9
И добавьте к нему

Шаг 10
Конечный URL будет примерно таким —

Step 11
А вот детали, которые вы искали

Надеюсь, он решит некоторые из ваших вопросов.

Если вам понравились наши выводы, поделитесь своими мыслями в комментариях ниже и поделитесь с друзьями, которые все еще сомневаются и находят решение, как исправить ошибки 404 кеша.

Как окупить Google Cache в вашем генеалогическом исследовании

Что вы делаете, когда вы что-то гуглите, нажимаете на URL-адрес результата поиска, и он говорит «страница не найдена» или «ошибка?» Дебби недавно нашла ответ в своей новой копии недавно отредактированного и обновленного The Genealog’s Google Toolbox (2-е издание).

Она написала нам: «Я заказала свою книгу на прошлой неделе и сегодня нашла ее в своем почтовом ящике! Я тут же пролистал его, прочитал заголовки и посмотрел на картинки.Мне нравится, как он читается… не «по учебникам», а более приятным и более таким, как если бы кто-то только что со мной разговаривал. Не могу дождаться, чтобы попробовать все советы и посмотреть, что я могу открыть! Фактически, я уже обнаружил то, чего не знал… поиск t в кеше, когда вы получаете страницу с надписью «не найден» или «ошибка». Если бы я только мог вспомнить все случаи, когда видел это. Большое спасибо! Я очень рада, что добавила эту книгу в свою маленькую генеалогическую библиотеку! »

Google Cache: вот как это работает

Как вы знаете, Google «сканирует» Интернет, постоянно индексируя веб-сайты.Он также делает снимок каждой просматриваемой страницы и кэширует или сохраняет изображение в качестве резервной копии. Это скрытая информация, которую Google использует, чтобы определить, соответствует ли страница вашим поисковым запросам.

В случае веб-сайта, который больше не существует, копия кэша предоставляет моментальный снимок веб-сайта, когда он был еще активен. Практически каждый результат поиска включает ссылку Cached .

Как получить кэшированную веб-страницу:

1. Когда вы попадаете на страницу с ошибкой «Обнаружена заметка о файле», нажмите кнопку «Назад» в браузере, чтобы вернуться на страницу результатов поиска Google.
2. Прямо под заголовком сайта находится его URL. Щелкните маленькую стрелку вниз рядом с этим адресом.
3. «Кэшировано» будет одним из вариантов, представленных во всплывающем меню. Щелкнув ссылку Cached , вы перейдете к кэшированной Google версии этой веб-страницы, а не к текущей версии страницы.

Кэшированные версии веб-сайтов также могут быть полезны, если исходная веб-страница недоступна, потому что:

• перегрузки интернета;
• веб-сайт не работает, перегружен или просто работает медленно.Поскольку серверы Google обычно работают быстрее, чем многие веб-серверы, часто вы можете получить доступ к кэшированной версии страницы быстрее, чем сама страница; и
• владелец веб-сайта недавно удалил страницу из Интернета.

Если Google возвращает ссылку на страницу, которая, кажется, не имеет ничего общего с вашим запросом, или если вы не можете найти информацию, которую ищете на текущей версии страницы, взгляните на кешированную версию, щелкнув закешированная ссылка. После этого вы увидите веб-страницу в том виде, в котором она выглядела, когда Google в последний раз проиндексировал ее.

Вы заметите, что вверху страницы появится серый заголовок. Это предоставит вам следующую информацию о кэшированной странице, которую вы просматриваете:

• Исходный веб-адрес страницы.
• Дата и время, когда просматриваемая страница была кэширована.
• Ссылка на текущую версию этой страницы.

Если вы не видите кешированную ссылку в результатах поиска, возможно, она была пропущена, потому что владелец веб-сайта попросил Google удалить кешированную версию или попросил Google не кэшировать их содержание.Кроме того, все сайты, которые Google еще не проиндексировали, не будут иметь кешированной версии.

Имейте в виду, что если исходная страница содержит более 101 килобайт текста, кешированная версия страницы будет состоять только из первых 101 килобайт (120 килобайт для файлов PDF).

Хотите узнать больше о кешировании?