Google now says a canonical fix can take two weeks

Google now says a canonical fix can sit for up to two weeks before it shows up in the index. The line landed in the canonicalization troubleshooting guide on 10 July 2026, and it changes how you should schedule the work: even after you fix the content problem, Google might hold your page in a duplicate cluster for another fourteen days. If you ship a fix on Monday and check on Wednesday, you have measured nothing.

The wording in Google's guide is plain: "Even after fixing content issues, Google might hold pages in a duplicate cluster for up to two weeks." The documentation changelog dates the edit to 10 July and describes it as a clarification on re-evaluation time. Google didn't change the algorithm. It told you how long to wait, which is the part most teams were guessing at.

What a canonical fix actually has to overcome

A duplicate cluster is a group of URLs Google has decided are the same page. It picks one to index and the others go quiet. You can declare a canonical with rel="canonical", and Google treats that as a signal rather than an instruction. The guide is direct about it: Google "might choose a different canonical for various reasons, such as the quality of the content."

The doc also tells you what speeds the split up. Pages come out of a cluster faster when the difference between the new content and the rest of the cluster is clear and significant. So a fix that changes a title tag and two sentences is a weak signal. A fix that gives the page a genuinely different job, different examples, different data, is a strong one. Half-measures get you the full two-week wait and then no movement.

Why the timing matters this month

Check Google's own status dashboard and July 2026 is empty. The last confirmed ranking event was the June 2026 spam update, which started on 24 June and ran about two days. Before that, the May 2026 core update started on 21 May and ran close to twelve days. Nothing since.

That gap is the problem. Rankings have still been moving, tracking tools have still been loud, and there is no confirmed update to hang it on. So when a page drops this month you are looking at two candidates that behave identically in a traffic chart: unconfirmed churn, or a canonical decision you triggered yourself with a recent edit. Both need the same thing from you, and it isn't another edit.

Ship once, then leave it alone for fourteen days

The protocol is short and it costs nothing to run.

• Write down the ship date. A line in a sheet: URL, what changed, date pushed. Without it you will be arguing from memory in two weeks.
• Make one change per URL. If you rewrite the body, swap the canonical, and change the internal links in the same push, you cannot read the result.
• Request indexing once. The URL Inspection tool has a request quota. Spending three of them on the same page on three consecutive days buys you nothing.
• Set the check for day fourteen. Not day three, not day seven. Anything you look at before then is noise you will be tempted to act on.

The hard part is the fourth one. Two weeks of silence feels like failure, and the reflex is to push another version. Every re-edit restarts the clock and muddies the read, which is how a page that was going to recover ends up in a loop. We see the same pattern when teams refresh old posts three times in a month and then can't say which version worked.

Check the canonical, not the sessions chart

Sessions are the wrong instrument here, because they mix ranking movement, seasonality, and AI surfaces into one line. Use URL Inspection instead and read one field: the Google-selected canonical. It answers the question directly. Either Google now indexes the URL you declared, or it still points somewhere else.

Three outcomes, three different next moves. Google agrees with your canonical and the page is indexed, so the fix worked and you go measure position. Google still picks another URL after fourteen days, so the content difference wasn't clear enough and you make it bigger. Google shows the page as crawled but not indexed, so the problem was never canonicalization and you have been fixing the wrong thing for two weeks.

That third case is the common one, and it's why the timestamp matters more than the fix. A dated log turns a vague sense that traffic is down into a specific question with a specific answer. It's the same discipline that separates a real plateau from a dip: you need a before, an after, and a date in between.

What to do this week

Pull your top twenty commercial URLs. Run URL Inspection on each and note where Google's chosen canonical disagrees with yours. That list is your work queue, and it's usually shorter and more valuable than the content calendar it will displace. Fix the top three properly, log the date, and put a reminder in the calendar for 2 August.

If you want help turning a list of canonical conflicts into a plan with dates against it, that's the kind of work we do at vibhe.