Brewit SEO Teardown: 65 Pages, Zero Schema, and a Title Tag Shared by Eight

Crawl data as of February 23, 2026. Analysis powered by redCacti.

Brewit is an AI-powered data analytics platform that lets businesses ask questions about their data in plain language and get instant answers. No SQL required, no analyst bottleneck, just a conversational interface sitting on top of your database.

The product is clearly built. The web presence is a different story. A crawl of brewit.ai turns up a marketing site where every page shares the same title tag, 264 images with zero alt text, an application subdomain that Google can freely crawl, five broken documentation pages with incoming links, and no schema markup anywhere across 65 URLs.

There are quick wins here. There are also some issues that require more than a one-line fix.

What We Crawled

Brewit operates across three distinct domains:

Crawl summary:

• brewit.ai - 9 pages (homepage, about, changelog, contact, integrations, pricing, privacy, terms, 404)
• docs.brewit.ai - 37 pages (product documentation, integration guides, API reference)
• app.brewit.ai - 19 pages (live application, sign-in, sign-up, settings, dashboards)
• Total: 65 pages crawled

The marketing site is lean. The docs are reasonably structured. The app subdomain is where the crawl surfaces a problem that isn’t obvious from the outside.

Section 1: Every Marketing Page Shares the Same Title

Eight pages. One title.

Every single page on brewit.ai - homepage, about, changelog, contact, integrations, pricing, privacy policy, and terms of service - returns the same title tag:

“Brewit - AI-Powered Analytics”

From Google’s perspective, this is eight pages all claiming to be about the same thing. The pricing page isn’t differentiated from the homepage. The integrations page doesn’t signal what integrations exist. The about page looks identical to the terms of service in search results. None of them have a unique identity in the SERP.

This is almost certainly a global title template applied at the CMS or framework level without page-level overrides - a common pattern on Framer-built sites.

What this costs: Title tags are one of the most direct signals Google uses to understand what a page is about. A pricing page titled “Brewit - AI-Powered Analytics” instead of something like “Brewit Pricing - Plans for AI Data Analytics” misses both the relevance signal and the click-through opportunity.

Meta descriptions are similarly flat. All eight marketing pages share the same description:

“The AI-powered data analyst can learn the performance of your business and provide you with instant answers and insights based on your business’s data.”

Again, applied globally with no page-level variation. The changelog page, the contact page, and the homepage are indistinguishable in search previews.

Takeaway: Every marketing page needs a title and description that reflects its actual content. For a product competing on queries like “AI data analyst,” “natural language BI,” “chat with your database,” and “AI analytics for SaaS” - the title tag is the first and most important place to communicate that. Right now it’s a placeholder doing the minimum.

Section 2: 264 Marketing Site Images, Zero Alt Text

The marketing site has 264 images across eight pages. Every single one is missing alt text.

This isn’t an isolated oversight on one page - it’s a systemic gap across the entire marketing site.

The docs site handles this correctly. docs.brewit.ai has near-complete alt text coverage across most pages, with only a handful of misses on specific pages like the CSV integration guide (50% coverage) and invite team members (40%).

The pattern suggests the docs platform sets alt text properly by default, while the marketing site - likely built on a visual page builder - treats images as decorative elements without requiring or prompting for descriptive text.

What this costs: Alt text matters on two fronts. For accessibility, it’s the description screen readers use to convey visual content to blind and low-vision users. For SEO, it’s a signal Google uses to understand image content and can contribute to image search visibility. On a pricing page with 60 images of product screenshots and feature illustrations, zero alt text means Google is inferring all of that content from surrounding text alone.

Benchmark context: A 0% alt coverage rate across an entire marketing site is unusual. Even sites with partial alt text coverage are more common than sites with none at all.

Takeaway: This is a bulk remediation task, not a one-by-one fix. On Framer or similar builders, alt text is typically added per image in the editor. A systematic pass through all eight pages to add descriptive alt text to product screenshots, UI illustrations, and team photos would close a real accessibility and SEO gap in a single session.

Section 3: The App Subdomain - 19 Pages Without Noindex

The crawl reached 19 pages on app.brewit.ai. None of them have a noindex meta robots tag.

These aren’t marketing pages. They’re live application screens:

