Welcome to the Q&A Forum

Hi Kurt, Thanks for writing us and I hope this message finds you well! This question can get a bit tricky because there can often be a few facbook or google places pages with information very close to the desired listing can often create some confusion. I would select the facebook and google places partner is the listings that have been verified to see what we are pulling. Here is a screen capture for reference: http://screencast.com/t/m4t4yt7bti5 Also, this help hub article does a pretty good job of breaking down this process here: https://moz.com/help/guides/local/listing If you can verify the pages that we are pulling from are not the ones associated with your clients business I would be happy to create a ticket with our engineering staff on your behalf. Let me know what you find and I would be happy to help you with the rest of the process. Thanks again for being awesome and I look forward to speaking with you soon!

I hope we might actually have that 11/17 index out a little bit early. We've made a lot of fixes and optimizations, and, fingers crossed, it looks (so far) like it's making a difference in terms of speed to index processing completion.

Hey Brian Thanks for reaching out. To provide more clarity. Facebook and Google URLs cannot be submitted to Moz Local to verify against. Our verification is a query of the business name and zip code directly to those services and they decide which ones to return as the closest match. If you have duplicate Google and Facebook pages, it is best to make sure those are removed prior to publishing a listing through Moz to avoid being validating against the wrong page. It's much easier when there is only one of each available for Google or Facebook to return. Then you only need to update these pages for any changes or updates to the NAP. If you can send us details of the listing you are referring to, we can take a look at help@moz.com If you need the listing to verify against a different Facebook or Google URL, please also include those links in the message as well. Hope this helps!

You can test this in keyword planner by simply searching for "Nike Shoes" and "Shoes by Nike". In this case, the first is searched 368,000 times monthly, the latter is searched 40.

Google considers this to be spam. Sometimes pages get away with doing this, but generally you're going to eventually get a manual action reported in Search Console.

Hi David, I was wondering if you can help me with a similar dilemma. I am technically a service area business, but we do have a location in each city/area that we service (to house the equipment and vehicles). I would like to use Moz Local and do the right thing on Google, do I list myself as a SAB or a chain? I would rather be listed as a chain since it seems easier on many accounts but I don't want to "game" the system in anyway.

Hi Lingke! Good feedback from everyone here. I just wanted to be sure to throw into the mix that fact that John Mueller specifically stated last December that Google does not want markup on on-site testimonials: https://productforums.google.com/forum/#!topic/webmasters/wY1vF2RRos4/discussion More on this here: http://www.localsearchforum.com/google-local/26385-say-what-google-says-dont-add-review-markup-your-customer-reviews.html

Thanks, I wont be giving up my subscription just yet as I think the work Moz does in terms of whiteboard fridays and everything else is worth it. I have spoken to your live help and reached a more than satisfiable outcome. Just a fruit for thought, the crawlers should be running 24/7 365 days and doing less work over a longer period, my job is a big data Analytics engineer / DevOps and this helped us solve a ton of issues at the petabyte scale.

Cheers all for the responses, this was pretty much what I was hoping to hear.... Thanks Tim

Hi Karen, The main concern you have is ensuring that your blog follows best practices from a technical perspective when it comes to sitemapping. You are on the right track with www.yourdomain.com/blog instead of creating a subdomain to host your blog. This will allow for optimal link juice flow. In terms of naming conventions - you are getting into UX and as Russ has pointed out, that has to be properly applied to your audience. If you are primarily sharing news about your industry on your site, a /news/ title may be best. It may also suggest a higher degree of professionalism with regard to your audience, depending on the demographic. If you follow these steps, you will be in great shape. As with anything, the name has to coincide with the target audience. Best of luck moving forward! Rob

The answer given by Dirk is correct. In the hreflang annotations you can indicate whatever URL, no matter it is on a subdomain or different domain name.

Hey There VERBInteractive! Just wanted to add a little proviso here to the advice you've been so nice to share with Peter. Adding a suite number should only be considered if a business legitimately has a suite number in the real business world, at which they receive postal mail. I believe this is what you meant, but in the past, Local SEOs have experimented with adding fictitious suite numbers in cases like Peter's. These days, no one I know is recommending this practice anymore. If the suite is real, do use it, but if fictitious, don't. Just wanted to clarify

The Moz crawl report will also show 404s.  I sometimes find that different spiders may find different things.  Between the Search Console report, Screaming Frog (great investment) and Moz, you should have a nice collection of things to fix.

Thanks Nitin and Moosa! I appreciate your replies.

