With Google posts, how do you tackle this if you have multiple locations?

Adam Paddock: Yeah. So we have 15 locations, a disclaimer. So not a crazy amount, but still isn’t and so what we try to do is obviously first and foremost, to make sure that any posts that we do applies to that location because the different locations have different offerings. And we try as much as possible to segment it. So that way if we know one location has patients who are more into this certain procedure, say cosmetic, we know people in Houston are more into these types of procedures. They’ll get those types of posts. Whereas Austin people are into different sort of procedures, they’ll get those types of posts, that being said I still see value in reusing some of the same content as long as it applies to, you know, multiple different locations. So we’re not afraid of using the same posts for more than one location, but we do try to minimize that as much as possible. That’s the basic answer. Sathya Krishnamurthy: On the technical side, Google previously had restricted publishing Google posts through API. So if you are using one of the vendors for doing Google posts like Milestone, definitely the API now allows you to take a single post and publish it across multiple locations so a single content can be re-published, again, as Adam mentioned, it’s very critical to have content relevant, whenever you’re doing a post, that content that you’re publishing is relevant to that location.

And how long are Google posts visible?

Sathya Krishnamurthy: I think right now, first 15 days we are seeing about seven days. But they keep changing it. I don’t know what the current visibility is. Adam Paddock: I actually thought it was 30 days, last time I looked but I could be wrong as well. I do know the more you post, you do bury older ones. So you kind of want to keep it fresh each month and sunset out old ones. So keep that in mind. For instance, one of the six to eight that we try to do each month is always like that month specials. So we always will do that at the beginning of the month and then at the end of the month, we’ll sunset that out and put a new one for the next month. Sathya Krishnamurthy: So for other verticals, when we tried it out, at least during the crisis, we saw the lifetime increase by 15 days. But previously before the crisis, it was seven days, now it’s around 15 days and and Adam’s seeing 30 days.

Right. So how many frequently asked questions should someone develop?

Sathya Krishnamurthy: I guess as many would be the thing, but most you need to answer as many questions as possible. And more of course definitely will help you to rank for more of these questions that people are commonly asking you. And my recommendation would be as long as you can develop the content and market, build as many questions that are relevant for you and along the keywords that you want to rank for. What do you think, Adam? Adam Paddock: I’ll agree to that I will just say we try not to double dip. So we try not to have too many crazy FAQ questions that are similar or about the same topic. We try to have like really distinct segmented FAQ questions, but we usually have a one per procedure or treatment. So we have quite a bit and yeah, I’m saying the more the merrier, as long as again, you’re not continually duplicating questions and answers.

And the follow up question is, should they put frequently asked questions on pages or in a database?

Sathya Krishnamurthy: It should be out for Google to index it. I would definitely put it out on the pages and then put it out with markups so that even if website traffic is increasin and if you’re doing these best practices out in Google and you’re driving your website topics, we’ll definitely focus on putting it on the pages.

How many schema types should be on each page?

Sathya Krishnamurthy: If I have to answer that question, it will depend on the page first, but what we are seeing is somewhere not of 16 to 18 different schema at bare minimum on every single page that basically identifies your brand, identifies your corporation, your entity, and what the webpage is trying to convey. That’s the bare minimum. And then on top of it, then you look at the content and then for each and every type of content each and every type of asset that is set on the page, you just start adding more and more schema types to mark up every single thing that’s available. Adam Paddock: I’ll say I have nothing to add to that. I’m not technical at all, we were in your earlier poll, Erik. We were the groups that had schema errors, I believe, really old and air it out and I kinda knew a little bit about it. Like I knew generally what we’re trying to do with schema is trying to get Google enhance background information on existing page. And I did a little bit of reading on it, but I’m not technical at all so I turned it over to Sathya and Milestone to do everything so sounds great Sathya, I liked your answer.

I believe we have one last one on page or tag injection make a difference for results?

Sathya Krishnamurthy: Both practices are fine, on page basically putting the schema definitely will cost more as the schema develops, and if you develop more and more content on page, you need to go and keep on updating your page, you can keep schema and content separated out so you can actually load it and as Adam mentioned, if any of your schema start throwing at us because Google and schema.org they changed the requirements for particular schema type, then you can actually quickly fix it without having to spend any time on development or basically updating your page. Both methods are fine. We use both these methods and we have seen success with it.

We do have actually another question. What tools do you use to develop schema?

Sathya Krishnamurthy: So most of our tools are internal tools that we have developed. We have our own professional services team, which basically use that internal tools to audit the content on the site and build a schema for that. Some of the tools we have our visual editors, look at the page and then mark it up. And then I look at all the requirements which are pulled from schema.org. There is quite a bit of automation that is built into it as well into some of these internal tools that we use. Eventually if that is enough interest, we will definitely open it up for the for the public to consume, but all of these tools that are internal tools.

» SEO

Add to Bookmarks