DEV Community: Sara Casciaro

Schema Markup JSON-LD for Local Businesses: A Practical Implementation Guide

Sara Casciaro — Sat, 09 May 2026 06:27:15 +0000

If you have ever wondered why some businesses show up in Google search with rich results like star ratings, address, opening hours and service area, while others appear as plain blue links, the answer is almost always structured data. Specifically, JSON-LD schema markup.

This guide walks through exactly how to implement LocalBusiness schema for small and medium-sized businesses, why it matters more than most developers think, and the common mistakes that make it useless even when it is technically present.

What JSON-LD Schema Markup Actually Does

Schema markup is a vocabulary of tags you add to your HTML that helps search engines understand your content in a structured, machine-readable way. JSON-LD (JavaScript Object Notation for Linked Data) is Google's preferred format. It sits in a script tag in your document head, completely separate from your visible HTML, which makes it easy to implement and maintain without touching your layout.

For local businesses, the LocalBusiness schema type tells Google exactly who you are, what you do, where you are, when you are open, and how to contact you. This structured signal complements your Google Business Profile and helps Google display your information accurately in search results, Maps, and increasingly in AI-generated answer summaries.

The SEO value is real. According to Google's own documentation, properly implemented structured data can enable rich results that significantly improve click-through rates compared to plain organic listings. For local businesses competing in a specific geographic area, this visibility advantage is concrete and measurable.

The Basic LocalBusiness JSON-LD Structure

Here is a clean, minimal implementation for a professional services business:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "Your Business Name",
  "description": "A clear, specific description of what your business does and who it serves.",
  "url": "https://yourdomain.com",
  "telephone": "+39000000000",
  "email": "hello@yourdomain.com",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Via Example 1",
    "addressLocality": "Your City",
    "addressRegion": "Province",
    "postalCode": "00000",
    "addressCountry": "IT"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 40.0000,
    "longitude": 18.0000
  },
  "areaServed": {
    "@type": "Country",
    "name": "Italy"
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "priceRange": "€€",
  "sameAs": [
    "https://www.facebook.com/yourbusiness",
    "https://www.linkedin.com/company/yourbusiness"
  ]
}
</script>

The @type value ProfessionalService is a subtype of LocalBusiness. Always use the most specific type that fits your client. Schema.org lists dozens of subtypes: Restaurant, MedicalBusiness, LegalService, HomeAndConstructionBusiness, and many more. The more specific your type, the better Google understands the business category.

The geo coordinates are optional but strongly recommended for local SEO. They remove any ambiguity about exact location, especially in areas where street address matching might be imprecise.

Choosing the Right @type

This is where most implementations go wrong. Using generic LocalBusiness as a type works, but you are leaving precision on the table. Google uses the specific type to determine which rich result features are applicable and how to categorize the business in local search.

Here is a quick reference for common business types:

Restaurant           → schema.org/Restaurant
Dental Clinic        → schema.org/Dentist
Law Firm             → schema.org/LegalService
Photography Studio   → schema.org/PhotographyBusiness
Web Agency           → schema.org/ProfessionalService
Hair Salon           → schema.org/HairSalon
Hotel or B&B         → schema.org/LodgingBusiness
E-commerce Store     → schema.org/Store

For service-area businesses without a physical storefront, like freelancers and remote agencies, omit the address field and use areaServed instead:

"areaServed": [
  { "@type": "City", "name": "Rome" },
  { "@type": "City", "name": "Milan" }
]

Or for country-wide service:

"areaServed": {
  "@type": "Country",
  "name": "Italy"
}

WordPress Implementation: The Right Way

Plugins like RankMath and Yoast generate schema automatically, but they do not always give you granular control and sometimes produce bloated or incorrect output.

The cleanest approach is injecting custom JSON-LD directly via functions.php, bypassing auto-generated schema entirely:

