Someone asked me if it was true that it takes around three months for Google to assign value to a link.
The interesting thing about the recent patents and updates to patents is that they explain a way to efficiently accomplish these mind boggling calculations.
Those kinds of research papers aren’t super exciting because they’re concerned with how to essentially do geek plumbing. But they are important because they make things like real-time Penguin calculations possible.
Does it Take 3 Months for a Link Effect?
The reasonable assumption for the past ten or so years has been that it takes about three months for the influence of a link to become noticeable in the search engine results pages (SERPs). With the recent advances in hardware, software and algorithms, it’s more likely that the influence is happening faster.
The search engines are a lot faster than they were ten years ago. So it follows that perhaps the link effect might be even faster today than it was a decade ago.
Evidence that Link Effects May be Faster
Consider that Penguin is now a part of Google’s core algorithm. Penguin, a link algorithm, works in real-time. This has been the case for almost two years now.
So it is reasonable to assume that the value of a link is folded into Google’s ranking algorithm at a significantly faster rate than three months.
Because Penguin is real time and is now a part of Google’s core algorithm, it is absolutely reasonable to update our estimate of how long it takes for a link to take effect. Three months now seems too slow and not reasonable at all.
The time period for a link to take effect is probably on the order of a week to fifteen days. But whether you see the effect of those links is another matter altogether. One link or a few links by themselves may not be enough to help your rankings.
*For a fuller explanation of why a week to fifteen days, please scroll down to the Addendum where I explain in more detail.
What if Rankings Change 3 Months Later?
Sometimes rankings change three months after a link. Could that be attributed to the links? In three months there is no way to know whether a change in ranking is due to a single link, another link that was added to your site, links dropping off of a competitor’s site or even a totally unrelated change with Google’s core ranking algorithm.
A change in Google’s core algorithm could decide that your competitor’s site is not a good fit for certain keyword phrases. Then your site rises because it’s a better match. Or it could be that your site offeres a better user experience and Google’s algorithm is handing out prizes for good UX that week.
Three months is far too long to make an accurate judgment about whether a single link or a group of links made a difference. There are too many things going on externally to your site (having nothing to do with your site), and too many factors directly related to your site that are changing, in order to put your finger on it and say with any confidence that this single factor is what caused a change in rankings.
Links and Ranking Changes
In my opinion, it’s best to focus on building content and cultivating links, in that order. Identifying which link caused a rise in rankings would be nice. But it’s not always possible to identify which link caused the change in rankings. The calculations involved are many and we have no idea how the various link factors are weighted on any particular day.
So the best answer to the question about how long to wait until a link has taken effect is to not wait. Just let go of fussing over minor details like a single link and move on to the bigger picture and keep building bigger and better things. The links will work their magic regardless if you are worrying about it or not.
I based that week to fifteen day estimate based on things John Mueller has said about crawling (it can take days for a site to be re-indexed), plus the description in the patent application for calculating link distances (Scalable system for determining short paths within web link network) which I’ll discuss in detail below.
Crawling is necessary to discover links. But, Google isn’t re-crawling the entire web and recalculating the link map of the entire Internet all at once after two A.M. According to the patent linked above, this part of the algorithm divides the web according to topics in order to make the process of updating the link graph scalable.
So now we have two processes that introduce an element of a time delay. The crawling and re-indexing plus the subsequent recalculations of link relationships.
Here is a relevant portion of that patent that relates to dividing up the web into smaller portions:
“Systems and methods for finding multiple shortest paths. A directed graph representing web resources and links are divided into shards, each shard comprising a portion of the graph representing multiple web resources. Each of the shards is assigned to a server, and a distance table is calculated in parallel for each of the web resources in each shard using a nearest seed computation in the server to which the shard was assigned.”
“The systems run in a distributed environment, across many machines and efficiently recover from machine failures.”
This divides the load of calculating all those relationships and makes it more manageable. That in my opinion is the part of that algo that is as interesting as the core link distance ranking part.
So that means that you have all these different niche areas that are recalculating, and not the entire web at the same time. Dividing up the web by niches creates a more accurate link signal but also makes the process scalable.
This way, in my opinion, you’ll have a rolling update where several niche areas update, followed by another group of niches and so on.
The Time Element
The patent discusses a process called Checkpointing. This is like a snapshot of a portion of the link graph. There are references to GFS, this is a reference to Google’s Global File System.
“At predetermined time intervals, or at times of low activity, or after many changes have accumulated, each shard server stores an incremental checkpoint of the distance table and of the leaf table on a reliable data store, e.g., as a distance table increment file and a leaf table increment file on a GFS.
The leaf table may be flushed at other times as well. Checkpoints may be used for failure recover in the event of a server failure, whether a software failure, a hardware failure, or other failures that prevents the shard server from processing distance updates. The term “checkpoint” is used within this specification to describe a data structure that may describe a state change in a portion of the distance table respective to a particular shard server and a particular time interval.
Each checkpoint includes a timestamp and a delta representing the changes to the data from the previous checkpoint. The shard servers will generally write checkpoints to the GFS independently of one another, and their regular interval times may include an element of pseudo-randomness so as to smooth out the demand for GFS resources. Because each shard server determines when a particular checkpoint is written to the GFS, the process is asynchronous.”
So there you have different shards “checkpointing” themselves and then in set time intervals they update the Global File System, where the entire map is stored. This tells us that the calculations aren’t happening all the time. This also tells us that changes are not committed right away to the main link graph.
Anyone who’s ever had a site go down in a server crash for a couple weeks or longer and subsequently fed Google 404 or 500 errors for that time can tell you that the average time to recovery is about a week to fifteen days. I think that time period reflects how long it takes to crawl, fold the data back into the index, then update the local link graph.
Images by Shutterstock, Modified by Author