The form is the only way in. It fails silently.

Across all 59 HTML pages: <header> count 0, href="tel:" count 0, mailto: count 0. /about, /contact, /legal all 404. Footer contains zero occurrences of ©, "copyright", "LLC" or "All rights". Organization.contactPoint carries no contact method at all. The only real email on the property, support@breesy-connect.com, is stranded inside ai-plugin.json. WHOIS: created 2026-04-26, registrant "Withheld for Privacy ehf".

Context that changes this finding: the absence of a phone number is a deliberate product decision. The business is built on phone-free intake, the customer submits a form and the routing is handled without a call, which is the consumer-side expression of the same thesis Breesy Voice sells to contractors. That reframes the defect but does not remove it. Nowhere does the site say this, so what is meant as a promise reads as a lead-flipping operation with nothing to reach. It also caps AI recommendation: an assistant doing due diligence finds no operator, no contact channel of any kind, and nothing to cite.

Do not add a phone number. Instead, state the promise where the phone number would have been: a header on every page with the Breesy mark left and a “Get help now” button right, plus one line saying no call is needed and what happens after submitting. Add a footer legal block naming the entity with a mailing address and a © line. Build /about and /contact, where /contact explains the phone-free model rather than apologizing for it. Populate Organization.contactPoint with a real email and hours, schema permits an email-only contact point, and having none at all is what currently reads as evasive. Surface support@breesy-connect.com as visible text. See W13 for the fallback channel this depends on.

/privacy, /terms and variants all 404. A regex for consent|privacy|terms|opt-out|TCPA|third-party returns zero matches across seven pages. Nothing sits between the last field and the submit button. callbackPhone is required. The OpenAPI schema accepts a consentToContact field that the rendered form never displays. ai-plugin.json points legal_info_url at the homepage, which contains no legal text. The parent policy at breesy.ai/privacy explicitly scopes itself to breesy.ai only and never mentions this domain.

The site collects a required callback phone and a street address from consumers in all 50 states and hands both to third-party contractors who will call, with no consent record and no notice at collection. That is offside of state privacy regimes requiring notice at collection, independent of any SEO consideration.

Route to counsel; do not self-draft. Directionally: express consent text immediately above the submit button naming who will call, linked to Privacy and Terms; store the consent artifact server-side per request (timestamp, IP, user agent, consent version); publish /privacy and /terms scoped to this domain covering data categories, disclosure to contractors, retention, and a rights request path; link both from every footer; repoint legal_info_url.

The form is a native full-page POST with no JS handler, grepping all nine JS chunks for "api/requests" returns zero files. An invalid form POST returns 303 to /request-error?code=validation_failed, whose entire message is "We need a little more information. Please review the form and try again." No field is named, no value is echoed, and "Back to Request Form" loads a blank form. Meanwhile an AI agent posting JSON gets a clean 400 with a per-field issues map naming exactly what failed. Server validation is stricter than the browser's: details requires 20 characters, serviceLocation 5, and callbackPhone rejects "ext". No aria-live, no role="alert" anywhere on the site.

A homeowner completes ten fields on a phone, taps submit, and lands somewhere that tells them nothing was accepted and nothing about why, then has to retype everything blind. The machine audience gets excellent error handling and the human audience gets a dead end. Because the product is phone-free, this form is the only door into the business, so a validation failure is not a conversion leak, it is the service failing shut on someone in an emergency with no alternative route. That makes this the single most important item on the list. With no analytics installed, nobody can see how often it happens.

Two layers. Immediately: redirect back to the form with values repopulated and the offending field flagged, or at minimum name the failing fields on the error page. Properly: add a submit handler that POSTs JSON, keeps the user on the page, and renders per-field errors from the issues object the API already returns. Drop details minimum from 20 to 5. Add an error summary in role="alert" plus aria-invalid on each bad control. Mark the six required fields visibly, nothing on screen currently distinguishes required from optional.