function add_local_business_schema() {
    if ( is_front_page() ) {
        $schema = [
            '@context' => 'https://schema.org',
            '@type'    => 'ProfessionalService',
            'name'     => get_bloginfo('name'),
            'url'      => home_url(),
        ];
        echo '<script type="application/ld+json">' .
             wp_json_encode($schema, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) .
             '</script>';
    }
}
add_action('wp_head', 'add_local_business_schema');

Using wp_json_encode with JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE keeps the output clean and readable.

If you are using WPCode for custom code injection, add the snippet as a PHP snippet with "Site Wide Header" placement. It works without touching theme files and survives theme updates.

The areaServed vs Address Distinction

A business can serve an entire country while being physically located in a small town. Schema handles these as two separate fields.

address tells Google where the business is physically located. It feeds into Google Maps and the local pack for geographic proximity signals.

areaServed tells Google where the business can serve clients. For a remote digital studio, this might be all of Italy even if the physical office is in a small town in Puglia.

Both should coexist when applicable:

"address": {
  "@type": "PostalAddress",
  "streetAddress": "Via Sant'Antonio 68",
  "addressLocality": "Ugento",
  "postalCode": "73059",
  "addressCountry": "IT"
},
"areaServed": {
  "@type": "Country",
  "name": "Italy"
}

Common Implementation Mistakes

Duplicate schema with conflicting data. If RankMath or Yoast is generating schema automatically and you are also adding custom JSON-LD, you end up with two conflicting schemas on the same page. Always check with Google's Rich Results Test before assuming your implementation is clean.

NAP inconsistency. Name, Address and Phone number in your schema must exactly match your Google Business Profile, your website footer, and every directory listing. Even minor variations like "Via S. Antonio" vs "Via Sant'Antonio" weaken your local SEO signals. This is one of the most common and most damaging mistakes in local SEO.

Missing @id for linked data. Adding an @id property makes your schema node referenceable across multiple pages:

"@id": "https://yourdomain.com/#organization"

This matters when you want blog posts, service pages and team pages to all reference the same organization entity.

Generic descriptions. The description field gets indexed. Write it like a focused meta description: specific, keyword-aware, under 160 characters. Be explicit about what the business does and who it serves.

Wrong opening hours format. Days of the week must be full English strings: Monday, Tuesday and so on. Not abbreviations. Violations silently break rich result eligibility without throwing visible errors.

Validating Your Implementation

Use Google's Rich Results Test to validate your JSON-LD and preview how Google reads it. Use Schema.org's validator for a more detailed structural check.

Pay attention to warnings, not just errors. A schema can be technically valid but still missing properties that unlock specific rich result types.

In Google Search Console, the Enhancements section shows detected structured data across your site after Google crawls the updated pages.

What to Expect After Implementation

Structured data does not produce overnight ranking changes. It typically takes two to four weeks for Google to recrawl affected pages and update its index.

The impact you are looking for is in rich result eligibility, knowledge panel accuracy, and local pack performance. For local businesses competing in specific geographic areas, clean schema plus an optimized Google Business Profile plus consistent NAP across directories is one of the most reliable local SEO foundations you can build.

Written by Sara Casciaro, founder of Sabriel Agency, digital studio in Ugento (LE), Italy.

WordPress vs Custom Development: A Practical Framework for Making the Right Call

Sara Casciaro — Mon, 06 Apr 2026 10:16:51 +0000

WordPress vs Custom Development: A Practical Framework for Making the Right Call

Every time a client comes to me with a new project, eventually the question comes up: "Should we use WordPress or build something custom?"

I've been asked this enough times that I've developed a fairly systematic way of thinking about it. Not a rigid rule, because the answer genuinely depends on context, but a set of criteria that helps me cut through the noise and make a decision I can defend six months into a project.

Here's how I actually think about it.

First: Reject the False Dichotomy

Before we get into the framework, I want to push back on how the question is usually framed. "WordPress vs custom" implies that WordPress isn't custom, but a well-built WordPress site with properly organized templates, custom post types, and a clean plugin stack is absolutely custom software. It just happens to run on a well-understood foundation.

The real question is: does the available WordPress ecosystem solve your specific problem well, or do you need to build something that doesn't exist yet?

