Welcome to the Q&A Forum

This clears it up I guess you could consider this a feature request too - I'd love to track more competitors on a campaign. If it came with the next account level it would influence any upgrade decisions we make, (although it's definitely not a 100% if I can track more competitors I'll upgrade). I'm going to look and see what Open Site Explorer can do for me.

Having "wicker" in the domain is only one small ranking factor of 200+. Although they used to be ranking higher, a drop in rankings could be due to a number of different factors, especially if you are talking a few years ago or more. There have been many Google updates that could have had an impact on your client's site.The first thing I would do is a competitor analysis on the top 3 ranking business that are showing up in the SERPs you want to show up in. Some of the following questions and comparisons would be a good starting point. How Many Domains Do They Have Linking To Them? What are their top 5-10 backlinks? How Much Unique Content Do They Have On The Page Ranking? Is It Well-Written & Structured with Pics and/or Video? What Is their Meta Title (What you click on in the SERP)? How Close Is the Keyword To The Beginning of Their Title? If Attempting To Rank Locally.. What is Their Moz Local %? (https://moz.com/local/search) How Fast Does Their Website Load? (I like using Pingdom and Pagespeed Insights for this) Compare those answers with what you see for your clients website and I am sure you will see some areas for improvement, but it will also give you very good goals as far as content creation, link opportunities, technical SEO edits, and more.

I'm trying to fix these 3 blocking CSS resources https://fonts.googleapis.com/css?family=Audiowide https://fonts.googleapis.com/css?family=Raleway:300,400,700 https://www.legendslimotn.com/code/css/style.css?ver=3.1 I tried this: <link rel="preload" href="path/to/mystylesheet.css" as="style" onload="this.rel='stylesheet'"> <noscript><link rel="stylesheet" href="path/to/mystylesheet.css">noscript> <script> /*! loadCSS. [c]2017 Filament Group, Inc. MIT License */ (function(){ ... }()); /*! loadCSS rel=preload polyfill. [c]2017 Filament Group, Inc. MIT License */ (function(){ ... }()); </script> Adding this to the code improved the load speed results but it caused other page problems on the browers other than the Chrome browser.

Thanks, Tawny, If you look at Duplicate titles, check the first one (https://needquest.com/place_tag/autism-spectrum-disorder/). All the URLs with a duplicate title have /page/ in them. I will suggest they move the Allow statement and see if that helps.

Thanks. Yea, I did consider those options. I assumed there was a more complicated way to do this then deleting the page and then re-creating it after. All of those make sense though. Thank you for your time. Much appreciated.

Hi Gaston, LureCreative and Nigel, your responses and suggestions are much appreciated. We will test it out and hopefully be able to update on here what's the outcome!

Hi Kenneth, I think it depends on whether you truly operate as a local business within that city location. If you intend to advertise to a specific city then the intent changes from finding you on a national level to finding you at a city specific level. If you truly operate (and you haven't said) from that city location then you could really optimise the page as city specific so would rank highly in that local area. You could make the page different from the national page by including photos of the city with appropriate Alts and a little about the city itself. You'd find it relatively easy to rank at a local level for the page. If you do not operate at City level (with a local office) and are a national company simply targeting a specific city to sell to then I would canonicalize the page back to the generic. It begs the question though why you would want a city focused page in the first place and why the national one wouldn't suffice. I hope that clears (and not muddies!) your thinking! Regards Nigel

Here's the answer I received. I have to say, I still don't get it. On the site I manage we have internal links in the body of many articles, side widgets, footer, HTML sitemap, Related Content, and so on. Yet MOZ has us -- constantly -- at 66 internal links. Here's the MOZ answer I received to my question about this: I think it may help to understand a bit more about how our index is built. Our index doesn't work like a direct crawler that you'll see with Screamingfrog, or Moz Pro Site Crawl. Direct site crawlers go right to your site and crawl from page to page using links. This would give you an accurate picture of your site at the time it's crawled. Our index is built by crawling and indexing high authority sites and pages and following links internally and externally. If we find a link to a site we may not go on to crawl and index all the other pages on that site. It's likely we won't have a complete map of all your pages and internal links. The index and Link Explorer tool are designed to help you discover prospects to build your backlink profile, rather than give you a complete picture of your internal links. The higher your pages authority to more likely they are to be crawled and indexed. You can learn more about our index here https://moz.com/help/guides/link-explorer/how-we-index

Hi There! The best practice here would be to implement those 301 redirects to prevent the possibility of duplicate content. It does not appear that any https://www. pages are in Google's index now (screenshot) but the potential is there with both http://www. and https://www. URLs being able to resolve and the fact that they both contain self-referencing canonical tags. I would recommend making the switch to https:// given Google's recent announcement regarding the 'Not Secure' warning in Chrome 62 starting October (All http:// pages with forms will be marked as 'not secure' - more on that here).  This warning will be triggered on every page due to the 'request a quote' form in the right-hand sidebar. If you are interested in looking into this further, I recommend checking out this 'Secure your site with HTTPS' Search Console Help article. Hope this helps!

The best PR strategy is to gain articles written by online publications that people read, sending both referral traffic and helping improve rankings. Press Releases can work within industry--if the brand is major and niche industry publications are going to pick it up. A recent example: StarWars.com did a press release on Colin Trevorrow leaving Episode IX. Link: http://www.starwars.com/news/a-statement-regarding-star-wars-episode-ix  This article is referenced and picked up without even having to go through a PR service because it's a major brand in the entertainment industry that's going to have a lot of coverage by movie blogs, vlogs, and so on. All the above is to say, work on creating articles that can be featured on major news services. They'll have their own take that they spin for their audience, but you'll have a lot more traction from being featured on sites that refer you interested visitors versus a press release service.

You used to be able to do this in the YouMoz section of the Moz Blog at https://moz.com/ugc. However, the last post was almost a year ago, and according to a note on https://moz.com/posts/ugc_guidelines, the submission process is closed for the time being.

superb answer! thank you!

I would also look at how you are currently managing the sitemaps between the two platforms to make sure that the new pages have not been left out of the sitemap generation.

Hi Rick, I don't know the details but you could have a collapsable section under the video. If not, then perhaps under the video you could provide a link to a new blog post and add it there. Make sure you know what keywords you target on these pages so they don't compete. Hope helps a bit. Katarina

That is a fantastic article, and good information. I appreciate the link

I suspect you didn't understood the question. MTBE was asking if schema.org structured data items must be in the language used in the subfolder. For instance, in www.domain.com/en/, will be the items written in English and in www.domain.com/es/ in Spanish? The answer is yes.