The site serves on www; the apex returns 307. Yet every canonical tag is non-www, all 63 sitemap entries are non-www, robots.txt declares Host: https://breesy-connect.com, and og:url, Organization.url, WebSite.url and the Link response headers are all non-www. The agent layer carries 39 non-www references across seven endpoints and zero www references. The same platform issues 308 for trailing-slash normalization, so 307 here is a configuration choice, not a limit. All 63 sitemap entries also share one hardcoded lastmod, identical to the millisecond, and four point at JSON/text files rather than pages.

Google will generally resolve to the host that returns 200, so this is loss of control and unreadable Search Console reporting rather than certain deindexing. The sharper cost is the agent layer: every client reading agent.json and posting to the apex pays an extra hop, and any client with redirect-following disabled fails outright on first run.

One pass, one deploy. Set metadataBase to the www origin in the root layout, which corrects canonical, og:url and twitter:image across all 59 pages at once. Separately update the base URL in the sitemap and robots routes, the hardcoded strings in the JSON-LD, the custom response headers, and all 39 strings across the seven agent endpoints. Change the apex redirect to 308, not 301, 308 is the only permanent status guaranteed to preserve POST method and body, which matters because agents post to it. While in the sitemap: drop the four non-HTML entries, emit real per-URL lastmod or remove it, and drop changefreq.

Every state page is 260 body words. Comparing Alabama to California, 253 of 260 tokens match, the seven differences are the state name five times and the abbreviation twice. All 1,225 state-to-state pairs fall between 95.5% and 98.3% similarity. Normalizing state names collapses all 50 pages to 147 distinct word types and 11 distinct sentences. Those 13,050 words are 80.9% of all body content on the site. Zero images, zero city names, zero state-specific hazard, licensing or permit facts, zero partner names. All 50 carry index, follow.

50 of 59 indexable URLs are near-identical templates containing nothing a searcher wants. At that concentration they define the domain's quality profile and drag on the service pages that could actually rank. This matches Google's scaled-content-abuse and doorway policies.

Do not 301 them into /locations, 50 redirects into one URL is its own signal, and the pages have a legitimate non-search job letting an agent confirm state coverage. Set index: false, follow: true on the state route and drop the 50 from the sitemap while keeping footer links live. One deploy, fully reversible. Then set a bar before any state page returns: 400+ words that exist nowhere else, plus at least three of, a named partner, that state's mold or GC licensing rule, dominant loss types with a source, real response-time data, or a real review from that state.

Grepping the delivered HTML and all nine JS chunks for gtag, GTM, Plausible, Fathom, PostHog, Hotjar, Clarity, Segment and fbq returns zero real matches. No google-site-verification meta tag. Distinct measurable funnel endpoints already exist and return 200: /thank-you, /thank-you?urgent=true, and /request-error?code=….

Nobody can answer whether these pages have ever produced a lead, which states get traffic, or how many people hit the error page. The two fixes with the largest expected lift are the ones whose effect only shows up in a before/after number.

Install Vercel Analytics and Speed Insights first, they serve from the same origin, which the existing strict CSP already permits with no header change. Define three events: form_start on first field focus, lead_submitted as a /thank-you pageview split by urgency, lead_error as a /request-error pageview carrying the code. Verify Search Console as a Domain property via DNS, not URL-prefix, so www and apex report together while W5 is in flight.

/breesyfavicon.png is 1,400,549 bytes, a 1024×1024 PNG that does not compress further. It is declared three times in every page head and reused as Organization.logo and the plugin logo_url. Measured first-load budget: favicon 1,400,549 + JS 195,371 + hero WebP 70,320 + fonts 52,396 + HTML 16,477 + CSS 5,067. The favicon alone is 80.5%; everything else totals about 340 KB. Cache headers force a revalidation round-trip on every navigation. Visually it is a plain letter B that matches neither the OG artwork nor breesy.ai.

On the degraded connectivity typical of a storm-affected area, this site's audience, 1.66 MB versus 340 KB is the difference between a page that loads and one that appears hung. Separately, the field Google reads for the brand logo points at a generic letterform while the real asset sits unused on the same server.

