LocalBusiness schema for service companies: a deep dive

When you're building SEO for a service-based business—especially one like a chauffeur or delivery company—generic markup won't cut it. LocalBusiness schema for service companies gives search engines the precise details they need to understand what you do, where you operate, and when you're available. I'll walk you through exactly what I implemented on a chauffeur service website and why each piece matters.

Pick the specific type — Use the most specific type available rather than generic LocalBusiness

The first decision I made was abandoning the generic LocalBusiness type entirely. While it's tempting to just use that catch-all, search engines reward specificity. For the chauffeur service, I went straight to RideShareService nested under LocalBusiness—or in some cases, I used TaxiService depending on the exact business model.

Here's why this matters: Google's structured data validator and the search engine crawlers themselves can categorize your business more accurately when you use the right subtype. A plumber should use Plumber, a locksmith should use LocksmithService, and a moving company should use MovingCompany. This precision helps with local pack visibility, knowledge panels, and relevance signals.

For the chauffeur service, I checked the schema.org hierarchy and found that RideShareService inherits from LocalBusiness and includes properties like areaServed, contactPoint, and openingHoursSpecification—exactly what we needed.

{
  "@context": "https://schema.org",
  "@type": "RideShareService",
  "name": "Elite Chauffeur Services",
  "url": "https://elitechauffeur.com",
  "logo": "https://elitechauffeur.com/logo.png",
  "description": "Premium chauffeur and transportation services across the tri-city area",
  "sameAs": [
    "https://www.facebook.com/elitechauffeur",
    "https://www.instagram.com/elitechauffeur"
  ]
}

Start by identifying the most specific schema type that matches your business. If you can't find an exact match, fall back to LocalBusiness, but always check schema.org first. The more specific you are, the better the ranking signals.

NAP data — Name, address and phone exactly as shown on the site and business profile

NAP—Name, Address, Phone—consistency is foundational for local SEO. But when you're adding it to your schema, it's not just about having the information; it's about having it exactly match across your website, Google Business Profile, and all business directories.

For the chauffeur service, I discovered they had inconsistencies: their website said "Elite Chauffeur Services" but their Google Business Profile said "Elite Chauffeurs Inc." The phone number on one page had parentheses, on another it didn't. These small mismatches confuse search engines and dilute your authority signals.

I standardized everything first, then added it to the schema:

{
  "@context": "https://schema.org",
  "@type": "RideShareService",
  "name": "Elite Chauffeur Services",
  "telephone": "+1-555-0147",
  "email": "bookings@elitechauffeur.com",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "742 Maple Street",
    "addressLocality": "Springfield",
    "addressRegion": "IL",
    "postalCode": "62701",
    "addressCountry": "US"
  },
  "contactPoint": {
    "@type": "ContactPoint",
    "telephone": "+1-555-0147",
    "contactType": "Customer Service",
    "availableLanguage": ["en"]
  }
}

The key is consistency. Before adding NAP to your schema, audit your entire web presence: website footer, Google Business Profile, Yelp, Apple Maps, industry directories, and any citation sites. Make them all match exactly—same capitalization, same phone format, same address abbreviations.

When there's a mismatch, search engines treat each variant as a separate business, fragmenting your local authority. I've seen this single issue tank local rankings for otherwise well-optimized sites.

Service areas — areaServed lists the cities and regions you operate in

Unlike a retail store with a physical location customers visit, a chauffeur service operates across multiple cities. That's where areaServed comes in. This property tells Google exactly where you provide service, which is critical for local search rankings.

I added areaServed as an array of cities and regions. For the chauffeur service operating in three states, I included major cities and broader region descriptions:

{
  "@context": "https://schema.org",
  "@type": "RideShareService",
  "name": "Elite Chauffeur Services",
  "areaServed": [
    {
      "@type": "City",
      "name": "Springfield"
    },
    {
      "@type": "City",
      "name": "Chicago"
    },
    {
      "@type": "City",
      "name": "Naperville"
    },
    {
      "@type": "State",
      "name": "Illinois"
    },
    {
      "@type": "AdministrativeArea",
      "name": "Chicagoland"
    }
  ]
}

Alternatively, you can use GeoShape for a more precise geographic boundary:

{
  "areaServed": {
    "@type": "GeoShape",
    "box": "40.0 -87.5 42.0 -88.5"
  }
}

The latitude-longitude box format (minimum latitude, minimum longitude, maximum latitude, maximum longitude) lets you define service boundaries programmatically. This is especially useful if your service area is a radius around a central location.

Why does this matter? When someone searches "chauffeur service near me" or "luxury car service Chicago," Google uses areaServed to determine if your business is relevant for that query. Without it, you're relying entirely on your address location, which limits your visibility for searches outside your immediate area—even if you serve those areas.

Opening hours — openingHoursSpecification — including 24/7 if true

Service companies often have non-standard hours. The chauffeur service I worked with operates 24/7 for certain services but has limited availability on specific days. Communicating this clearly through schema is crucial for user experience and conversion rates.

openingHoursSpecification lets you define hours by day of the week. For a 24/7 operation, you set all days with the same open and close time at midnight:

{
  "@context": "https://schema.org",
  "@type": "RideShareService",
  "name": "Elite Chauffeur Services",
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "06:00",
      "closes": "23:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Saturday"],
      "opens": "07:00",
      "closes": "01:00"
    },
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Sunday"],
      "opens": "07:00",
      "closes": "23:00"
    }
  ]
}

For true 24/7 operations:

{
  "@type": "OpeningHoursSpecification",
  "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday"],
  "opens": "00:00",
  "closes": "23:59"
}

You can also specify holidays when the business is closed using validFrom and validThrough. This prevents users from seeing your business as open during periods when you're actually closed.

Google displays this information prominently in the knowledge panel and local pack, so accuracy here directly impacts click-through rates. I've seen users abandon service requests when the hours shown are incorrect, even if they could have booked after checking the website properly.

Common mistakes

• Mixing up schema types: Don't use LocalBusiness if a more specific type exists. It's like telling a search engine you sell "products" instead of "plumbing supplies." Less information is typically worse than more specific information.
• NAP inconsistency: The number-one mistake I see is different phone number formats or address abbreviations across the site and Google Business Profile. Audit and standardize before adding to schema. This takes 30 minutes and saves months of potential ranking issues.
• Incomplete or inaccurate service areas: Some developers list only their primary city, forgetting secondary markets they actually serve. This leaves ranking potential on the table. Check your booking system to see where customers actually request service, then list all those areas.
• 24/7 marked incorrectly: I've seen sites list "24/7" in the description but then add specific hours in openingHoursSpecification. Structured data takes priority, so Google will use the hours and ignore your text claim. Make them match.
• No contactPoint specified: While address and phone go in the root object, contactPoint should also be included for better mobile and knowledge panel appearance. Don't skip this.

Key takeaways

• Always use the most specific schema type available (e.g., RideShareService instead of LocalBusiness) to maximize search engine understanding of your business model.
• Ensure NAP data matches exactly across your website, Google Business Profile, and all directories—inconsistencies fragment your authority and confuse search algorithms.
• Use areaServed to define where you operate; for multi-city services, list both individual cities and broader regions so you rank for relevant local searches everywhere you serve.
• Define openingHoursSpecification for every day of the week, including holidays and special hours; users and search engines rely on this data for availability and contact decisions.
• Include contactPoint in addition to phone and address to improve mobile visibility and knowledge panel display.
• Validate your schema with Google's Rich Results Test before publishing to catch errors early.