The concept that Google is trying to setup here is that your CSS and JS contain elements that are critical for the page to render.  The problem is that as the browser downloads them, they can block other resources from being downloaded.  This is because the browser wants to read these files to see everything they need to download to render the page. Part of fixing render blocking is to reduce the number of files that a browser has to download, especially those in the critical path (html, CSS, JS) that can block the downloading of other files (images, etc) Google is getting even more specific in your case.   They are looking at the "above the fold" parts of your page.  What Google wants you to do is take any CSS or JS that you use to render what is "above the fold" on that page and inline that code into your HTML file.   That way when the browser downloads the HTML file it has all it needs to render the visible / "above the fold" part of the page vs having to wait for the CSS and/or JS files to download. The problem is that defining "above the fold" is relative due to the multiple browser size and OS and devices that your web server sees on a regular basis. If you have a really good front end developer, they can take the time to figure out what viewport size is the most common and then take all the CSS and JS and inline that (and note this may be different depending on the page) into your HTML (and this assumes that your CSS and JS do not bloat your HTML file size too much).  One approach is to take your most common large viewport size and then inline all those items into your HTML that are above the fold so you have everything covered as the viewport gets smaller.  The issue there (and this is also with most responsive sites) is that you have a lot of code bloat for your phone browsers.  You can also use a sniffer to determine what the size of the viewport is and then having the appropriate amount of CS and JS inlined on the fly.  I have also seen people suggesting that we should design websites for the phone first and then expand out from there. This is the best website I have seen that talks about how all these files interact and what Google is really getting at https://varvy.com/pagespeed/critical-render-path.html Here is what I would do. Have a single CSS file for your site and host it on your server, not an external domain.  This is best practice.  Take the time to strip out all of the stuff you do not use out of the CSS to get the file size down.  Minify and compress it, reference your CSS in your header.  This may help with the render blocking as you are reducing the number of files requested to just 1, but it may not help with the above the fold render blocking. If you want to move forward with with "fixing" the above the fold render blocking.  Extract the CSS that is critical to render above the fold items on your site (noting the caveats above) and place it inline within your HTML file and then put the rest in your single CSS file. https://varvy.com/pagespeed/optimize-css-delivery.html Have a single JS file and host it on your server.  If there is any external JS try and see if you can host it within your single JS file.  Strip out all the JS you do not use to get the file size down.  Minify and compress it. If you want to get past the render blocking above the fold item above, figure out what JS is needed to render the page above the fold.  Inline that JS within your HTML and then setup a single file for all the other JS and then defer loading of that file using this technique: https://varvy.com/pagespeed/defer-loading-javascript.html I noticed your external JS file to Googleadservices.  You may not be able to put that JS into your main JS file and have to keep the external JS reference.  I would then try and defer the loading of that using the technique above.  You need to do some testing to make sure that doing this does not throw off how your ads are displayed or tracked.  I would also make sure your GA or other web tracking JS code is inlined as well, otherwise you risk throwing off your web stats. This is what makes all of this tricky.   The Google page speed tool is just looking at a list of best practices and seeing if they are present or not.  They are not looking to see if your page is actually getting faster or not, or if you change any of these things if they throw off the function of your site. https://developers.google.com/speed/pagespeed/insights/ PageSpeed Insights analyzes the content of a web page, then generates suggestions to make that page faster This is why with all of this you need to use a tool that shows actual page speed and will show a waterfall chart with timings to see how everything interacts.  webpagetest.org is a common one. It gets really complicated, really fast, and this is where a a really good front end guy or gal is worth it to look at these things. I would start with my initial simple suggestions above and not sweat the above the fold stuff.  Test your site with actual speed and see how it does.  You can also setup GA to give you page speed data.  You can then decide if you need to take it to the next level. Another thing you can try (I have not been able to get this to work for me) is that Google has a tool that can do all the "above the fold" inlining and other speed tricks for you https://developers.google.com/speed/pagespeed/module/ Just like above, I would benchmark your performance and then see if this makes a difference on your site. Good luck!

I would also check Search Console to see if Google is reporting a lot of 404s. Maybe your site has been down some.  Also check your robots.txt and also your site for any noindex or rouge canonical links. The basic approach here is to look first at any technical items.  Is your web server or code is acting in such a way that Google cannot crawl your site or giving a signal that your pages are faulty or giving a directive to deindex them.  You do this as it is the simplest thing to check and the easiest thing to fix.  Did you have a major site change, etc. After that, you check your rankings data and your organic traffic data to look for any patterns.  Is this to the whole site, is it to specific pages.  This may give clues of what is going on.  Did it only change from Google and not from another source. You then look at external factors.  Did you lose good links?  Did you gain bad links?  Did a competitor or two come in and outrank you?  Do these traffic changes correspond with a known Google update? Good luck!

HI! As the previous answer says, you must always present all the countries and languages (or just languages) related hreflang annotations as many are the multicountry/multilingual version of your site. So your own first question (My question is, do both of these tags need to be on both the Spanish and English version of the page?) is the correct answer.

My indexation number went back to normal for 2/3 sites. But for one of my sites, the number still hasn't returned to normal. Do you have any idea as to why this might be? Do you think it's a bug with Google?