Ajouter des microdonnées Organization et LocalBusiness sur les pages clés

Un cabinet d’architectes dispose de trois agences régionales, chacune avec sa propre adresse, ses horaires et son numéro de téléphone, mais toutes rattachées à une même structure juridique et une même identité de marque. La page d’accueil du site doit représenter l’entreprise dans son ensemble, tandis que chaque page « Agence de [ville] » doit représenter une implantation physique précise, avec ses propres coordonnées. Deux besoins différents, deux types de balisage Schema.org à ne pas confondre.

Organization pour l’entité globale

Le type Organization convient à la page d’accueil ou à une page « À propos », pour décrire l’entreprise dans son ensemble sans ancrage géographique unique. Il accepte notamment la propriété sameAs, une liste d’URL vers les profils officiels de l’entreprise sur les réseaux sociaux et les annuaires professionnels, qui aide à consolider l’identité de l’entité aux yeux des moteurs de recherche :

function ma_recette_organization_jsonld() {
    if ( ! is_front_page() ) {
        return;
    }
    $data = array(
        '@context' => 'https://schema.org',
        '@type'    => 'Organization',
        'name'     => 'Cabinet Architecture Meridian',
        'url'      => home_url( '/' ),
        'logo'     => get_site_icon_url( 512 ),
        'sameAs'   => array(
            'https://www.linkedin.com/company/architecture-meridian',
            'https://www.instagram.com/architecturemeridian',
        ),
    );
    echo '<script type="application/ld+json">' . wp_json_encode( $data ) . '</script>';
}
add_action( 'wp_footer', 'ma_recette_organization_jsonld' );

LocalBusiness pour chaque implantation

Sur les pages dédiées à chaque agence, le type LocalBusiness (ou l’un de ses sous-types plus spécifiques comme ProfessionalService) décrit l’implantation physique avec son adresse structurée via PostalAddress, ses horaires d’ouverture et son numéro de téléphone local :

function ma_recette_localbusiness_jsonld() {
    if ( ! is_page_template( 'template-agence.php' ) ) {
        return;
    }
    $data = array(
        '@context'   => 'https://schema.org',
        '@type'      => 'ProfessionalService',
        'name'       => 'Cabinet Architecture Meridian — Agence de Lyon',
        'telephone'  => '+33478000000',
        'address'    => array(
            '@type'           => 'PostalAddress',
            'streetAddress'   => '12 rue des Fantasques',
            'addressLocality' => 'Lyon',
            'postalCode'      => '69001',
            'addressCountry'  => 'FR',
        ),
        'openingHoursSpecification' => array(
            array(
                '@type'     => 'OpeningHoursSpecification',
                'dayOfWeek' => array( 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday' ),
                'opens'     => '09:00',
                'closes'    => '18:00',
            ),
        ),
    );
    echo '<script type="application/ld+json">' . wp_json_encode( $data ) . '</script>';
}
add_action( 'wp_footer', 'ma_recette_localbusiness_jsonld' );

Faire cohabiter les deux sans conflit

La règle de cohabitation est simple une fois posée :

• Un seul Organization global, uniquement sur la page d’accueil ou une page « À propos ».
• Un LocalBusiness distinct par page d’agence, jamais mutualisé entre deux implantations différentes.
• Jamais les deux types sur la même page en simultané, sauf besoin réellement justifié et documenté.

Certains guides suggèrent de relier les deux via une propriété parentOrganization sur chaque LocalBusiness, une option intéressante si le cabinet souhaite renforcer explicitement le lien hiérarchique entre l’entité globale et chaque implantation.

Les données à ne jamais dupliquer entre les pages

Un piège fréquent consiste à copier le même numéro de téléphone ou la même adresse sur toutes les pages d’agence par facilité, en modifiant seulement le nom de la ville dans le libellé. Cette incohérence entre le texte affiché et les données structurées peut être détectée lors d’un contrôle manuel, et surtout nuit à la cohérence des informations locales que les moteurs cherchent justement à vérifier pour ce type d’établissement.

Vérifier avant mise en production

L’outil de test des résultats enrichis de Google permet de valider chaque type de balisage indépendamment, page par page. Sur ce projet, la vérification a permis de repérer une erreur de format sur les horaires d’une agence, un jour de la semaine mal orthographié en anglais qui invalidait silencieusement toute la propriété openingHoursSpecification sans faire échouer le reste du balisage.

Notre verdict

Distinguer clairement l’entité globale de ses implantations locales dans le balisage Schema.org évite la confusion la plus fréquente sur ce type de site multi-agence. Une fois la structure de données bien pensée en amont, générer le JSON-LD correspondant reste une opération mécanique, sans dépendance à une extension SEO complète.