If you received a noticed from Google Search Console saying that your site has been moved to the Mobile-first index, you have done nothing wrong and there is nothing you can do to restore the cache visibility. See the detailed explanation at the end of this article for more information. Someone left the following comment a week ago March I have tried twice to send an email to the person but their mail service says the mailbox is unavailable. Normally I would leave matters at that but this question comes up from time to time so I thought I would write a brief article about it.
To the original commentor, I hope you see this. Your site should be fine. This is off-topic, but I was wondering if you could lend me some of your SEO expertise. My website is not cached in google. The homepage and all inner pages are indexed, but none of them are cached. I was wondering if this affects whether my website is sent organic search engine traffic.
Also, can you think of a few possible causes off the top of your head as to why my pages are not cached. I also checked my robots. If you could help, I would really appreciate it! By the way, I enjoyed reading this post. Google and other search engines will now cache your pages.
For example, you can use Web Cache Viewer. Now, go to a page you want to check. The full version shows a rendered view of the page.
Keep in mind that what you see in the rendered view is the page rendered by YOUR browser, not by Google. Here is a small experiment. Check Google Cache for this page — Online-Stopwatch and compare the date of the last re-indexing and the time and date displayed in the cache. The clock shows when I checked the cache, so it is displaying the content in real time.
If the page was rendered by WRS, the time and date would be frozen and would display the same time as you see in the gray box. The text view is a version with CSS switched off and with no images displayed. Here you will see only the text and hyperlinks. The text view will not show the content loaded with JavaScript, so if you check the text-only version of Online-Stopwatch, the clock is gone.
We should keep a healthy distance between what we are seeing there and how we use the data from Google Cache. At the same time, the full version shows the rendered page, as rendered by your browser. These two pieces of information significantly impact how we should interpret what we see in Google Cache. Let me guess. You probably more or less use the up-to-date version of the browser. You can check it by visiting this page.
My browser is Chrome version Google, for rendering purposes, uses Web Rendering Service based on Chrome The gap between these versions is huge, which you can see by simply comparing the supported and unsupported features in caniuse. So rendering with Chrome 41 and a more up to date browser is incomparable.
And vice versa. It may happen that they use an older version, even though the content may have changed twice since then. As a result, the content in the cache might be stale. Google does not provide detailed information on how Google Cache works, but they give us hints on how we should interpret the issues discovered in Google Cache.
Below you will find a review of the common issues and their causes. When you visit a cached version of the page you may see that it has crashed. Some elements might not be rendered properly; some images might be missing; the fonts might differ from what you see on your website.
The reason this may occur is that the recent rendering is based on the cached version of the page, which may refer to resources that no longer exist.
When someone visits a website, everything the site needs to display and operate has to come from somewhere. All the text, images, CSS styles, scripts, media files, and so on must be retrieved by the browser for display or execution.
You can give the browser choices about where it can retrieve a resource from, and that can make a big difference in your page's load speed. The next time the browser hits that page, it can look in the cache for resources that were previously fetched and retrieve them from disk, often faster than it can download them from the network.
You can read about how these caches vary in this excellent article, A Tale of Four Caches. Of course, every first-time visitor to your page arrives with nothing yet cached for that page. Even repeat visitors may not have much in the HTTP cache; they might have manually cleared it, or set their browser to do so automatically, or forced a fresh page load with a control-key combination.
Still, a significant number of your users may revisit your site with at least some of its components already cached, and that can make a huge difference in load time. Maximizing cache usage is critical to speeding up return visits.
Caching works by categorizing certain page resources in terms of how frequently or infrequently they change. Your site's logo image, for example, might almost never change, but your site's scripts might change every few days. It's beneficial to you and your users to determine which types of content are more static and which are more dynamic.
It's also important to remember that what we think of as browser caching may in fact take place at any intermediate stop between the original server and the client-side browser, such as a proxy cache or a content delivery network CDN cache. Two main types of cache headers, cache-control and expires , define the caching characteristics for your resources.
Typically, cache-control is considered a more modern and flexible approach than expires, but both headers can be used simultaneously. Cache headers are applied to resources at the server level -- for example, in the.
Caching is enabled by identifying a resource or type of resource, such as images or CSS files, and then specifying headers for the resource s with the desired caching options.
You can enable cache-control with a variety of options in a comma-delimited list. Here is an example of an Apache. This example sets caching for styles and scripts, resources that are probably more likely to change than the images, to one day and public access.
Cache-control has a number of options, often called directives , that can be set to specifically determine how cache requests are handled. Some common directives are explained below; you can find more information at the Performance Optimization section and at the Mozilla Developer Network.
This forces the client to check for freshness but allows it to avoid downloading the resource again if it has not changed. Mutually exclusive with no-store. This is a good option for resources that may contain sensitive data, or for resources that will almost certainly change from visit to visit. Mutually exclusive with no-cache. Overrides the default private setting for requests that use HTTP authentication. Mutually exclusive with private. Often used for user-specific, but not particularly sensitive, data.
Mutually exclusive with public. This option generally replaces the expires header see below and takes a value in seconds, with a maximum valid age of one year seconds. You can also enable caching by specifying expiration, or expiry, times for certain types of files, which tell browsers how long to use a cached resource before requesting a fresh copy from the server.
0コメント