Ship three purpose-built assets: a 32×32 favicon.ico plus 48×48 PNG under 5 KB combined, a 180×180 apple-touch-icon under 10 KB, and a real 512×512 Breesy mark as WebP under 50 KB referenced from Organization.logo. Serve with max-age=31536000, immutable. First-load weight drops to roughly 350 KB from the image swap alone.

All ten controls compute to font-size: 14px, and the viewport meta sets no maximum-scale, so nothing suppresses iOS Safari focus zoom. Safari force-zooms any input under 16px. Across all 63 URLs: type="tel" count 0, inputmode count 0, and no user-facing field carries an autocomplete attribute. The phone field is a plain text input whose placeholder invites "+1 555 555 1234" while the server rejects anything containing "ext".

This is the most likely cause of "the mobile version doesn't work." Tapping any of ten fields lurches the page to ~150% zoom, and the visitor fights a zoomed layout for the rest of the form. The field that determines whether a lead is contactable shows a full QWERTY keyboard, which makes typing "ext 204" natural, and that submission is then rejected into the dead end in W3.

Raise every control from 14px to 16px; labels can stay 14px. Add type="tel" inputmode="tel" autocomplete="tel" to the phone field, inputmode="numeric" autocomplete="postal-code" to ZIP, and autocomplete on name, address and email. Do not fix the zoom with maximum-scale=1, that breaks pinch-zoom for low-vision users.

Hero CTA row in DOM order: View Services, AI Agent API Guide, View AI Agent JSON, Read llms.txt, View OpenAPI JSON. Measured in-browser at 375×812: document height 12,256px, form top at 1,349px, header count 0. On desktop the form sits beside the hero and is visible immediately; on mobile the columns stack, pushing it nearly two full screens down. Homepage body copy is 982 words, of which the agent block is exactly 369 (37.6%). 62 of the homepage's 71 links sit in the footer.

Someone whose house is flooding opens this on a phone and the first screen offers them a JSON file. The most commercially important page on the site gives 3.4× more words to API documentation than to the homeowner it exists to convert.

Cut the hero to two CTAs: a primary "Get help now" anchored to the form, and a secondary tel: link. Move the entire 369-word agent block to /ai-agent-api, which already exists for this purpose and is only 324 words. Delete the AI-assistant sentence from the hero and the "AI agents should submit JSON" line from the form header, leaving one quiet footer link. Agent discovery is unaffected, llms.txt, the robots directives, the Link headers and the.well-known files all remain. On mobile, collapse the 50-state footer list behind a disclosure.

The control border computes to 1.18:1 on the card fill against a 3:1 WCAG minimum, with no shadow to compensate. The focus outline computes to 1.45:1 on white. The submit button is white on the brand teal at 3.68:1 against a 4.5:1 AA minimum at 14px, and that same teal is used 26 times on the homepage as small uppercase label text at 3.52:1.

On a phone held outdoors, again, the actual use case, the ten input boxes are barely perceptible as boxes, and there is no visual feedback at any point in the form. The button and label failures are near-threshold; the border failure is a total loss of the affordance for everyone on the primary touch path.

Raise the control border to #64748b (4.76:1), already in the palette, or keep it light and double the width. Note that #94a3b8, the natural-looking choice, computes to only 2.56:1 and still fails. Set the focus ring to the existing dark hover color #0d3b4c (12:1). Darken the button fill to #0b6f8a (5.75:1) and raise it to 16px. Keep the bright teal for large display type and non-text decoration only.

The homepage and all 50 state pages emit FAQPage JSON-LD. On /locations/alabama the two questions appear in the schema and in the framework payload but zero times in rendered page text, the page contains no question marks in 411 visible words. Verified independently. The four service pages are compliant: every question is a visible heading and every answer appears verbatim in the body, so the correct component already exists.

A clean, reproducible violation of Google's requirement that marked-up content be visible to the user. Consequence is limited in practice because FAQ rich results have been restricted to a narrow set of sites since 2023, so nothing is being lost or wrongly earned, fix it because it is a stated policy violation that costs one deploy to clear.

Delete the FAQPage node from the state template and the homepage. Re-add it only where a visible accordion renders, reusing the working service-page component. Separately, add noindex, follow to /thank-you and /request-error, which currently return 200 and are indexable.

