Between April 7 and May 4, 2026, lawncareguides.com got 920 users from Bing organic search and 17 from Google organic, a ratio of 54 to 1. For that entire window, the site’s code named www.lawncareguides.com as its address, and by May 16 the host was redirecting www to the bare domain.
I rebuilt this site with Claude Code, and the repository now has 395 commits. This post lines up the traffic numbers against four of those commits. I will be clear about what the record proves and what I am inferring, because the record does not prove the cause.
How big was the gap between Bing and Google?
This is the GA4 export for the 28 days, by source, in active users. The site total was 3,523. I recomputed every share from the user counts.
| Source | Users | Share of 3,523 |
|---|---|---|
| Bing organic | 920 | 26.1% |
| DuckDuckGo organic | 771 | 21.9% |
| Direct | 705 | 20.0% |
| Yahoo organic | 495 | 14.1% |
| OpenAI referral | 364 | 10.3% |
| ChatGPT (combined) | 128 | 3.6% |
| Copilot (combined) | 45 | 1.3% |
| Google organic | 17 | 0.5% |
| Other | about 78 | 2.2% |
Four search engines sent 2,203 users between them. Google sent 17 of those, or 0.77%. Bing, DuckDuckGo and Yahoo together sent 2,186, which is 62% of all traffic to the site.
Google was weak before the rebuild too. The oldest Search Console export in the repo has daily rows from November 17 to December 13, 2025. Those rows add up to 3 clicks and 844 impressions.
The same file has a summary block that says 1 click and 676 impressions. That summary equals the sum of the file’s query table exactly, so I believe it was built from queries alone. That is my inference. The file’s header also claims a range starting September 17, but the daily rows start in November. I use the daily rows, and I would not quote the summary.
What were the canonical tags saying during that window?
They named the www host, on every page. On January 27, 2026, a commit titled “Fix sitemap URLs to use www subdomain” changed the site address in astro.config.mjs from the bare domain to www. Every canonical tag, every sitemap URL and the structured data are built from that one setting.
On May 16, a second commit flipped it back across 80 files. Its message says the host “301-redirects www to apex now,” and that the sitemap was emitting www URLs that were “every one a 301 hop on crawl.”
Read the two messages together. On January 27 the code was matched to a www host. By May 16 the host sent www to the bare domain. So the host’s primary domain changed somewhere in those 109 days, and the code did not follow it until May 16.
Google’s canonicalization guide calls a redirect “a strong signal that the target of the redirect should become canonical.” It calls rel="canonical" “a strong signal that the specified URL should become canonical.” It also says: “Don’t specify different URLs as canonical for the same page using different canonicalization techniques.”
Once the host flipped, this site did exactly that. The canonical tag said www. The redirect said the bare domain. The sitemap, which the guide counts as a weaker signal, listed URLs that each answered with a redirect.
Here is the limit. The date the host flipped is not in the data I have. The repo does not record it, and the hosting project was not visible to the account I checked with. If the flip came before April 7, the whole GA4 window ran on contradictory signals. If it came after May 4, it did not, and the 17 needs another explanation.
Why did 53 pages carry two canonical tags?
Because the canonical tag was written in two places. The shared head component emits one for every page. Individual pages also hard-coded their own, and nobody removed them when the shared one arrived.
On May 4, 27 page source files carried their own canonical, all on www. By May 16 that was 48 files. By July 31 it was 53.
The trailing slash turned this from untidy into contradictory. Also on May 16, a crawlability commit set trailingSlash: true on the host and made the shared canonical always end in a slash. The hard-coded canonicals had no slash. A URL without the slash now answered with a 308 redirect.
So for the 76 days from May 16 to July 31, each of those pages named two canonicals. One was the live page. The other was a URL that redirected to it.
The July 31 commit removed them and added a prebuild check, scripts/check-canonical.js, that fails the build if any page file contains its own canonical tag. The commit message says 54 pages. The diff removes 53 canonical lines from 53 files, so 53 is the number I use.
What does “Page with redirect” in Search Console mean?
Google’s page indexing report help defines it plainly: “This is a non-canonical URL that redirects to another page. As such, this URL will not be indexed.” The same page lists it under “Not indexed” and says that status is “not necessarily bad.”
It became a problem here because the site was generating those URLs itself. On September 13, the commit message records that Search Console reported about 105 URLs as “Page with redirect.” The cause was internal links without the trailing slash, each one a 308 hop.
That commit added the slash to 1,754 internal links, dynamic links and schema URLs, by its own count. It took redirect stubs and thank-you pages out of the sitemap and fixed 10 links to pages that did not exist. It also added a second prebuild check so a slashless internal link fails the build.
Bing’s Webmaster Guidelines name the same waste from their side. They tell you to avoid “outputting excessive or low-value URLs, such as duplicate content.” They also say “Duplicate URLs dilute signals and reduce Bing’s confidence in selecting a URL.”
Doesn’t Bing’s traffic prove Google was the problem?
No, and this is the assumption I made first. The May 5 analytics notes concluded the content was “clearly good” and the issue was likely specific to Google. That reads well and proves nothing.
Bing’s own guidelines penalize the same things Google’s do: duplicate URLs, crawl waste, and canonical tags used where a redirect belongs. They even say to “use redirects instead of canonical tags” when content moves. The two engines publish matching rules, so a 54 to 1 gap does not show that one of them ignored a rule.
What the gap shows is that two engines reached different conclusions about the same site. The canonical conflicts are documented and dated. That they caused Google’s 17 users is an inference I cannot yet test. The May 5 notes listed three other candidates: an indexing problem, a manual action and a young domain. None of them was ruled out in the repo.
One more trap. The December Search Console export was pulled from a URL-prefix property for the bare domain over https. From January 27 to May 16 the canonical tags named www. Whether Google’s data for www URLs showed up in that property is not something the export can answer. Check which property type you are reading before you trust a zero.
What does the site look like now?
I checked it from the terminal on October 8, 2026, read-only. Here is the homepage and one review page:
$ curl -sI https://www.lawncareguides.com/
HTTP/2 301
location: https://lawncareguides.com/
$ curl -sI https://lawncareguides.com/reviews/zero-turn-mowers
HTTP/2 308
location: /reviews/zero-turn-mowers/
$ curl -s https://lawncareguides.com/reviews/zero-turn-mowers/ | grep canonical
<link rel="canonical" href="https://lawncareguides.com/reviews/zero-turn-mowers/">The homepage, the zero-turn mower review, the dandelion guide and the tall fescue guide each return 200. Each has exactly one canonical tag, on the bare domain, ending in a slash. The sitemap lists 143 URLs. I requested all 143, and all 143 returned 200 with no redirect. None are on www.
Did Google traffic recover after the fixes?
I don’t know yet. There is no GA4 or Search Console export in the repo dated after May 5, 2026. The last fix shipped on September 13, 25 days before I checked the live site, and the www fix shipped 145 days before.
What should you check if Bing outsends Google on your site?
- Split organic users by engine in GA4 and compute Google’s share of search users, not of all users. Here it was 0.77%.
- Run
curl -sIon the www and bare versions of your homepage. Write down which one returns 200. - View the source of three pages, including the homepage. Count the canonical tags. There should be one, on the host that returned 200.
- Find every place your code names the site address. Keep it in one setting, and change it the same day anyone changes the primary domain in your hosting dashboard.
- If your host enforces a trailing slash, every internal link, canonical and sitemap URL must end in one. Add a build check so it stays that way.
- Request every sitemap URL. Anything that does not return 200 is a URL you are suggesting and not serving.
- Open the Search Console page indexing report on a Domain property. Read the “Page with redirect” count and the URL Inspection result for your top Bing landing page.
- When a report’s summary disagrees with its own rows, recompute from the rows and say which number you used.
Related fixes: trailing slash canonical mismatches in Next.js on Vercel, and canonical tags that point at a redirect after a www and bare-domain mismatch.
Sources
- Google Search Central, How to specify a canonical URL (page updated 2026-07-10, fetched 2026-10-08).
- Google Search Console Help, Page indexing report (no update date shown, fetched 2026-10-08).
- Bing Webmaster Tools, Bing Webmaster Guidelines (no update date shown, fetched 2026-10-08).
- The lawncareguides.com repository: GA4 analytics notes dated May 5, 2026, the December 2025 Search Console export, and commits from January 27, May 16, July 31 and September 13, 2026.
- The live site, checked with curl on October 8, 2026.
