Welcome to the Q&A Forum
Browse the forum for helpful insights and fresh discussions about all things SEO.
Hi Joost,
Unfortunately we don't use Wordpress in our company - I know the basics of the Yoast plugin but I am not really an expert in how to configure it. Maybe somebody else on Moz can help you on how to configure it. My guess would be to fill in the full url - you could always try & see if this works.
There are quite a lot of users on the forum who use Yoast - so I guess they should be able to help you with the configuration.
rgds,
Dirk
@nateknox & @rachel.cachel: This question is more than 1 yr old - apart from the original poster & the people who replied nobody is seeing the questions you ask. If you need help - post a new question in the Q&A
If Fetch like Google is also giving a 301 - I would mark them as solved in WMT & check if they re-appear.
If you click on the i next to the redirect message in Fetch like Google - it shows the type of redirect & the page it's redirecting to. I assume you checked that this is also a 301.
I have a similar issue on one of my sites - if a user gets to a non-existing url - the server first tries to find out if the page exists - if it doesn't it's redirected to a 404 page. Although technically it is a 301 - WMT sees them as a soft 404 as the destination page is a "Page not found" type of page (called 404.php) - which (quite ironically) renders a 200 status.
On the destination page - do you mention somewhere a message like "page not found" or is it just a plain category page?
The SEO impact is difficult to assess - Google says these pages are mainly wasting the bot's time as it's indexing pages that do no longer exist, not sure if it is also affecting rankings. As you did the crawl with Screaming Frog, I guess you are also removing all internal links to these redirected pages? If these links disappear, and as the content was thin, I suspect you don't have many external links pointing to them, so the problem should disappear after a while.
rgds,
Dirk
Hi Donna,
The general principles are also applicable for Drupal - which normally is quite flexible to fine tune in terms of SEO. It is however a bit more complex to setup & configure compared to a Wordpress site.
You should check the tools mentioned in this article https://www.acquia.com/blog/4-steps-optimize-your-drupal-site-increase-traffic (step 2 list some modules that can help - the rest will be quite obvious for you). Acquia is the company founded by the guy who started Drupal - so the modules that are suggested should be ok.
We use Drupal as well - but as it's implemented by a technical partner we just give the requirements, we don't know which modules they use to deliver what we ask.
Hope this helps
Dirk
I am a big fan of Screaming frog myself. Apart from the real basic stuff (checking H1, titles,...etc) it's also useful to check if all your pages contain your analytics tag and to check the size of the images on the site (these things Moz can't do).
It's also extremely useful when you're changing the url structure to check if all the redirects are properly implemented.
Sometimes you get loops in your site, especially if you use relative rather than absolute links on your site - Screaming Frog has an extremely helpful feature: just click on the url and select "crawl path report" - which generates an xls which shows the page where the problem originates
It's also very convenient that you can configure the spider to ignore robots.txt / nofollow / noindex when you are test a site in a pre-production environment. Idem for the possibility to use regex to filter some of the url's while crawling (especially useful for big sites if the they aren't using canonicals or noindex where they should use it)
rgds,
Dirk
Hi,
If you still find errors in WMT I would do a full site crawl with screaming frog to be sure that no errors remain.
Apart from that, I fear you will have to be patient & hope for the best. One of our sites was hacked (2times in a 3 month period) - we lost about 30% of search traffic, and it took us about 3 months to recover (we fully recovered, but we were in a pretty specific niche, with a lot of long tail searches and not that much competition)
rgds,
Dirk
Hi,
Rand did a Whiteboard Friday on this topic (http://moz.com/blog/subdomains-vs-subfolders-rel-canonical) - and also answered a question quite similar as yours (http://moz.com/community/q/moz-s-official-stance-on-subdomain-vs-subfolder-does-it-need-updating)
=> advice would be not to use subdomains but rather to use subdirectories (which corresponds with the advice Tony gave you)
rgds,
Dirk
Joost
You might want to open a new question (on how to filter) - this question is too deep down the list & marked as answered so I fear nobody is going to see your additional question.
rgds,
Dirk
Hi
If the template is marked as responsive it should pass the mobile friendly test. Main issue with these templates is that they are very often stuffed with a lot of features that you're not going to use (resulting in heavy css / js files). This could have a negative impact on the load time of your page. That said, I guess most people just buy Wordpress themes rather than develop themselves.
rgds,
Dirk
Hi,
You might want to check this article of Google on facetted navigation: http://googlewebmastercentral.blogspot.be/2014/02/faceted-navigation-best-and-5-of-worst.html
In your current set-up - Google isn't indexing pages of type https://modli.co/dresses.html?category=45&price=13%2C71&size=25 as these pages are only accessible using javascript (you can check this by crawling the site by using Screaming Frog or just using site:modli.co in Google) - so adding the rel next/previous will not change a lot for these pages.
If you want to make this pages accessible you will have to
Hope this helps,
Dirk
Hi,
This is question which is asked quite often on Moz Q&A. Pages that have a big chunk of source code in common are sometimes considered as duplicated - even if the content is quite different. Recently they did a post on the tech blog on how they identify duplicates (it's quite technical stuff - but still interesting to read - https://moz.com/devblog/near-duplicate-detection/)
If only address & image are different but description is identical - the page will probably be considered as a duplicate by the Moz bot. If it's only for 40 of 1500 listings, I wouldn't worry to much about it, especially because you are unable the content anyway.
I would be more worried if other real estate companies would use the same feed and hence provide exactly the same content on their side, not only the 40 you mention but the full listing.
rgds
Dirk
Hi,
You could put a 301 redirect of the old image folder to the new location. The easiest alternative is to keep the images in both places for a while, until Google has indexed the new location (which can take a few weeks/months). Normally, if all the internal links have been updated, there should be no links to old location, so these images will disappear from the index and replaced by the ones in the new location. Once they are indexed on their new location, you can delete them in the old location
rgds,
Dirk
Hi,
It's not always best practice to use a canonical url for paginated pages - according to Google:
"In cases of paginated content, we recommend either a rel=canonical from component pages to a single-page version of the article, or to use rel=”prev” and rel=”next” pagination markup."
Again from Google:
"When using rel=”alternate” and rel=”canonical” markup, maintain a 1-to-1 ratio between the mobile page and the corresponding desktop page. In particular, avoid annotating many desktop pages referring to a single mobile page (or vice versa)."
If you would decide to stick to the canonical for the pagination your desktop site would have a config like this:
http://www.example.com/article.htm&page=2
href="http://m.example.com/article.htm&page=2" >
On the mobile version m.example.com/article.htm&page=2 this would become:
This way you keep the 1-1 between mobile & still indicate to google that page=2 should not be indexed but rather the 1st page. It's quite possible that
could also work, but the other option seems to be more in line with the guidelines
Hope this helps;
Dirk
As far as I know if your pages pass the "mobile friendly test" - they get the label "mobile friendly". If you check
=> it's considered mobile friendly so it is ok for the mobile update
If you change your user agent to mobile and do a site:billboard.com you can quite easily identify the pages that are not considered mobile friendly (you should see them in WMT as well). If these pages are important in terms of search traffic, you might consider to create a mobile version of these pages as well.
Don't really understand the point of the redirection for the Google bots - your system should normally send all mobile devices to the mobile version. Googlebot will identify itself as mobile device so should be redirected. There is no need to make specific redirects for the bots.
I would try to focus on the performance on your pages - the score from PageSpeed insights is not great (for mobile/desktop) - https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwww.billboard.com%2F&tab=mobile
Desktop version is loaded in 8sec (http://www.webpagetest.org/result/150429_4Q_15JQ/) - mobile fully loaded in 20sec (http://www.webpagetest.org/result/150429_S8_15QW/) - so there is probably some room for improvement.
Having the mobile friendly label is the first thing, but if your site is slow to load the user experience will not be great and this can impact your rankings for mobile (regardless of the label).
Hope this helps,
Dirk
@Stramark - for me putting a follow link to the customer(s) depends on the context of the site. As I don't know this particular site I just mentioned to be careful. It's up to the OP to decide if these links should be follow or no follow. If these links look natural (see https://moz.com/ugc/what-is-an-unnatural-link-an-in-depth-look-at-the-google-quality-guidelines) they are probably ok - if they are "too" optimised for certain keywords - they are not.
Hi,
Do you get a lot of traffic coming through image search? Most of the images you use on the site seem to be stock images, so normally the % of image search traffic shouldn't be that big.
If you receive limited or no search traffic from image search, you don't really have to do anything special. There 404 errors in WMT will disappear after a while & the new images will get indexed. Normally the 404's will have no impact on search traffic.
If all CDN's contain all the images, you could always redirect the original image folder to one of the cdn's - but it not strictly necessary.
rgds
Dirk
Hi,
It's quite possible that it's just a matter of time before the label shows like Patricks mentions. However, if you check your site with PageSpeed Insights there seems to be something strange with the way you implement the redirect: https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwww.pssl.com which could be the reason why the label does not appear:
Your page has 2 redirects. Redirects introduce additional delays before the page can be loaded.Avoid landing page redirects for the following chain of redirected URLs.
If you want to check this "manually" you can check the headers yourself using web-sniffer.net with a mobile user agent. I would check with your technical team how to avoid this redirect chain.Apart from that, if you check the insights for speed, your scores for both mobile & desktop are not really great. Testing on webpage test http://www.webpagetest.org/result/150429_62_19PT/1/details/ - loaded in 3.7 sec is not extremely bad but not great either. You could probably reduce the load time by combining your 19 js & 6 css files. For mobile 400K images & 270K javascript (!) is probably a bit too much to load over a mobile connection(the test also shows the double redirect).rgds,Dirk
Hi Patrick,
If the question would have been about country targeting I guess your answer would have been correct. As mentioned in the article however, the lowest level of geolocation is country. As the question was about locations "nationwide" I would conclude based on this article that at this point of time Google is unable to detect geo-targeted content based on region or city.
Even for countries I think it's a risky business - as the article doesn't indicate if this "local" bots visit the sites with the same frequency & depth as the normal ones, and they don't clearly indicate which country ip's are used.
It's a different story for languages - because you can indicate in the HTTP header that the content is depending on the user's language. A similar case is the dynamic serving for mobile (https://developers.google.com/webmasters/mobile-sites/mobile-seo/configurations/dynamic-serving?hl=en) - here you can indicate that the content is changing based on the user agent.
As far as I know, there is no way to indicate in the HTTP header that the content is varying based on ip address.
rgds,
Dirk
Hi Ravi,
Not sure which link checker you are using - I did a quick check with both Screaming Frog & an extension in Chrome. Both indicate that the anchors do not generate 404's. They seem to be functional as well so it shouldn't be a problem.
Anyway, anchors exist for ages and do not cause SEO issues - so it's safe to use them.
I noticed that both the www & non-www version are accessible - you might want to choose a preferred version & redirect the other one.
Dirk
Hi Peter,
Don't really understand your question about permalink & url - as far as I know a permalink is just an url which remains permanent. Could you give an example of what you mean?
GWT is checking if pages exist - it's not showing you errors if only a part of the page (like the image is missing) - Screaming Frog is much better to help you with this. If Screaming Frog is detecting the issues, it implies that there are links to these images. When you go to the "Response Code" tab - filter on 4xx errors and click on the image url - you can see in the window below under "inlinks" which pages are linking to this image.
Dirk
Hi,
You could check this tool http://flang.dejanseo.com.au/ to check if the tags are properly implemented.
rgds,
Dirk
Hi Ana,
Just to clarify - if you redirect based on ip to a location based url like /newyork you can still have a link on the page going to the other locations like /sandiego - so Google can access all these pages & index them. This is not possible it the scenario you mentioned.
Not sure how old the article from unbounce is, but Google bot is able to interpret javascript (to a certain extent). Using javascript won't change the problem - as long as you have only one page that adapts automatically to the ip location you will be unable show all versions of the page to Google - it will help your Californian branch, but hurt all the others.
rgds,
Dirk
No they will not be indexed. Check: http://googlewebmastercentral.blogspot.be/2007/03/using-robots-meta-tag.html:
If content values conflict, we will use the most restrictive. So, if the page has these meta tags:
We will obey the NOINDEX value.
Dirk
Hi,
Don't think that there is a plugin for this (most people need it the other way round).If you have access to htaccess you could add a rewrite rule which is redirecting all https request to http - see https://sites.google.com/site/onlyvalidation/page/301-redirect-https-to-http-on-apache-server.
Options +FollowSymlinks
RewriteEngine on
RewriteBase /
RewriteCond %{SERVER_PORT} ^443$ [OR]
RewriteCond %{HTTPS} =on
RewriteRule ^(.*)$ http://www.example.com/$1 [R=301,L]
The other option would be to check if you can optimise the https to render faster - you could check this article (especially the part on SPDY): https://yoast.com/move-website-https-ssl/
Hope this helps,
Dirk
This can have different reasons - without having the actual example it's difficult to assess. Based on the info you give, adding all this content, video, images, it could be that your page became a lot heavier to load (check the page on webpagetest.org and with pagespeed insights). May be you exaggerated a bit with the optimisation - and is Google considering the page a bit too spammy.
If possible, can you give the actual url of the page?
rgds,
Dirk
Jennifer,
Some of your pages still reference http images - example https://www.tsheets.com/proadvisors-we-trust.php calls image http://cdn.tsheets.com/images/pros/denise-loter-koch.png
"Your connection to www.tsheets.com is encrypted with obsolete cryptography. However, this page includes other resources which are not secure. These resources can be viewed by others while in transit, and can be modified by an attacker to change the look of the page."
This is probably the reason for the 804 errors in Moz.
You should also check your internal links - some of them still point to the http version which is then again redirected to the https version
Example https://www.tsheets.com/infographics/time-tracking-infographic-hr-industry links to http://www.tsheets.com/infographics/time-tracking-infographic which is then redirected to https.
Unrelated to the https - but you might want to optimise the image on https://www.tsheets.com/online-invoicing-and-billing/ (https://www.tsheets.com/online-invoicing-and-billing/images/main-image-billing.png)
rgds
Dirk
Difficult to tell how long it will take before it's completely removed (Google is never very clear on how long it takes). If it's urgent you could use the url removal tool :https://support.google.com/webmasters/answer/1663419?hl=en
Dirk
The way you structure the url has no impact on SEO performance (unless the url becomes very long & unreadable).
The depth of a site has an impact (how many clicks do I need from the homepage to get to a page) but this is completely unrelated to the folder structure. A good article on why it's good to have a certain structure in your url can be found here: http://www.bruceclay.com/blog/structured-urls/
As changing URL's always carries a risk & doesn't bring SEO benefit I wouldn't change them just for the sake of changing them.
Dirk
Hi Dustin
I checked the last example a bit more in detail:
Webpagetest indicates that his page is even heavier than the one I tested the first time - results here: http://www.webpagetest.org/result/150501_XQ_Q1H/ (load time ok - but page way to heavy)- page speed analyser results are not terrific either. Check also the links on the page - a lot of your css files seemed to be 301 to a new location - it's better to call directly the final location. Optimising shouldn't be too difficult - compressing images, js,..etc should really increase your scores.
Also on the technical side, probably good to clean the code a bit. You don't really have to pass the W3C validator test, but it seems your page generates a awful lot of errors.
From a content perspective - looks good. A remark could be that a lot of content is not directly visible when loading the page (read more, tabs). Google announced end of 2014 that they don't really like content that is hidden when the page is loaded (https://www.seroundtable.com/google-hidden-tab-content-seo-19489.html). Don't really think this would cause a drop - but it's something you could consider changing if you modify the HTML code.
Hope this helps,
Dirk
The normal way to check is like you did - if it fails it implies something is wrong with the way you set it up. Check the link in Patrick's answer - the doc of Google is quite detailed how to set it up properly.
rgds
Dirk
In the example you give the meta description is too short (70 characters - should be 155 or even longer). If Google thinks your meta description isn't good at describing the content on the page, it will select another part of the content which seems to be more appropriate.
I would try to make the meta description a bit longer & teasing. The text should be both descriptive & teasing for the searcher to click on it. Check here https://moz.com/learn/seo/meta-description
Dirk
To add to the previous comment - crawl delay is ignored by Googlebot. Check http://tools.seobook.com/robots-txt/
It can be used to limit the speed for the bots - it is however not part of the original robots.txt specification. Since this value is not part of the standard, its interpretation is dependent on the crawler reading it
Yandex: https://yandex.com/support/webmaster/controlling-robot/robots-txt.xml#crawl-delay
Didn't find more info for Bing (they mention it here but do not provide additional info: https://www.bing.com/webmaster/help/how-to-create-a-robots-txt-file-cb7c31ec
If you want to limit the speed for Google bot you have to do it in Webmastertools.
Dirk
If the external links to these pages are ok in terms of quality, and you don't have a similar page on the new site, I would redirect these pages to the homepage. It would be a bit of a waste to loose good links to your site.
For the ones that have no (quality) incoming links - you could put a 404 (or in your case probably better a 410 - The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent) - see also this video of Matt Cutts on this topic. As Patrick indicates - a custom version is more user friendly compared to a standard one.
rgds,
Dirk
Hi Donna,
Didn't forget your question - however the first reply I got was a bit too generic (Drupal can do everything that Yoast does, and even better, but sometimes several modules are required).
Would it be possible to indicate for which Yoast functions you would need a solution - so I can be a bit more specific in when asking info from them.
Rgds,
Dirk
There is long article on the dev blog how they determine whether pages are duplicates - check https://moz.com/devblog/near-duplicate-detection/ - it's quite technical stuff - but this is the part which might interest you:
"This leads to one of the questions we get asked a lot: Why do I see duplicate content warnings in the context of Custom Crawl for pages that I see as different. Ultimately, it’s always because of the same reason: because no dechroming is done, there is a small amount of unique content relative to the total content. One of the places where this crops up a lot is web stores, where there’s a large amount of chrome layout, but only a short product description associated with it."
Dechroming : removing things like navigation, footer, ..etc from the page (exact def. to be found in the article)
If you compare both pages - apart from the image & product title there isn't too much difference between them so the crawler sees only a very small % of content which is different and marks them as duplicates.
Dirk
You can combine them, but not in the way you are actually doing.
If I take your example: page: www.rococlothing.co.uk/boys/boys-suits/?p=2
=> with this set-up you are basically telling Google 2 different things:
The canonical indicates that http://www.rococlothing.co.uk/boys/boys-suits/?p=2 is in fact a duplicate of http://www.rococlothing.co.uk/boys/boys-suits/ so Google should index http://www.rococlothing.co.uk/boys/boys-suits/ instead.
With the rel next/previous you tell Google that http://www.rococlothing.co.uk/boys/boys-suits/ - http://www.rococlothing.co.uk/boys/boys-suits/?p=2 & http://www.rococlothing.co.uk/boys/boys-suits/?p=3 should be considered as one page rather than 3 pages.
As these messages are in conflict this set-up is not going to work. If you want to use both - the canonical can only be used to strip additional info from the url like sort order, number of items on page, etc. Check the link Dimitri gave for an example from Google.
An example from your site: http://www.rococlothing.co.uk/boys/boys-suits/?dir=desc&limit=24&order=price&p=2 would have this configuration:
(please not that the first url is http://www.rococlothing.co.uk/boys/boys-suits/ & not http://www.rococlothing.co.uk/boys/boys-suits/?p=1 )
Hope this clarifies
Dirk
With a 301 you communicate that the requested resource is no longer available (The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs- source: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)
If you look at the definition of a canonical url - it indicates the preferred URL to use, so that the search results will be more likely to show users that URL structure. (Google attempts to respect this, but cannot guarantee this in all cases.)
So basically what you are telling to Google:
On your site you ask Google not to index site.com/A.htm - but rather to index url site.com/B.htm
On the url site.com/B.htm you put a 301 to site.com/C.htm - in other words force Google to index C.htm rather than B.htm (the 301 indicates that the page has permanently moved to a new location - so is no longer available on B.htm)
So in fact - you ask Google not to index A.htm but C.htm instead. Rather than doing this in a complicated 2step process using both canonical & redirect it would be simpler & make more sense to directly put a canonical url on A.htm with C.htm as canonical.
In your case you could create www.site.com/iphone but if it's identical to www.site.com/iphone(black,16,000000000010204783).html I don't think you will gain a lot (especially if it requires a lot of development)
rgds,
Dirk
It's will not have a big impact - while not really common, it's ok to use parenthesis in the url. Just makes the url a bit more difficult to remember, a bit like very long url's. In the example you give - not sure if Google is going to interpret this & that as two different words or that he will think of it as one entity this(that). If this or that are important keywords for you - it's may be better to put a - between this-(that)
Personal experience - redirecting from subdomain to main domain shouldn't have a big impact (maybe some temporary fluctuations).
Changing the design can have a huge impact. We did a relaunch recently where both url / ux where changed and we had a massive drop of traffic - even when all url's where properly redirected. We did notice however pageviews/visit go down & bounce rate increase which indicated that our visitors had issues with the new (responsive) design. It took us about 4/5 months to return to previous traffic levels - but we still haven't recovered some of our top positions for very competitive keywords.
Dirk
Hi,
Don't really understand your remark "it's definitely not a duplicate site" - according to me it is exactly that.
Set-up seems to be quite straightforward: both domain names point to the same server which is a classical case of duplicate content. The domains both are registered by the same company (I guess your client who probably forgot the existence of the old domain) - so all the content is available on both domains
What you should do is to choose a principal site & redirect the other domain with 301 to the main domain which should solve the issue.
rgds,
Dirk
Difficult to confirm without having the actual site. Looks like analytics spam on first sight.
You can find some useful info on how to block this in this article: http://moz.com/blog/how-to-stop-spam-bots-from-ruining-your-analytics-referral-data
rgds,
Dirk
Did you check these pages with the robots.txt tester in Webmastertools to be sure that these pages are really blocked for bots? Did you exclude all bots or only the Googlebot?
Hi,
The tagging seems to be on organisation level and looks ok on first sight (you can always check the tag inside WMT or using this tool . From your question I do not really understand where you add the product specific info. Normally they should be in two separate itemtypes: organisation / product (the one for the product should be without the aggregate rating - as this only exist for the organisation & not for the product).
You could check the example on https://schema.org/LocalBusiness (scroll to the bottom) for the tagging of your organisation. For the product - you could check the tagging on https://schema.org/Product (idem).
Hope this helps,
Dirk
If you see a sudden change in Analytics it's very often related to a problem with the tracking code. You could install the Analytics plugin for Chrome & check your pages. It could be the same visit is tracked twice - as Bill says - check the bouncerate. If this has significantly decreased it's almost certain a tracking issue.
You could check that you don't have a meta refresh or something similar which could artificially boost your page views.
Hope this helps
Dirk
Hi,
You might want to check the FAQ on OSE which discusses the most obvious reason why no links are showing up and why there is a difference between OSE & Google WMT.
rgds,
Dirk
