Sean Walsh
Sean is a Director at Intelligency heading up our digital marketing and client services operations. Sean has 15+ years experiencing working both in-house and agency with brands including Lloyds, Alstom, Hitachi, Lufthansa, Viaplay, DFDS Seaways and Mercedes-Benz.
A new website launches. The redirects are in place, the content has carried over, the pages look great, and nothing is obviously broken. Then, a few weeks later, organic traffic is flat or down, and someone asks the obvious question: what went wrong?
Google has again said that new sites simply take time to be understood, and fresh guidance on website migrations shows that keeping your URLs the same is not the safety net many people assume. Together they explain why a launch can wobble even when it was done properly, and what to do about it.
Google says new sites need time to prove their value
On 10 November, Google’s John Mueller responded to a site owner whose relatively new website wasn’t being indexed as fully or as quickly as they wanted. The site had a working sitemap with several hundred URLs, no manual actions and no obvious technical faults, but the “Request indexing” tool in Search Console kept failing.
Mueller’s answer was simple: “it can take time for the systems to understand the unique value” of a new site. His advice was to focus on quality over quantity, and to rely on normal crawling and indexing rather than repeatedly pushing pages through the request indexing tool.
That matters because it reframes the problem. A new site is not being held back by a penalty or a bug. Google is still working out what the site offers that others don’t, and that judgement is built up over time from how the content performs, how it is linked to and how people engage with it. Publishing more pages faster does not shortcut it.
Keeping the same URLs doesn’t mean nothing has changed
The second piece of news is about rebuilds rather than brand new sites. A Search Engine Land article published on 9 November made the point that a migration can damage SEO even when every URL stays the same.
Most migration checklists focus on redirects, because changing URLs is the obvious risk. But when a site moves to a new CMS, theme or framework, a lot of the work that search engines rely on happens below the URL. Things that the old platform handled quietly in the background can change, disappear or start behaving differently, even though the page looks identical to a visitor. The main ones are:
- Canonical tags. These tell Google which version of a page is the main one. On the old site, a plugin might have generated them correctly; on the new build,d they may be missing or point to the wrong place.
- Internal links and navigation. Menus, breadcrumbs and “related content” blocks may now rely on JavaScript. If links aren’t in the page’s initial HTML, Google can find it harder to discover pages and understand how they relate.
- Status codes. A missing page should return a proper 404. Some new builds show a friendly “not found” page but tell Google everything is fine, which muddies what gets indexed.
- Structured data and robots directives. Schema, noindex rules and sitemaps are often generated by different parts of the new system, and any one of them can slip.
None of these shows up in a visual check. The site can look perfect and still be sending Google weaker or conflicting signals than the old one did.
And the settling period can run for months.
This builds on comments Mueller made in October, when a site owner described a domain migration that appeared to have gone smoothly, only for Google to start favouring the old domain again around four months later. Mueller acknowledged that migrations can sometimes take a particularly long time to be fully processed, and pointed to one easily missed step: making sure the Search Console change of address is set up for both the www and non-www versions of the domain.
The wider lesson is that a migration is not a single launch-day event. Google re-crawls, re-evaluates and re-ranks over weeks and sometimes months. Early stability is encouraging, but it isn’t the end of the story.
Why the timing makes this harder right now
Google’s November 2026 core update started rolling out on 10 November and is expected to take around two weeks. Any site launching or migrating in that window will see the usual settling-in movement mixed with wider ranking volatility across the whole of search, plus normal seasonal swings in the run-up to Christmas. Separating “our new site” from “the whole market moved” is genuinely difficult for the next few weeks, which is exactly when panicked changes tend to happen.
What marketers should do before a launch?
- Capture a baseline. Before anything changes, record how your most important page types behave today: the homepage, key service or category pages, top articles and a few known 404s. Note the status code, canonical, robots directives, structured data and the internal links on each.
- Map who is responsible for each SEO element. Ask your developers where canonicals, sitemaps, redirects, schema and navigation links will be generated on the new build. If nobody owns a signal after launch, it is the one most likely to quietly disappear.
- Test what changed, not just what it looks like. Check pages with a crawler and in Search Console’s URL Inspection tool, request a deliberately broken URL to confirm it returns a 404, and confirm the important links and content are in the page source rather than only appearing after JavaScript runs.
- Cover the admin steps. If the domain is changing, set up the change of address in Search Console for every version of the domain, submit the new sitemap and update profiles and listings you control, including your Google Business Profile.
What to do after it goes live
- Monitor by page type, not just the total. A drop in one template (for example, all location pages) points to a shared technical cause far faster than a site-wide traffic line does.
- Watch the Page Indexing report in Search Console. Growth in “crawled, currently not indexed” or unexpected canonical choices is an early warning worth investigating.
- Don’t lean on “Request indexing”. As Mueller said, normal crawling does the heavy lifting. Strong internal links from your most visited pages will help new content get found faster.
- Keep publishing quality, not volume. A new or rebuilt site earns trust through genuinely useful pages, not by flooding the index.
- Resist knee-jerk changes. Give a launch several weeks before conclusions, especially during a core update. Fix genuine technical faults straight away, but avoid rewriting content or restructuring navigation in response to normal early movement.