_dmarc.breesy-connect.com returns no TXT record. SPF exists but only authorises the registrar's mail-forwarding service (v=spf1 include:spf.efwd.registrar-servers.com ~all) and ends in a soft fail rather than a hard fail. MX points at registrar forwarding. The parent domain breesy.ai has no DMARC record either.

Without DMARC, mail claiming to be from this domain has no enforcement policy, so the domain can be spoofed. That matters more here than for a typical site: the brand asks disaster victims for their name, home address and phone number, and a spoofed "your restoration crew is on the way, confirm your details" email is a natural follow-on attack. It also suppresses deliverability for any real mail the business later sends.

Publish v=DMARC1; p=none; rua=mailto:<address> first to collect reports without affecting delivery, review a few weeks of aggregate data, then tighten to p=quarantine and on to p=reject. Tighten SPF from ~all to -all once every legitimate sender is enumerated, and add DKIM signing for whatever service ends up sending transactional mail. Do the same on breesy.ai.

Intake exists on exactly one route: the form on the homepage, posting to /api/requests. There is no phone (by design), no visible email, no SMS path, no chat, no status page, and no reference number returned to the user in the rendered success page. /contact returns 404. The only email address on the property is buried in ai-plugin.json. The success page does not display the request ID that the API generates and returns.

Removing the phone is a legitimate and differentiating bet, but it raises the reliability bar for everything downstream: when the single channel fails, validation error, dropped submission, mis-routed request, a partner who never calls, the customer has no way to escalate and no evidence their request exists. For a service advertising a 60-minute on-site guarantee to people in an active emergency, that is both a customer-safety issue and the most likely source of a public complaint. It is also a practical problem for privacy-rights requests, which generally require a working contact route.

Keep the no-call promise and build the safety net underneath it. Return and display a request reference number on the success page and in a confirmation email or SMS. Publish a lightweight status lookup (reference number plus phone digits) so someone can confirm their request is live. Provide one non-phone escalation channel, a monitored email or SMS shortcode, stated plainly on /contact. Define what happens if the SLA is missed and say it on the site. None of this reintroduces a call center; it is what makes the phone-free claim credible rather than risky.

The visible promise "Someone will reach out within 10 minutes" renders on all 59 pages, and the 60-minute on-site commitment appears alongside it and are repeated in llms.txt, agent-info, the OpenAPI response schema and the well-known files. Nowhere is there a qualifier: no coverage exclusions, no definition of when the clock starts, no remedy if missed, no distinction between contact and dispatch.

The word "guarantee" attached to a specific number, with no stated conditions, is the most legally exposed sentence on the site, and it is now also embedded in files AI assistants will quote verbatim to users. It is simultaneously the site's single most quotable differentiator, so the answer is to qualify it, not delete it.

Confirm with the business whether this is a contractual SLA with partners carrying a remedy, or an internal target, and what starts the clock, submission, acceptance, or dispatch. Then publish the qualified version consistently across the site and all seven machine-readable files, since inconsistent claims across those files are worse than a conservative one.

No partner is named anywhere. No certification body is named, not IICRC, not anything. No reviews, no ratings, no case studies, no license numbers, no before-and-after photography. The entire property contains one image, and it is the social share graphic.

"Highly rated" and "certified" are exactly the claims a homeowner needs substantiated before handing over a home address, and exactly the claims an AI assistant needs corroborated before recommending a service. Unsubstantiated, they read as filler in both directions.

Name the certification standard the partner network is screened against and rewrite /provider-standards around the real screen. Add real photography of real work. Add reviews with attribution. If the network cannot currently support these claims, soften the copy before building the page, that ordering matters.

Zero content on insurance claims, cost, timeline, or what to do in the first hour. The 110 FAQ questions in the schema are all about how to use the intake form, not about damage. Of the 15 highest-value homeowner questions in this vertical, is mold covered by insurance, how much does water damage restoration cost, how fast do I need to dry it, what do I do first, the site answers zero. There is no blog, no resource section, and no step-by-step guidance anywhere.

