More threads by RFKSolutions

Joined
Jun 24, 2014
Messages
20
Reaction score
3
Hi

Looking for bit help. One of our website design clients who we are doing some local SEO on, we recently added some schema markup on his website.

Mcintyre Masonry Ltd | Stonemasons in Scotland

In the footer of all pages we have listed his address, he has 2 offices which we added in schema format. But Im not sure if this will confuse Google having both on all pages and whether I have added it right for multiple addresses?

Hoping you guys and girls can help out :)
 
Last edited by a moderator:
It could get confusing for Google, she's sensitive.

Industry best practices would be to create a page for each location, and have your schema on those. Currently on the contact us page you have both addresses with embedded maps.
 
Hi Blake

thanks for your reply, on contact page we didnt use schema markup, so you think keep contact page as it is, remove schema from the footer on all pages, and just add schema on an actual individual location page?
 
Hi and welcome to the forum. :)

Moved your post to help and support which is where posts need to go that link to and are about a specific listing.

I agree with Blake plus you'll find lots more detailed advice under this hashtag.
<a href="http://localsearchforum.catalystemarketing.com/tags/multi-location.html">#multi-location</a>

I've answered this question a lot in those threads and am really short on time so hope you don't mind me not answering again here.
 
Hi RFK. I would assume that one of those locations would be considered their "main" location, so the other location could be considered one of their branches. If that's the case, you could always use the "branchOf" property to specify the difference between the two locations.
 
Hi RFK. I would assume that one of those locations would be considered their "main" location, so the other location could be considered one of their branches. If that's the case, you could always use the "branchOf" property to specify the difference between the two locations.

Hi David

thanks for your comments, the west lothian address is their main base, main office, the edinburgh one is simply a sales office they use from time to time when needed

so are you saying, just keep it all as it is but add branchOf into the edinburgh address in the footer and that should all be good?
 
Well, I've never been a big proponent of marking up the address on every single page of a website, simply because it seems like overkill. The exception to that would be if you were marking up different pages that highlight a different product or service that the business offers. In that case, you would also want to mark up who is offering the service and where they are located. It won't hurt to have the addresses marked up in the footer, but it won't necessarily help much either.

But since that's how everything is currently formatted, you can just leave it as it is. So I would recommend that you mark up the main office location with either schema.org/Organization or schema.org/LocalBusiness and the sales office with the "branchOf" property. But because of the way that schema.org has things set up, you will have to essentially mark them up inversely, like this:

HTML:
<div itemscope itemtype="http://schema.org/LocalBusiness">

<div itemprop="branchOf" itemscope itemtype="http://schema.org/Organization">
  <span itemprop="name">Name of Main Office</span>

<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
  <address properties here...>
</div>
</div>

  <span itemprop="name">Name of Sales Office</span>
<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
  <address properties here...></div></div>

Schema also has a "hasPOS" (has points-of-sales) property, which is also an option here, but I think that the branchOf property with the LocalBusiness schema type would be more appropriate in this case.
 
Hi David

Thanks again for your reply, ive took your comments on board and updated the code, if you get chance to check it out and let me know all looks ok that would be great?

thanks
 
Looks better. But I did notice that the phone number is not nested within either location schema, so that's something important that you really should fix. And you can use the LocalBusiness schema type for both locations. You don't have to use the Organization type for one, because LocalBusiness is actually an extension of Organization.
 
Hi David,

I find myself in a bit of a quandary. I'm trying to do multiple schema but decided to use suborganization.

I run the authentication in Yandex and receive no errors. Conversely, Google's tool throws errors.

Q. What am I doing wrong?

The hangout
 
Hi Callmenicholi. Well, since you have two locations, one really should to be the parent and the other should be the subOrganization. And when you mark them up, you do need to include all of the information about both locations including the name, address, etc.

So in your case since there are only two locations, you would only need one block of markup, specifying which is the parent and then nesting the info about the subOrganization.

I hope that makes sense and helps.
 
So it sound like json would be recommended and just keep the rest txt...
 
Last edited:
Forgive me if I am a little slow on this but my question is :

what if they sell exactly the same service and just have to locations apart from each other in the same city

currently, just doing schema markup per page they are really sort of a franchise set up. different addresses and phone numbers same company name same website just structured as


Home page www.mydomain.com

www.mydomaian.com/city

service www.mydomain.com/fixthis/city

am I on the wrong track

Help could be needed

Thank you
 

Login / Register

Already a member?   LOG IN
Not a member yet?   REGISTER

Events

LocalU Webinar

Trending: Most Viewed

  Promoted Posts

New advertising option: A review of your product or service posted by a Sterling Sky employee. This will also be shared on the Sterling Sky & LSF Twitter accounts, our Facebook group, LinkedIn, and both newsletters. More...
Top Bottom