With that reframing, let's look at the criteria.

Criterion 1: Who Maintains Content?

If the answer is "a non-technical person who needs to update the site themselves," WordPress wins almost every time.

The admin interface is familiar, widely documented, and forgiving. A client can add a blog post, update a service page, or swap an image without touching code. This matters more than people think. The best-built custom CMS is worthless if the client is afraid to use it.

The exception: if you're building a headless architecture where the CMS is separated from the frontend, there are purpose-built headless CMSes like Contentful, Sanity, and Strapi that offer better developer experience without sacrificing editor-friendliness.

Criterion 2: What's the Budget and Timeline?

Let's be honest about the math.

WordPress with a well-configured theme can deliver a solid 10-page business site in 3-4 weeks. A custom-built equivalent would take 2-3x longer. That time difference costs money, either yours or the client's.

For most small business sites, the performance, SEO, and flexibility differences between WordPress and custom aren't significant enough to justify doubling the budget. The marginal gain doesn't justify the cost.

Custom development makes economic sense when the project requires complex business logic that would require building custom WordPress plugins anyway, when performance requirements are extreme and the WordPress overhead is genuinely problematic, when the client has an internal dev team that will maintain and extend the codebase, or when the project scope is large enough that the upfront custom build cost amortizes over time.

Criterion 3: What Are the Performance Requirements?

WordPress gets a bad reputation for performance that's mostly deserved by bad WordPress implementations, not the platform itself.

A WordPress site with a lightweight theme like GeneratePress or Kadence, an object cache like Redis or Memcached, a page cache like LiteSpeed Cache or WP Rocket, WebP images and a CDN, and no more than 10-15 carefully selected plugins can score 95+ on Google PageSpeed Insights and pass Core Web Vitals without much difficulty.

The performance problems come from 50 plugins, heavy page builders making 80 database queries per page, unoptimized images, no caching, and shared hosting with limited resources.

That said, there are cases where WordPress genuinely can't compete. If you're building something with thousands of concurrent users, complex real-time functionality, or very specific server-side rendering requirements, a custom Node.js or PHP application, or a headless setup, is the right call.

Criterion 4: What Does the Integration Landscape Look Like?

WordPress has an enormous plugin ecosystem. Payment gateways, booking systems, LMS platforms, CRM integrations, membership systems — there's usually a plugin that covers 80% of what you need.

But "80% of what you need" isn't always enough. If the remaining 20% requires the kind of customization that means you're essentially rewriting a plugin to work differently than it was designed, you're probably better off building that component from scratch on a custom codebase.

I've spent enough hours fighting WooCommerce to make it do something it wasn't designed for that I can recognize when it's time to step back and build a proper custom solution for e-commerce edge cases.

The Middle Path: Headless WordPress

Nobody talks about this enough in the "WordPress vs custom" debate: headless WordPress is a legitimate third option that combines the best of both worlds.

WordPress as the content layer: editors use a familiar interface, content is stored in a database, the REST API or WPGraphQL exposes everything cleanly.

A modern JavaScript framework like Next.js, Nuxt, or Astro as the frontend layer: full control over rendering, excellent performance, server-side rendering or static generation as needed.

This is increasingly what I recommend for e-commerce projects or content-heavy sites where SEO performance is critical and the client team needs to manage content themselves.

The tradeoff: higher upfront development cost, more complex deployment, and a dependency between two separate applications. Not the right choice for a straightforward 10-page business site. Absolutely the right choice for a high-traffic media site or a complex e-commerce platform.

My Actual Decision Framework

Here's the simplified version.

Choose WordPress when non-technical content editors will maintain the site, when the budget is under €5,000 and timeline is under 8 weeks, when the requirements are well within what plugins and themes handle well, or when the client needs something live quickly and can expand later.

Choose custom when the project has complex business logic that doesn't fit any existing plugin architecture, when the team has developers who will maintain and extend the codebase, when performance at scale is a hard requirement, or when you need functionality that would require rebuilding a plugin from scratch anyway.