This is the entire top and middle of the funnel. It is also the whole GEO opportunity: AI assistants cite pages that answer the question being asked, and this site has nothing to cite. Insurance is the single largest homeowner anxiety in restoration and the site is silent on it.

Build useful content answering those questions, starting with insurance and first-hour guidance, marked up with HowTo and FAQPage where the content is actually visible. This is the largest single lever for both search and AI citation, and it is the slowest, which is why it sits here rather than in week one.

Only the homepage carries the form. All 50 state pages, all four service pages, and the hub pages send the visitor back to the homepage to convert.

Every page built to capture search traffic drops its visitor into a navigation step before they can act, on a site with no header to navigate with.

Put the form, or a short two-field version that hands off to it, on every service and state page. Pre-fill service type and state from the page context.

"breesy.ai" appears zero times on this site. "breesy-connect" appears zero times on breesy.ai, including in its privacy policy. No parentOrganization, no sameAs, no reciprocal link. The parent has three trade-press placements, none of which name this property. There is no BBB, Trustpilot or comparable listing for the brand, and zero outbound links exist across the nine pages checked.

The strongest trust asset available is left unused: a real company with a real product line and named restoration customers. But the bigger loss is strategic. Breesy Voice sells contractors a 100% answer rate on inbound emergency calls; Connect removes the homeowner’s call altogether. That is one coherent thesis, the phone call is where restoration leaks revenue and where customers suffer, so remove it from both ends, and neither property states it. Industry figures back the premise: more than half of restoration calls arrive after hours, strong firms answer only about 87%, and a missed call is commonly valued at $2,500–$10,000 because the caller immediately dials a competitor. Told properly, that story is the single most persuasive thing either site could say. For AI recommendation it is also decisive: an assistant cannot establish who operates this site, and no third-party source exists to corroborate it.

Add parentOrganization and sameAs to the schema, link both ways between the properties, and get this domain named in the next trade placement and the LinkedIn description. One third-party page reading "Breesy Restoration Connect, operated by Breesy" is worth more for AI citation confidence than all seven agent manifests combined. See S1 first, this assumes the unbranding is not deliberate.

Title lengths run 58 to 80 characters against a practical display limit near 60. All 50 state titles open with the same hazard list, "Water, Fire, Mold, and Storm Damage Help", so in a results page they truncate to near-identical strings differing only by state.

The differentiating word is at the front, but the shared 40-character phrase that follows means the visible portion carries little information.

Rewrite to lead with the state and the single dominant intent, dropping the brand suffix on state pages where it consumes 28 characters.

The file documents the API, endpoint, fields, SLAs, service categories, but links to none of the site's actual pages. The llms.txt convention is a curated index of content worth reading; this is API documentation wearing its filename.

A model reading it learns how to submit a form and nothing about the business, its coverage detail, or any content it might cite.

Restructure to the convention: a short description, then linked sections pointing at the service pages, provider standards, and, once M5 ships, the insurance and cost guidance, which is the content actually worth citing. Keep the API block as one section rather than the whole file.

The homepage declares EmergencyService, which describes an organization that performs emergency work. This business routes requests to companies that perform it. The node carries no telephone, no address, no opening hours, no price range and no rating, so it is ineligible for every rich result the type could target.

The site tells Google it is something it is not, using a type it cannot satisfy the requirements for.

Model it as an Organization that provides a Service, with areaServed and a properly populated ContactPoint. Reserve local-business types for the metro pages in S2, where a real servicing partner can be named.

The state enum accepts exactly 50 values. DC, Puerto Rico, the US Virgin Islands and Guam are rejected by the API and return 404 on the site, while the copy says "all 50 US states", technically accurate and practically surprising to a resident of Washington DC.

A DC homeowner in an emergency cannot submit at all, and gets no explanation.

If coverage exists, add DC and the territories to the enum, the dropdown and the location set. If it does not, say so where a visitor will see it rather than failing silently.

The service type control is a single flat select with 36 ungrouped options, from "Emergency water extraction" to "Document recovery coordination". On mobile the labels truncate in the native picker. The form asks 12 fields, six of them required.

