It's May 20, 2026, and I'm looking at a Local Pack that would have been unrecognizable to me two years ago. Three-pack. No three-pack. Expanded tiles. Collapsed tiles. AI-generated summaries sitting right above the business name. The past four months have been a sustained exercise in rebuilding local SEO strategies I thought were stable, for clients who had no idea the ground was shifting until their phone stopped ringing.
I specialize in local SEO for service-area businesses — HVAC contractors, personal injury attorneys, residential plumbers, dental groups. Eleven years of that work. The early-2026 Google Business Profile redesign hit my client roster harder than any update since the Possum rollout, and the recovery work has been some of the most technically specific, painstaking work I've done in my career. This article is a record of what I've learned. Not a prediction piece. Not a "here's what Google announced." What I actually found in the data from February through right now.
What Actually Happened in February
Google began rolling out the GBP redesign on February 4, 2026. The dashboard interface changed first. Then the public-facing profile cards started shifting. By February 19, the old "Products" carousel and the legacy "Services" menu tab structure were gone from most verticals. Hospitality kept a modified version. Home services lost it almost entirely.
The shift wasn't announced with the kind of fanfare you'd expect for something that disrupted this many business profiles. Google posted one support document. One. And it was structured like an FAQ for a completely different rollout they'd partially merged with this one by accident — or so it seemed at the time. The actual substantive changes were buried in a March 3 update to the Google Business Profile Help Center that most people only found because someone screenshotted it in a LinkedIn comment thread.
What changed in the public-facing Pack results is harder to characterize simply. The visual real estate of the Pack expanded in some queries and contracted in others. On mobile, the Pack went from a relatively predictable three-result display to what Google's internal documentation calls a "fluid card stack" — meaning anywhere from one to five results display based on query confidence scoring and user device context. I started seeing this in my clients' Google Search Console data in early February, before any formal announcement: the impression counts for local queries were spiking erratically, while click-through rates collapsed on specific devices.
The Fluid Card Stack in Practice
A plumbing client in Charlotte was ranking third in the local Pack for "emergency plumber Charlotte" throughout January. Consistent. Reliable. Then the fluid card behavior started, and on mobile the Pack collapsed to two results about 60% of the time — using a confidence threshold that seemed to be correlated with the user's distance from the business cluster. My client's profile, which had previously appeared because it was geographically central to the query, started appearing only when all three results had high-confidence signals. Her call volume dropped 34% in February and she thought she'd done something wrong on her end. She hadn't.
The fix wasn't obvious. It wasn't about getting more reviews. It wasn't about posting more often. It was about what the redesign had done to how Google was reading her profile's completeness signals — specifically, the attributes and service categories that had been reorganized in the backend.
The Features That Disappeared Overnight
Let me be specific. The following features were removed or significantly altered in the February 2026 GBP redesign, across most (not all) business categories:
- The standalone "Services" tab as a navigable menu item on the public profile card
- The ability to add custom service descriptions longer than 300 characters (trimmed from 1,000)
- The "Products" carousel in home services, legal, and healthcare verticals
- Third-party booking integration deep links that previously appeared as prominent CTA buttons
- The "Questions & Answers" section's visibility on desktop Pack results (it still exists but no longer surfaces in Pack snippets)
- The legacy "Attributes" display format — replaced by an AI-parsed summary of attributes rather than the attribute labels themselves
That last one is the one causing the most confusion right now. When you added attributes to a GBP listing — "wheelchair accessible," "women-led," "free Wi-Fi" — those attributes used to appear as readable labels on the profile. Now the AI summary layer ingests those attributes and may or may not surface them in the generated business description shown in the Pack card. Whether they appear depends on how the AI summary model weights them for a given query context. You no longer have direct control over what attribute language shows up on your profile card in the Pack.
What Survived the Cut
Photos. Photos survived and actually got more prominent. The photo display in the Pack card went from a single static image to a scrollable gallery strip on desktop and a full-bleed auto-rotating image on mobile. I've watched this shift click-through behavior in real time for several clients. Image quality matters more than it did six months ago. Not quantity. Quality and recency — Google appears to weight images uploaded in the last 60 days more heavily in the Pack display.
Review quantity and recency survived too. No surprise there. But review response rate — whether you respond to reviews, not just how well — seems to have taken on new weight. Three of my clients who were borderline on Pack inclusion saw measurable improvement after we implemented consistent review response protocols in March. Correlation, not causation, but I've now seen it enough times to treat it as a working hypothesis.
Pack Signals Are Not What You Think Anymore
The local SEO community has been reliably wrong about which signals actually drive Pack ranking for as long as there's been a Pack. I was wrong about some of them too — more on that in a minute. But the 2026 redesign has made a specific set of assumptions obsolete that I want to address directly.
The first assumption: citation volume still functions as a primary proximity-independent trust signal. It doesn't. Or rather, it functions much less than it did. The redesign appears to have coincided with a backend weighting adjustment that reduced the ranking contribution of NAP citations from aggregator directories — the Yext/Brightlocal/Whitespark ecosystem of directory submissions that formed the backbone of local SEO citation strategies for a decade. I can't tell you the exact magnitude of the change because Google hasn't disclosed it and I can't isolate it cleanly in my data. But I can tell you that several clients whose citation profiles were impeccable showed almost no Pack recovery after the redesign, while other clients with messier citation situations recovered faster once we fixed profile-level issues. That's a signal worth paying attention to.
The Proximity Signal Got Weirder
Proximity has always mattered in local rankings. The 2026 redesign made the proximity calculation stranger. I'm seeing Pack inclusions for queries at distances that previously would have excluded a business, paired with Pack exclusions at distances that previously would have included one. The distance thresholds appear to be dynamic now — varying by vertical, by query volume, by time of day, and by what Google characterizes as "local supply confidence." If there are three strong plumbing signals within a two-mile radius, the Pack radius contracts. If local supply is thin, the radius expands, sometimes dramatically.
A client of mine — a sole-practitioner family law attorney in a mid-size city — started appearing in Pack results for queries centered 12 miles from her office address. Twelve miles. That's unusual. It happened because two larger competing firms in her area lost Pack visibility after the redesign due to profile incompleteness issues, and the supply confidence calculation expanded her effective radius. Documenting that pattern has changed how I think about geographic expansion strategies entirely.
My LSAP Framework for Recovery Work
After running recovery audits on 23 client profiles since February, I developed a working framework I call LSAP: Legitimacy, Signals, Attributes, Photos. In that order. Not interchangeable. The order matters because each layer depends on the layer before it being solid.
Legitimacy means the profile fundamentals — business name matching exactly across the GBP listing, website, and primary citations; category selection being as specific as the taxonomy allows; service area definitions being accurate (not aspirationally large); and the profile being verified in a way that Google's current systems accept as high-confidence. Several clients had verification status that showed as complete in the old dashboard but was flagged internally in the new one. Fixing that first, before anything else, cleared phantom ranking suppression I couldn't explain otherwise.
Signals means the behavioral signals Google is pulling from the profile: review recency, review response consistency, post frequency (weekly at minimum, I've found), and Q&A completeness. Yes, Q&A still matters even though it's less visible in the Pack card now. It matters in the AI summary layer — the model reads Q&A content when generating the AI-written business description.
Attributes in 2026 means auditing every attribute you've set and auditing the AI summary that now represents those attributes publicly. You can request an AI summary refresh through the GBP dashboard — it's buried under the "Profile completeness" section, labeled "Update business information summary." Submit it, then monitor what the summary says over the following 7-14 days.
Photos means a structured upload cadence with attention to EXIF data (geotag within your service area where appropriate and legitimate), image subject variety, and regular pruning of low-engagement older images. Google's own help documentation now explicitly states that "frequently updated, high-quality photos improve profile performance." They've never said that so directly before.
Running a Clean NAP Audit in 2026
The mechanics of a NAP audit haven't changed as much as the signals they're connected to, but the tools have, and what you're looking for has shifted. Here's the core script I use to pull NAP inconsistencies from a crawl dataset. This assumes you've exported your citation list as a CSV from whatever tool you're using (Whitespark, BrightLocal, etc.).
#!/usr/bin/env python3
"""
NAP Consistency Auditor — 2026 Edition
Checks business name, address, and phone against canonical values.
Usage: python nap_audit.py --canonical canonical.json --citations citations.csv
"""
import csv
import json
import argparse
import re
from difflib import SequenceMatcher
def normalize_phone(phone_str):
return re.sub(r'\D', '', phone_str or '')
def normalize_name(name_str):
return re.sub(r'[^\w\s]', '', (name_str or '').lower()).strip()
def similarity_score(a, b):
return SequenceMatcher(None, a, b).ratio()
def audit_nap(canonical_path, citations_path, threshold=0.85):
with open(canonical_path, 'r') as f:
canonical = json.load(f)
canon_name = normalize_name(canonical['name'])
canon_phone = normalize_phone(canonical['phone'])
canon_address = canonical['address'].lower().strip()
issues = []
with open(citations_path, newline='', encoding='utf-8') as csvfile:
reader = csv.DictReader(csvfile)
for row in reader:
source = row.get('source', 'unknown')
row_name = normalize_name(row.get('business_name', ''))
row_phone = normalize_phone(row.get('phone', ''))
row_address = (row.get('address', '') or '').lower().strip()
name_score = similarity_score(canon_name, row_name)
phone_match = (canon_phone == row_phone)
addr_score = similarity_score(canon_address, row_address)
if name_score < threshold or not phone_match or addr_score < threshold:
issues.append({
'source': source,
'name_score': round(name_score, 3),
'phone_match': phone_match,
'address_score': round(addr_score, 3),
'raw_name': row.get('business_name'),
'raw_phone': row.get('phone'),
'raw_address': row.get('address'),
})
return issues
if __name__ == '__main__':
parser = argparse.ArgumentParser(description='NAP Consistency Auditor')
parser.add_argument('--canonical', required=True)
parser.add_argument('--citations', required=True)
parser.add_argument('--threshold', type=float, default=0.85)
args = parser.parse_args()
results = audit_nap(args.canonical, args.citations, args.threshold)
print(f"\nInconsistencies found: {len(results)}\n")
for issue in results:
print(f"Source: {issue['source']}")
print(f" Name similarity: {issue['name_score']} | Phone match: {issue['phone_match']} | Address similarity: {issue['address_score']}")
print(f" Raw: {issue['raw_name']} | {issue['raw_phone']} | {issue['raw_address']}\n")
Run this against a fresh citation pull every quarter. The output gives you a ranked list of inconsistent citations with similarity scores so you can prioritize fixes by severity rather than treating all inconsistencies as equal urgency. A name similarity score below 0.70 is a high-priority fix. Between 0.70 and 0.85, triage based on the domain authority of the citing source.
For the canonical.json file the script expects, the format is simple:
{
"name": "Charlotte Emergency Plumbing LLC",
"phone": "+17045550183",
"address": "4412 Albemarle Road Suite 200, Charlotte, NC 28205"
}
Schema and GBP API Patterns That Still Hold
The GBP API (now officially part of the Google Business Profile API v4.9, updated in March 2026) changed its endpoint structure for location attributes. If you're managing multi-location clients programmatically, you'll have noticed that attribute category IDs shifted and several legacy attribute keys now return deprecation warnings rather than errors. The silent deprecation is the problem — your code continues running, you get no error, and the attributes simply don't write to the profile.
Here's the pattern I now use for attribute updates via the API that correctly handles the deprecation check:
import requests
GBP_API_BASE = "https://mybusinessbusinessinformation.googleapis.com/v1"
def get_available_attributes(location_name, access_token, category_id):
"""
Fetch currently valid attribute metadata for a location's primary category.
Use this before writing attributes to avoid silent deprecation failures.
"""
headers = {
"Authorization": f"Bearer {access_token}",
"Content-Type": "application/json"
}
params = {
"categoryName": category_id,
"regionCode": "US",
"languageCode": "en"
}
url = f"{GBP_API_BASE}/attributes"
response = requests.get(url, headers=headers, params=params)
response.raise_for_status()
data = response.json()
# Build a set of currently valid attribute IDs
valid_ids = {attr["attributeId"] for attr in data.get("attributeMetadata", [])}
return valid_ids
def update_location_attributes(location_name, attributes, access_token, category_id):
"""
Write attributes to a GBP location, skipping deprecated keys.
"""
valid_ids = get_available_attributes(location_name, access_token, category_id)
filtered_attributes = [
attr for attr in attributes
if attr.get("attributeId") in valid_ids
]
skipped = len(attributes) - len(filtered_attributes)
if skipped > 0:
print(f"Warning: {skipped} attribute(s) skipped — deprecated or invalid for this category.")
headers = {
"Authorization": f"Bearer {access_token}",
"Content-Type": "application/json"
}
payload = {"attributes": filtered_attributes}
url = f"{GBP_API_BASE}/{location_name}"
response = requests.patch(
url,
headers=headers,
json=payload,
params={"updateMask": "attributes"}
)
response.raise_for_status()
return response.json()
And for the LocalBusiness JSON-LD on your website — which feeds into how Google cross-references your on-site signals with the GBP profile data — here's the current pattern I'm using for home service clients. Note the hasOfferCatalog block, which is how I'm replacing the lost "Services" tab data in on-site schema now that it no longer has a profile-level counterpart:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Plumber",
"name": "Charlotte Emergency Plumbing LLC",
"image": "https://www.charlotteemergencyplumbing.com/images/logo-2026.jpg",
"url": "https://www.charlotteemergencyplumbing.com",
"telephone": "+17045550183",
"priceRange": "$$",
"address": {
"@type": "PostalAddress",
"streetAddress": "4412 Albemarle Road Suite 200",
"addressLocality": "Charlotte",
"addressRegion": "NC",
"postalCode": "28205",
"addressCountry": "US"
},
"geo": {
"@type": "GeoCoordinates",
"latitude": 35.2271,
"longitude": -80.8431
},
"openingHoursSpecification": [
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
"opens": "07:00",
"closes": "19:00"
},
{
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Saturday"],
"opens": "08:00",
"closes": "16:00"
}
],
"hasOfferCatalog": {
"@type": "OfferCatalog",
"name": "Plumbing Services",
"itemListElement": [
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Emergency Plumbing Repair",
"description": "24-hour emergency plumbing repair for burst pipes, water heater failures, and sewer backups in Charlotte and surrounding areas."
}
},
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Water Heater Installation",
"description": "Installation and replacement of tank and tankless water heaters. Licensed and insured."
}
},
{
"@type": "Offer",
"itemOffered": {
"@type": "Service",
"name": "Drain Cleaning",
"description": "Hydro-jetting and mechanical drain cleaning for residential and light commercial properties."
}
}
]
},
"aggregateRating": {
"@type": "AggregateRating",
"ratingValue": "4.8",
"reviewCount": "214"
},
"areaServed": [
{"@type": "City", "name": "Charlotte"},
{"@type": "City", "name": "Concord"},
{"@type": "City", "name": "Gastonia"},
{"@type": "City", "name": "Matthews"}
]
}
</script>
The areaServed array now feeds directly into how Google cross-validates service area claims on the GBP profile. If your schema says you serve Concord but your GBP profile doesn't have Concord in the service area list, the mismatch registers as a legitimacy signal discrepancy. I started aligning these systematically across all my clients in March and have seen it correlate with Pack inclusion at the edges of service area boundaries. See also my earlier post on service area page architecture for the on-site component of that strategy.
Two Things the Community Got Wrong
I'm going to be direct here because I think the mainstream local SEO conversation has gone in two wrong directions since February, and I've seen clients spend money on strategies that aren't working.
Wrong take number one: posting frequency is the Pack recovery lever. I have seen this advice everywhere — post more to your GBP, post daily if you can, the redesign rewarded active profiles. There's a grain of truth in there, but the framing is misleading in a way that matters. Posting frequency correlates with Pack performance, but it's not causally responsible for it. What I've seen in my data is that the businesses that post frequently also tend to be the businesses that respond to reviews promptly, keep their hours accurate, and update their categories when needed. They're doing more things right across the board. Isolating posting frequency as the intervention and cranking out daily low-quality posts — which is what the "post more" advice tends to produce in practice — does not move the needle. Three of my clients tried it for six weeks. Two of them saw no Pack improvement. One actually saw a slight regression, which I attribute to the low engagement rate on the volume posts depressing their overall profile interaction signals.
Wrong take number two: the AI summary is out of your control, so ignore it. I've heard this from people I respect in the industry, and I disagree with it fundamentally. The AI summary is generated from your GBP data, your website content, your reviews, your Q&A content, and your attributes. You have significant indirect control over what the AI summary says. The playbook is: audit the summary text that's currently showing, identify gaps or inaccuracies, then trace those back to the source data that's generating them. Update the source data. Request a summary refresh. Monitor. It takes time — sometimes 3-4 weeks for the summary to fully regenerate — but it's absolutely actionable. I've corrected AI summaries that were describing one client as serving an area she'd stopped serving two years ago, and another that was mischaracterizing a dental practice's specialty focus. Both corrections required no special access or API magic. Just systematic source data cleanup.
The broader point: the 2026 redesign moved control from explicit settings to implicit signals. That's frustrating. But it doesn't mean control is gone. It means you have to understand which signals feed which outputs, and work accordingly. That's harder. It's also more durable — because when you fix a fundamental signal, it doesn't break when Google changes the interface layer again. Google's official Business Profile API documentation is worth reading carefully here; the signal taxonomy they describe in the developer docs is more explicit than anything in the help center.
The Mistake I Made With a Roofing Client
I want to be honest about this because it cost a client time and money and I should have known better.
In late February, after the redesign hit, I was running Pack recovery work for a roofing contractor in the Atlanta metro. He'd lost Pack visibility for his primary target keyword almost immediately. I diagnosed it as a profile completeness issue related to the attribute restructuring and spent three weeks on attribute cleanup, AI summary work, and photo cadence improvements. All legitimate work. None of it was the problem.
The actual problem was that his GBP profile had a duplicate. An old listing from when the business had a slightly different name — "Hargrove Roofing & Gutters" vs. the current "Hargrove Roofing" — had come back to life in the redesign migration. Google's system had reactivated a dormant listing when it migrated profiles to the new backend. The duplicate was competing with the primary listing in the Pack and the primary listing was losing that internal competition because the duplicate had slightly higher review count from years of accumulated reviews before the business rebranded.
I should have done a duplicate audit as the first step. I've done duplicate audits before in my workflow but I skipped it here because the client had done a clean brand consolidation and I assumed the old listing was gone. Assumption without verification. Classic mistake. Once we found the duplicate, filed a duplicate report, and got it suppressed — which took about 11 days — the primary listing recovered Pack visibility within a week. Three weeks of work I'd done on the profile was largely wasted effort. The client was generous about it, but I felt the lesson pretty hard.
Duplicate audits are now step one in every LSAP engagement I run. Non-negotiable. And if you're doing recovery work for anyone post-February 2026, check for duplicates before you do anything else. The redesign migration appears to have reactivated dormant listings at a rate significantly higher than normal — I've seen it in four of my twenty-three recovery cases, which is about 17%. That's not a rounding error. See also my guide on handling GBP duplicate listings for the full process.
Where We Actually Stand Right Now
It's mid-May 2026. Most of my clients who lost Pack visibility in February have recovered it, or are in the final stages of recovering it. The fluid card stack behavior has stabilized somewhat — I'm seeing fewer extreme Pack size variations than I was in February and March, which suggests Google has been tuning the confidence thresholds. The AI summary layer is still inconsistent and still throws surprises, but it's becoming more predictable as I accumulate data on how different source inputs affect summary output.
The single clearest thing I can tell you about local SEO right now, in May 2026, is that the redesign accelerated a shift that was already underway: from a world where local rankings were mostly about what you'd set up, to a world where local rankings are mostly about what you're consistently doing. The GBP profile as a static asset you configure once and maintain lightly — that model is functionally dead. The GBP profile as an active, regularly-tended signal source that feeds a machine learning system making real-time decisions about your relevance and legitimacy — that's the current reality.
For home services clients specifically, I'm now budgeting significantly more ongoing management time than I was a year ago. The flat-fee "local SEO maintenance" packages I used to sell have been replaced with arrangements that account for the actual labor involved in monitoring Pack behavior, auditing AI summary accuracy, managing the photo cadence, and staying current on API changes. That's not a sales pitch. It's a scope shift that reflects what the work actually takes.
The weird numbers I mentioned when I started writing this — the 34% call volume drop, the 12-mile Pack radius expansion, the 17% duplicate reactivation rate — those aren't universal. They're from my client set, my verticals, my markets. Your data will differ. But the patterns are real. And if you've been staring at Pack volatility since February wondering what's happening, I hope this gives you a clearer diagnostic lens than the general-purpose advice floating around the community right now.
There's more work ahead. Google hasn't finished redesigning GBP — the hospitality and healthcare interface changes are still partially deployed as of today, and the API changelog for v4.9 has items marked "coming Q3 2026" that suggest another round of attribute restructuring. I'll be writing about that when it lands. In the meantime, the local SEO resources section on this site has the tools and frameworks I reference most often, updated through May 2026.
And if your Pack visibility has been erratic since February and you're not sure where to start: start with duplicates. Run the NAP audit. Fix Legitimacy before you touch Signals. That order matters more than it used to.
Frequently Asked Questions
- Did the 2026 GBP redesign affect all business categories equally?
- No. Home services, legal, and healthcare saw the most significant changes, particularly around the removal of the Services tab and Products carousel. Hospitality and retail kept modified versions of some features. Restaurant categories saw changes to the menu display but maintained more structural continuity than other verticals.
- How long does Pack recovery typically take after the February 2026 redesign changes?
- Based on my client work, businesses without duplicate listing issues typically see measurable Pack recovery within 4-8 weeks of implementing systematic profile improvements. Cases involving duplicate suppression add 2-4 weeks to the timeline depending on how quickly Google processes the suppression request.
- Is the AI-generated business summary replacing the business description I wrote?
- In the Pack card, yes — the AI-generated summary has taken prominence over the manually written business description in most verticals. Your written description still exists on the full profile page and still feeds into the AI summary as one of its inputs. You can't directly edit the AI summary, but you can influence it by improving the source data it pulls from: your description, your attributes, your Q&A, and your website content.
- Do citation directories still matter for local SEO in 2026?
- They matter less as ranking signals than they did before the redesign, but they still serve legitimacy and consistency functions. NAP consistency across authoritative directories remains a trust signal, even if citation volume no longer functions as a meaningful ranking lever. Focus on accuracy over volume.
- Should I update my LocalBusiness schema to reflect the new GBP structure?
- Yes. Specifically, using the
hasOfferCatalogproperty to document services is now the best on-site substitute for the removed Services tab data. Google's cross-validation between on-site schema and GBP profile data appears to have increased in sensitivity since the redesign. - What's the most common reason for Pack exclusion since the February 2026 redesign?
- From my recovery caseload, duplicate listing reactivation is the most common single cause of sudden Pack exclusion. Profile completeness issues related to the attribute restructuring are the second most common. Proximity signal changes affecting border-case businesses are third.