• app.brewit.ai/ - the authenticated dashboard
• app.brewit.ai/dashboards - user dashboards
• app.brewit.ai/resources and app.brewit.ai/resources/new/[connector] - database connection setup flows for BigQuery, Databricks, MySQL, PostgreSQL, Snowflake, and Microsoft SQL Server
• app.brewit.ai/settings and nested settings pages - billing, members, analytics, developers, SSH tunnels
• app.brewit.ai/signin and app.brewit.ai/signup

Most of these pages return 200 OK with no robots instructions at all. Google can crawl them, index them, and serve them in search results.

In practice, these pages are likely behind authentication - a logged-out user hitting /dashboards probably lands on a login redirect, not actual data. But that behavior isn’t guaranteed, and it’s not communicated to Google via robots or noindex directives.

The structural risk: Internal application URLs appearing in Google’s index creates a confusing user experience if those URLs ever surface in search results. More importantly, crawl budget spent on authenticated application pages is crawl budget not spent on indexable marketing and docs content. For a smaller site, this isn’t catastrophic - but it’s noise that serves no purpose.

How to fix it: Add a noindex, nofollow meta robots tag to all app.brewit.ai pages, or configure a robots.txt on the app subdomain to disallow crawling. Either approach keeps application internals out of Google’s index without affecting the marketing or docs sites.

Takeaway: The app subdomain should be explicitly excluded from indexing. This is a configuration change, not a content change - it can be applied once at the robots.txt or framework level and affects all 19 pages simultaneously.

Section 4: Five Broken Docs Pages with Incoming Links

The docs site has five pages returning 404 or “Page Not Found” responses. Four of them have incoming internal links pointing at them - which means the crawl found broken paths that other pages on the docs site are actively linking to.

Two of these are particularly revealing. The .mdx extensions on the MySQL and Postgres pages suggest that somewhere in the docs, there are links pointing to the raw source file paths rather than the compiled output URLs. That’s a configuration issue - links to mysql.mdx instead of mysql - that’s easy to fix but suggests an automated link generation process that isn’t filtering file extensions.

The other three look like legacy URL structures that didn’t get redirects when the docs were reorganized. docs.brewit.ai/integrations/databases/bigquery and /snowflake follow an older path pattern (without the docs/ prefix) that four pages each are still linking to. The docs/learn/notebook path has four internal links pointing to a page that no longer exists.

What this costs: Each broken internal link is a dead end for both users and search crawlers. The four incoming links to /docs/learn/notebook mean that four docs pages are guiding users - and Google’s crawler - to a page that no longer exists. That’s link equity evaporating into 404 responses.

Takeaway: All five should be fixed with 301 redirects pointing to the correct current URLs. For the .mdx pages, fix the link generation to strip the extension. For the legacy paths, redirect to the new equivalents under docs.brewit.ai/docs/integrations/databases/bigquery and docs.brewit.ai/docs/learn/notebook - or to the docs homepage if those pages have been permanently removed.

Section 5: Schema Markup - Zero Across 65 Pages

The crawl found no schema markup on any page across all 65 URLs.

Not on the homepage. Not on the pricing page. Not on the docs site. Not anywhere.

For an AI analytics product, schema is an underutilized signal with some directly applicable types:

• Organization schema on the homepage establishes the company’s name, URL, logo, and social profiles as structured facts for Google - a 15-minute implementation.
• SoftwareApplication schema on the homepage communicates that this is a software product, enabling app-specific SERP features and signals.
• FAQPage schema on the docs FAQ page (docs.brewit.ai/docs/others/faqs) would make it eligible for FAQ accordion rich results in search - a direct visibility boost for the exact page designed to answer questions.
• TechArticle schema on docs pages signals to Google that these are technical reference documents - useful for documentation queries.

Benchmark context: Among SaaS companies at this stage, Organization and SoftwareApplication schema on the homepage are effectively baseline expectations. The absence of any structured data across 65 pages represents a gap relative to competitors who have implemented even the basics.

Takeaway: Organization and SoftwareApplication schema on the homepage are the fastest-impact additions. The FAQPage schema on the docs FAQ is the most targeted quick win - it targets a page that already exists and has good incoming link counts (37 internal links pointing to it).

Section 6: Thin Content and the Orphaned About Page

Four of the eight marketing pages have word counts that would struggle to signal depth to Google:

The homepage at 218 words is thin for a page that needs to rank for competitive head terms in the AI analytics and business intelligence space. The about, contact, and pricing pages are at or near the floor for content depth.

