Google Meet recurring meeting: one link, or a new one each time
A recurring Google Meet link looks like the simplest thing on a calendar. One event repeats, one link sits in it, everyone bookmarks the link and the weekly meeting runs for a year. It works that way until something ordinary happens: the time moves by thirty minutes, the series gets duplicated for a second team, or the event is edited in a calendar application that is not Google Calendar. Each of those does something specific to the meeting code, and in the last two years Google has changed the rules deliberately. The version of this that people learned in 2022 is no longer how it behaves.
One code, tied to one event
Start with the rule everything else follows. When Google Meet is added to a Google Calendar event, the event gets a unique meeting code, and Google's documentation states that until the code expires it is permanently linked to the original Calendar event. The guest list of that original event is what controls who can join the meeting and who can reach the meeting records, meaning recordings and chat history.
For a recurring series this produces one link across every occurrence, which is the behaviour people want. Google's guidance adds a detail about how the code resolves in time: for recurring events, the code connects to the meeting in progress or the next upcoming one. The link in a calendar entry from three weeks ago is not a link to that past occurrence. It is a link to whichever occurrence is current.
Creating the series itself is ordinary. An event is set to repeat from the control next to the repeat option, an existing event can be made to repeat the same way, and Google notes a ceiling that is rarely hit but does exist: repeating events in Google Calendar have a limit of 730 occurrences. A daily meeting runs out after roughly two years.
What generates a new code
This is the part that changed, and it changed twice.
In September 2025 Google stopped copying the Meet conference when an event is copied or duplicated. The announcement is direct about the reason: keeping the conference on the original event means Meet access and meeting notes stay tied to that event and its attendees. Anyone who duplicates last quarter's series to create this quarter's now has an event with no conference on it, and has to add one or paste the old code in on purpose.
In November 2025 the recurring case followed. Previously, editing the start time or the recurrence of a repeating event and applying the change to this and following events left the remaining occurrences on the original Meet link. Now those remaining events automatically generate a new, unique Meet link, while the original series keeps the original one. All properties of the Meet conference are preserved on both links, including the host, cohosts, access restriction and recording settings. Google's stated purpose is to stop meeting links being unintentionally reused across separate Calendar events.
| Action | Effect on the Meet link |
|---|---|
| Editing a single occurrence | Series link unchanged |
| Changing the start time for this and following events | Remaining events get a new link, original series keeps the old one |
| Changing the recurrence for this and following events | Same as above |
| Copying or duplicating the event | No conference is carried over |
| Editing the event in a non-Google calendar application | A new code may be generated automatically |
Both changes apply to personal Google accounts as well as Workspace accounts, and neither has an admin control or an end-user setting. There is nothing to opt out of. The practical consequence is that a series edited for this and following events has quietly become two meetings with two links, and the participants holding a bookmark are holding the older one.
The Mac calendar trap
One line in Google's documentation deserves its own section for anyone running meetings from a Mac, because it explains a recurring confusion that looks like a sync bug and is not.
Google states that for the best experience Meet should be used with Google Calendar, and that if Google Calendar events with Google Meet codes are created in Apple Calendar or other calendar applications, a new meeting code might be generated automatically to ensure the privacy and security of the meeting. An email notification is sent when that happens. The recommendation attached to it is to manage meeting links either in the Google Calendar app on iPhone or iPad, or at the Google Calendar website.
That is a specific and consequential behaviour. A weekly team meeting whose time gets dragged in a desktop calendar application can come back with a different code than the one in everyone's bookmarks, and the only notice is a mail that reads like routine calendar noise. For a recurring meeting the failure is not visible until the next occurrence, when half the participants are in one room and half are in another.
What it means for choosing a desktop calendar
The lesson is not that desktop calendars cannot be used. It is that conference data is the one part of a Google Calendar event that should not be edited through a generic synchronization path. Any calendar application on the Mac is being judged on a narrower question than it looks: does it edit the event through Google's own interface for conferences, or does it write an event body and let Google work out what happened.
For a recurring series this question is worth settling before the series is created, not after. The Compared with other calendars page sets out how the options on the Mac differ on the ground they share with Google Calendar, and the Features page covers what the event editor handles directly.
Why reusing an old code is worse than it looks
There is a shortcut that appears obvious. Rather than letting a new event generate a new code, paste the familiar link into it. Google's documentation on meeting codes spells out what that does, and the list is uncomfortable.
Because permissions stay tied to the original event's guest list, sensitive discussions such as performance reviews or interviews could be visible to the people invited to the original event. Those people might have access to recordings and other files from the new meeting. If continuous meeting chat is enabled, participants from the original event can receive chat messages sent in the new meeting even though they were never invited to it. And the guests who were properly invited to the new event may have to ask the host for permission to join.
Google's own worked example is a recruiter who uses one code for a candidate interview and then for the internal debrief. The hiring team has to knock to get in and cannot see the chat from before and after the meeting, while the candidate may find the debrief's notes and recording. Every part of that outcome is backwards from what was intended, and none of it required anyone to make a mistake beyond reusing a link.
Reusing a code that was created outside Calendar, at the Meet website for instance, has its own set of consequences. Continuous meeting chat is not available, meeting records can only be shared with the host, and invited guests may need to ask permission to join.
There is also a narrower point that is easy to get wrong. Google's guidance says plainly that meeting codes should not be reused as a way of hiding who is attending. The supported way to keep attendee names private is a single event with the guest list hidden, done by unchecking the guest permission to see the guest list.
Codes expire, and the clock differs by origin
Expiry rarely matters for an active weekly meeting and matters a great deal for a series that pauses over a summer.
For meetings started in Google Calendar, the documented rule has two conditions that both have to be true: the code has not been used for 60 days, and it is not associated with any future calendar events. A live recurring series with occurrences still ahead of it satisfies neither, which is why a long-running weekly meeting never expires. A series that ended, with a link people still keep, expires two months after its last use.
The number is different for codes created elsewhere, and the difference is large enough to matter when a link is inherited from somebody else.
| Where the code was created | When it expires |
|---|---|
| Google Calendar | After 60 days unused, and only if no future events use it |
| Gmail, Google Chat, the Meet website | 365 days after last use |
| Third-party software such as Outlook | 365 days after last use, extended by each use |
| Meeting room hardware | Instantly once everyone leaves |
| Meet breakout rooms | Instantly once the main meeting ends |
Google adds a clarification that closes a common assumption: a code generated in another product and then pasted into a Calendar invitation is not a Calendar-generated meeting, and it expires according to the product it came from. The event being in Calendar does not adopt the code.
Reading the warning when it appears
Meet shows a warning that says the meeting code is from a different meeting. It is the product telling someone, in advance, that the outcome described above is about to happen.
Google's instruction for it is unambiguous: if the reason is unknown or the other meeting cannot be identified, generate a new code. The route is to open the event, edit it, remove the current conference, save, then reopen the event and add Google Meet video conferencing again, which produces a code unique to that event.
Regenerating the code is not free, and the cost should be weighed before doing it in a hurry. The new link has to reach everyone holding the old one, and for a recurring meeting that means the people who never open the calendar entry because they open a bookmark instead. Sending the invitation update is the reliable half of that. Telling the participants in whatever channel they read is the half that actually works.
Two related settings are worth knowing while in that panel. An event can hold only one conference, and Google notes that pasting conference details into the location field or the description, or using a browser extension, can result in several conferences attached to a single event. And the option to add Meet automatically to every created event lives under Event settings, which is convenient and worth understanding as a default that will attach a fresh code to everything.
What to change first
Open the recurring series that people complain about and check whether its Meet link matches the one participants actually use, because an edit applied to this and following events now splits the link in two. If a desktop calendar on the Mac has been used to move that series, check the mail for a notice about a regenerated code. For a series that has to hold for a year, keeping the conference edits in a calendar built for Google Calendar's own event model, such as Caltimate, removes the most common way the link changes without anyone noticing.
Frequently asked questions
Does a recurring Google Meet meeting keep the same link every week?
Yes, while the series is left intact. The code is permanently linked to the original Calendar event until it expires, and for a recurring event it connects to the occurrence in progress or the next upcoming one. Editing the start time or recurrence for this and following events is what splits the series into two links.
Why did the Meet link change after the meeting time was moved?
Because since November 2025 Google generates a new, unique Meet link for the remaining occurrences when the start time or recurrence of a repeating event is changed for this and following events. The original series keeps the original link, and the conference properties such as host, cohosts, access restriction and recording are preserved on both.
Why does duplicating an event lose the Meet link?
Google stopped copying the Meet conference to copied and duplicated events in September 2025, so that Meet access and meeting notes stay tied to the original event and its attendees. The conference has to be added to the new event, or the old code pasted in deliberately, and there is no setting that restores the old behaviour.
Is it safe to reuse an old Meet link for a new meeting?
It carries real risks, because permissions remain tied to the original event's guest list. People invited to the original event may see recordings and files from the new meeting, they can receive continuous chat messages from it, and the correctly invited guests may have to ask the host for permission to join.
Do Google Meet codes for recurring meetings expire?
Not while occurrences remain. For meetings created in Google Calendar, expiry requires both that the code has gone unused for 60 days and that it is not associated with any future calendar events. Codes created in Gmail, Google Chat, the Meet website or third-party software such as Outlook expire 365 days after last use instead.