A person standing in water is being asked to classify their own loss into a taxonomy built for dispatch software. Selecting the wrong option routes the lead to the wrong partner.

Lead with four or five large visual choices, water, fire, mold, storm, other, and derive the specific service type from that plus the free-text details, or ask it as a second step. Group the remaining options under the six category headings that already exist in the data model. Consider a two-step intake: phone and what happened first, everything else after.

No sizes attribute is set, so the responsive candidates are only 1200w and 3840w. A phone at 2× device pixel ratio downloads the 3840 variant, 70 KB as WebP, where the 640 variant would be 24 KB. The declared og:image dimensions do not match the served asset.

Modest in isolation, and far smaller than the favicon problem in W7, worth fixing in the same pass rather than on its own.

Add a correct sizes attribute so realistic candidates are generated, and correct the declared OG dimensions.

The four service pages are 226 to 257 words, and their FAQs answer intake questions rather than damage questions. Deepen them with real guidance; they are the pages best positioned to rank.

Six service categories are advertised but only four have landing pages, specialty cleanup and reconstruction have none, despite both appearing in the dropdown and the schema.

Intake is unauthenticated with no verification of the requester, which is deliberate and reasonable for agent access but leaves the endpoint open to submitted-on-behalf-of abuse. Confirm what triage or dedupe already exists server-side before adding friction.

State pages and service pages never link to each other, so the two clusters that should reinforce each other are isolated. Several link-shaped elements are plain text.

Every identity fix above assumes breesy-connect.com should openly be a Breesy property. There is a real commercial reason it might not be: Breesy sells software to restoration contractors, and those customers may object to their software vendor running a consumer front door that competes with them for the same homeowner.

If the unbranding is deliberate, W1 and M3 change shape rather than simply shipping. The site still needs a named operator, a phone number and a privacy policy to be legitimate, but the parent linkage and the reciprocal link do not ship. This is a business decision, not a dev ticket, and it should be made before the header is built.

Restoration is a same-day, drive-time purchase and the converting queries are city-grain. Today city URLs all 404, the taxonomy stops at the state, "near me" appears zero times sitewide, and no schema node carries an address or phone, so the site is structurally excluded from the local pack that owns those queries.

Do not mass-produce 300 city pages, that repeats the state-page mistake at six times the scale. Pick 15 to 25 metros where coverage is real, build one page per metro for water damage only, and require on each: the named servicing partner, their credentials, real response time for that metro, two or three real local reviews, and neighborhood names in the body. Ship five, measure at 90 days, scale only what works.

ai-plugin.json is the ChatGPT plugin format OpenAI sunset in 2024. agent.json uses a bespoke schema matching no published specification while occupying a discovery path conforming clients probe for something else. agent-card.json fails A2A validation on four required fields and points at a REST endpoint where the protocol requires JSON-RPC, so a conforming client does not skip it cleanly, it records an integration error. No MCP server exists at any of the five paths a client would check, and MCP is the one protocol assistants actually invoke today.

Ship one streamable-HTTP MCP server with three tools: check_coverage (read-only, no consent gate, the low-friction entry point), submit_restoration_request wrapping the existing POST, and get_response_commitment. The existing request schema converts almost verbatim. Then submit to the connector directories, because installation is where discovery actually happens. Delete ai-plugin.json, and either fix or delete the two A2A files, two invalid manifests are worse than none.

If the state pages ever come back from noindex, two state-varying fields would do most of the work: dominant seasonal loss profile (hurricane in Florida and Louisiana, hail in Texas and Colorado, freeze-burst in Minnesota, wildfire smoke in California) and the state's insurance claim filing deadline plus any mold-assessor licensing rule. Florida, Texas, Louisiana and New York regulate these; most states do not. Verify every regulatory claim against the current statute before publishing. A wrong legal assertion inside structured data is worse than generic text, so do not generate these with a model.

Get listed on BBB and Trustpilot so a corroborating source exists off-domain, and get the property named in the next trade placement. This is the cheapest real GEO work available and it outperforms any amount of on-site markup.