The changelog is an outlier at 6,141 words - it accumulates every release entry over time and is likely not optimized or structured for search. It has 48 incoming internal links, making it one of the most-linked pages on the site, but the word count is a product of logging releases, not deliberate content strategy.

The orphaned about page is a separate issue. brewit.ai/about has zero incoming internal links from anywhere on the site. It exists, it’s accessible, but the crawl couldn’t reach it via any internal link - it was discovered through another method (possibly a sitemap). No page on brewit.ai links to the about page.

That’s an unusual structural choice. About pages typically appear in navigation or footers and pick up internal links organically. A page with 76 words and no incoming links from the site’s own pages is effectively invisible to users navigating the site and carries no internal link equity.

Takeaway: For the about page, the immediate fix is adding a navigation or footer link so it’s reachable. For the thin content on the homepage, pricing, and integrations pages - adding 300-500 words of substantive copy about the product, how it works, and what problems it solves would both help search signals and reduce the gap between what the page claims to be and how much it communicates.

Section 7: What Brewit Gets Right

This teardown has focused on the gaps. A few things are genuinely solid:

Canonical tags on marketing pages. Every brewit.ai page with content has a self-referential canonical tag. The 404 page is the only exception, which is appropriate. No www/non-www duplication to worry about - that issue doesn’t exist here.

Docs image alt text. Unlike the marketing site, the docs site handles image alt text well across most pages. The few gaps (CSV guide, invite team member page, usage and billing page) are isolated and manageable.

Consistent docs meta descriptions. 21 of 37 docs pages have meta descriptions - a majority, and the coverage is concentrated on the core product docs rather than the integration pages. The pattern is clearly intentional.

Zero broken links on the marketing site. The marketing site itself has no broken internal or external links. The broken pages are confined to the docs subdomain.

Strong internal link equity on docs. Several docs pages have incoming link counts that reflect intentional information architecture - docs.brewit.ai/docs/introduction has 74 incoming links, the security page has 68, integrations overview has 41. The docs site has a working link structure.

How Brewit Can Think About Optimization

Quick Wins

• Add unique title tags to every marketing page - pricing, integrations, about, changelog, contact, privacy, and terms each need their own
• Write page-specific meta descriptions for all eight marketing pages
• Add noindex, nofollow to all app.brewit.ai pages via robots.txt or meta tag
• Add 301 redirects from all five broken docs URLs to their correct current paths
• Add Organization and SoftwareApplication schema to the homepage
• Fix the .mdx link generation issue in docs to strip file extensions from URLs

Next Phase

• Add descriptive alt text to all images on the marketing site (264 images across 8 pages)
• Add FAQPage schema to docs.brewit.ai/docs/others/faqs
• Add TechArticle schema to docs page templates
• Add a navigation or footer link to the about page
• Write meta descriptions for the 16 docs pages currently missing them (primarily the database integration pages)
• Expand homepage, pricing, and integrations page copy to provide more substantive content depth

Final Action Items

• Evaluate the changelog page for search value - at 6,141 words it’s the largest page on the site, but likely not optimized; consider whether it serves a marketing audience or should be restructured
• Build use case or integration-specific landing pages for the databases Brewit supports (BigQuery, Snowflake, Databricks, PostgreSQL, MySQL, SQL Server) - these exist in docs but not as marketing content
• Consider a blog or resources section for content covering the AI analytics and business intelligence queries that matter to the target audience

Key Takeaways

• 8 marketing pages share the same title and description - no page-level differentiation anywhere on brewit.ai
• 264 marketing site images have zero alt text - a systemic gap on every page, while the docs site is mostly covered
• 19 app.brewit.ai pages are crawlable without noindex - application internals visible to Google with no robots instructions
• 5 broken docs pages - including 2 exposing raw .mdx file extensions and 3 legacy URLs with combined 12 incoming links pointing to dead ends
• Zero schema across 65 pages - no Organization, SoftwareApplication, FAQ, or TechArticle markup anywhere
• About page is orphaned - 0 incoming internal links on a page with 76 words of content
• Docs site structure is solid - good link architecture, reasonable meta description coverage, strong image alt text

Brewit has a working product in a competitive and growing category. The SEO issues here aren’t catastrophic - there’s no duplicate domain problem, no crawl errors on the marketing site, and no broken links on the pages that matter most for conversion. But the title tag situation alone is significant enough to address immediately. Eight pages presenting identical identities to Google is leaving real signal value unclaimed on every one of them.

Want to run a crawl like this on your own site? Try redCacti →