Consider headless WordPress when content editors need a familiar CMS but frontend performance is critical, when SEO requirements are serious and you need full control over rendering, or when the budget supports the added complexity.

The Most Common Mistake

The most common mistake I see isn't choosing the wrong platform. It's choosing the right platform and implementing it badly.

A custom-built site with poor database design and no caching will be slower than a well-configured WordPress site. A WordPress site with 60 plugins and no performance optimization will be a nightmare regardless of the theme.

Platform choice matters less than implementation quality. Whatever you build, build it well.

Written by Sara Casciaro, founder of Sabriel Agency, a digital studio in Ugento, Lecce, Italy, building websites, e-commerce, and digital interfaces for businesses that need things done right. sabrielagency.com

The Website That Doesn't Convert Is Worse Than Having None

Sara Casciaro — Mon, 23 Mar 2026 18:57:14 +0000

By Sara Casciaro, Founder of Sabriel Agency

There is a very common illusion among small businesses: having a website means being present online. It is an understandable belief, but a dangerous one. Because a poorly built website is not neutral. It is actively harmful. It communicates distrust, wastes budget, and convinces potential clients to choose a competitor.

I have built websites for restaurants, luxury brands, fashion e-commerce, medical practices, and AI mobile apps. In every project I learned the same thing: the problem is never the lack of a website. It is the lack of a system.

The Numbers the Industry Prefers Not to Show You

According to Google, 53% of mobile users abandon a page that takes more than 3 seconds to load. Not 10%, not 20%, 53%.
The Nielsen Norman Group documented that users read on average only 20% of the text on a web page. Writing long, dense texts without visual structure is wasted effort.
According to HubSpot, companies with an active blog generate 67% more leads than those that do not publish content. Yet most websites have no blog, or abandoned it after three articles.

These are not abstract figures. They explain why so many websites exist but do not work.

The Real Problem: Confusing Presence with Performance

When we design a website we do not start with the design. We start with a question: who is the user, what are they looking for, and what convinces them to make a request? Only after answering that question does it make sense to talk about color palettes, typography, and hero sections. Design is not decoration. It is communication. Every visual choice must serve a precise objective.

The structure determines user behavior, not the other way around.

The 4 Pillars of a Website That Delivers Results

Real Speed, Not Perceived Speed

Speed is measured by Core Web Vitals: LCP, FID, and CLS. These parameters directly influence Google ranking. A slow website does not just lose users, it loses organic visibility. The solution involves:

High performance hosting
Correctly configured cache
Images in WebP format
Lazy loading

SEO Architecture Designed From the Start

SEO is not added to an already built website like paint on a wall. It is designed into the architecture from day one:

Clean URLs
Hierarchical heading structure
Schema markup for search engines
XML sitemap
Canonical tags to avoid duplicate content

A Clear Message in the First 5 Seconds

A visitor who lands on your homepage has 5 seconds to understand three things:

Who you are
What you offer
Why they should choose you

If they have to scroll, read extensively, or search for information, they have already decided to leave. Clarity is not simplicity. It is the most advanced form of communication.

A Designed User Journey, Not an Improvised One

Every page must have a precise purpose and a clear direction:

Homepage leads to services
Services lead to contact
Contact leads to consultation

If this journey is not designed, traffic disperses without converting.

Why Most Websites Fail on All 4 Points

Not because of lack of budget. Not because of lack of goodwill. But because the market is full of quick solutions, pre-packaged templates, and agencies that measure success by the number of pages delivered, not results generated.

A website is not a finished product. It is a living system that requires analysis, continuous optimization, and constant alignment between business objectives and user behavior. Small businesses deserve digital tools that match the quality of their products and services.

Where We Are

Sabriel Agency operates from Ugento, Salento, Italy, working with businesses across the country that want a digital presence built to last and to convert.

For a free consultation:

📍 Via Sant'Antonio 68, 73059 Ugento (LE), Italy

📞 +39 344 536 0025
📧 supporto@sabrielagency.com
📧 agenziasabriel@gmail.com
🌐 https://sabrielagency.com