The BigTech Reseller IBM Exposure Campaign: Eighteen Doors Into the Same Building
One IBM Question, Eighteen Properties, Each Answering It From a Different Angle
The AS400System.com family went from 9,278 weekly impressions and 60 clicks before the update to 1,322 impressions and 1…
What was measured.
Five readings across three measurement dates on an 18 property family. The numbers got worse between the first and the last, and they are presented in that order rather than reorganized into something flattering.
An 85.8 percent loss in seven days, with clicks going from 60 to 1. Before this the subdomain architecture was a reasonable theory. After it, it was a measurable cost.
Crawling held steady and even ticked up while visibility collapsed. Google never stopped reading the pages. It stopped showing them, which separates a crawl problem from a ranking one.
No recovery. Seventy three pages still earning impressions, at an impression weighted position past sixty, which is visibility that cannot convert.
Recognized bot requests stayed nearly flat while successful content crawling fell. The September interim is where the one reassuring signal started slipping too.
Nothing punitive explains any of this. The architecture is being held because 18 properties still have genuinely distinct jobs, not because the numbers have started agreeing with the decision.
A historical blind spot is worth stating: direct cPanel subdomain log discovery was broken until 24 August 2026 and then backfilled, so bot figures from before that date and after it are not measured the same way.
The short version.
The BigTech Reseller IBM Exposure Campaign is Project Everywhere applied to one vertical: 17 AS400-family properties plus BigTechReseller.com, each with a distinct role. Every established AS400System.com host lost visibility together on August 22. The September 11 interim still shows no recovery: 705 weekly impressions versus the 9,278 baseline, down 92.4 percent. The architecture is staying, but the crawler receipt is now more qualified after the warehouse classification repair.
Explain it to me like I'm ten.
Picture one big popular store. Now imagine splitting it into eighteen little specialty shops spread around town.
Each shop has a real reason to exist. One sells only shoes, one sells only coats. That part makes sense.
But right after we split it up, the number of people finding us dropped hard. In one week it fell about eighty six percent, and actual visitors went from sixty down to one.
Here is the confusing part. Google's robot kept coming by and reading everything just as much as before. So it is not that Google stopped visiting. Google just stopped telling people about us.
Three weeks later it still had not come back.
We checked whether we were in trouble with Google, like a penalty. We are not. Nothing is broken and nothing is against the rules.
We are keeping the eighteen shops for now, because each one really does do a different job. But we are being straight about it: the numbers have not agreed with that decision yet.
What was the system?
AS400System.com, AS400Software.com, AS400IBMSystem.com, and AS400IBMSystems.com are the flagship base properties. Around them sit Power 5 through Power 12 generation-specific subdomains, an AI subdomain covering IBM Bob and watsonx on IBM i, a FlashSystem storage-hardware subdomain, two Pricing subdomains splitting hardware and software economics, and a Security subdomain for IBM i-specific protection. BigTechReseller.com sits outside the as400.* namespace entirely, as the multi-vendor comparison layer where IBM competes against Dell, HPE, and others on the same buyer's page. None of these were built as duplicate coverage of the same content. Each one exists because a different real buyer question needed a property built around answering just that question well, per Krisada's established portfolio philosophy that redundancy crowds out competitors rather than competing with itself.
What changed?
The build order tracked real gaps as they were found, not a fixed roadmap. Power 9 AS400System.com got dedicated lifecycle, sourcing, and migration content after earlier end-of-life articles showed real demand. AI.AS400System.com launched to cover IBM's AI-on-IBM-i push. FlashSystem.AS400System.com became the storage decision layer, then expanded again when IBM shipped a fifth FlashCore Module generation. Pricing.AS400System.com and Pricing.AS400Software.com split hardware economics from software licensing economics. Power 5 and Power 6 were rebuilt as legacy-hardware decision sites once their infrastructure was ready.
The campaign reached twelve hosts and 781 submitted URLs inside the AS400System.com branch. The live Digital Karma Data Warehouse tracks each Google Search Console property, query, page, country, device, human request, and verified crawler request independently. That made it possible to compare August 15 through 21 against August 22 through 28 without treating one dashboard line as the whole story.
The comparison also used portfolio controls. If AS400 and IBM Power demand had collapsed everywhere, the sibling sites should have fallen with AS400System.com. They did not. AS400Software.com rose 5.2 percent, AS400IBMSystems.com rose 4.8 percent, and AS400IBMSystem.com rose 282 percent during the same comparison window. The synchronized loss stayed inside the AS400System.com domain family.
What did the evidence show?
The AS400System.com family went from 9,278 weekly impressions and 60 clicks before the update to 1,322 impressions and 1 click after it. That is an 85.8 percent impression loss and a 98.3 percent click loss. The break began August 22, the day after Google's global August 2026 spam update finished. Google's incident record confirms the rollout ended August 21.
The evidence still does not point to a technical outage. Search Console reported no manual action and no security issue. It reported 683 indexed pages on August 27. The root pages, robots file, sitemaps, and representative subdomain homepages returned HTTP 200.
The crawler comparison needed a correction after the warehouse repaired bot classification and successful-content measurement. Recognized Googlebot requests were 935 before and 979 after, up 4.7 percent. Successful Googlebot content requests were 819 before and 847 after, up 3.4 percent. The original 938-to-984 receipt was close, but it came from the measurement available on September 3 and should not be treated as the final definition.
The September 11 interim is worse on Google and mixed on crawling. September 2 through 8 produced 705 impressions, 1 click, a weighted average position of 61.6, and 73 pages with impressions. That is 92.4 percent below the baseline impression count. Recognized crawler requests across the family were nearly flat, 3,430 versus 3,501, while successful crawler content requests fell from 2,691 to 2,133. Successful Googlebot content requests fell from 819 to 460. Bot requests did not disappear with rankings. Successful content crawling did not remain untouched either.
The timing confounder remains. Several specialist subdomains and network relationships launched immediately before the update. That does not prove the architecture caused the loss, and it prevents a clean story that it had nothing to do with it. The decision is still to keep distinct specialist roles and measure through the reclassification.
What can be reused?
The August loss made the subdomain argument measurable. The September interim made it uncomfortable. Google visibility has not recovered, and successful content crawling is now down even though recognized bot requests remain almost flat. The architecture stays because the properties still have distinct jobs, not because the numbers have started telling a recovery story.
Keep Browsing the Case Library
Move from this evidence file back into the full proof system.