Welcome to the Q&A Forum
Browse the forum for helpful insights and fresh discussions about all things SEO.
Hi Anirban,
The impact of adding the few lines of extra code of schema.org will be zero on the load time of your pages.
Apart from that, serving different content to bots & human users could be considered cloaking by search engines.
Implementing schema.org on the normal pages should do just fine!
rgds,
Dirk
Hi,
You should redirect the old url's to the new ones using a 301 redirect. Normally it's not really necessary to submit for re-indexing, Google is quite good in finding new url's itself.
The fact that Screamingfrog still finds the old url's is a sign that on your site you are still using links to the old url - you should update the internal links to the new url (you can easily get this info from Screaming frog - take the url's that have a 404 - check at the bottom of the page "In Links" - this will give you all the pages where the links need to be updated.
rgds,
Dirk
Great video Matt! Should be 'obligatory' to watch this video before posting the first question.
Hi,
Why would you do that for? A coming soon page has no value for visitors, and as a result no value for search engines.
If you're going to create a new site, I would first launch the new site and then redirect the old pages to the new ones.
rgds
Dirk
According to Google webmaster guidelines - a sitemap for users still has some value:
Offer a site map to your users with links that point to the important parts of your site. If the site map has an extremely large number of links, you may want to break the site map into multiple pages. (source: https://support.google.com/webmasters/answer/35769?hl=en)
I agree with Patrick that now most people don't bother to consult sitemaps - if they need to consult it to find their way on your site you probably have a UX problem.
For SEO purposes - it still can have some advantages:
Sites like Linkedin.com still use these HTML indexes (although they are not called sitemaps but member lists) - as you can check when you visit the site in "Incognito" mode in your browser.
rgds,
Dirk
Google Academy http://www.google.com/analytics/learn/index.html would probably be a good starting point. Or just trial/error with some support from online help. It's pretty self-explanatory.
rgds,
Dirk
You can use Screaming Frog to identify the pages with highest load times as well as the heaviest images. Also check speed reports in Analytics (Behavior > Site Speed).
Once you identified the slowest / heaviest pages you can do more detailed testing using Google Pagespeed Insights (can be called directly from the Site Speed report in Analytics) and webpagetest.org.
You don't need to check all the pages on your site - checking a few different templates should be sufficient to identify the most urgent issues.
Dirk
I think these names would be fine and following google guidelines for image search (https://support.google.com/webmasters/answer/114016?hl=en) - quote: "The filename can give Google clues about the subject matter of the image. Try to make your filename a good description of the subject matter of the image. For example, my-new-black-kitten.jpg is a lot more informative than IMG00023.JPG. Descriptive filenames can also be useful to users: If we're unable to find suitable text in the page on which we found the image, we'll use the filename as the image's snippet in our search results."
rgds
Dirk
The main reason to use internal "nofollow" links on your site if the links would go to technical pages like login pages, or links to pages that you don't want to have indexed. As Ryan says - if you link to other relevant articles there is no reason to use nofollow.
Dirk
Hi,
The difference between them
canonical : url has a canonical url - which can be self-referencing (canonical url = url) or not
canonicalised: url has a canonical url which is not self-referencing (canonical url <> url)
no canonical : quite obvious - the url has no canonical.
Potential issues could be - url's that you would like to have a canonical don't have a canonical or url's that are canonicalised don't have the right canonical url. You can use the lists (both canonicalised & no canonical) from Screaming Frog to check them - but it's up to you to judge whether the canonical is ok or not (no automated tool can guess what your intentions are).
Typical mistakes with canonicals: all url's have the same canonical url (like the homepage), or have canonical url's that do not exist. You could also check this with Screaming Frog using the setting "respect canonicals" - this way only the canonical url's will be shown in the listing.
Also keep in mind that canonical url's are merely a friendly request to Google to index the canonical rather than the normal url - but it's not an obligation for Google to do this (check https://support.google.com/webmasters/answer/139066?hl=en quote: "the search results will be more likely to show users that URL structure. (Note: We attempt to respect this, but cannot guarantee this in all cases.)"
Dirk
There are quite a lot of posts on Moz that cover link building. There is of course the beginner's guide, and this category page, which highlights the most important articles on link building.
Remember that all blogs once started from zero: without quality content, quality sites are not going to link to you. Create your content strategy and start building relationships. It will probably take time and a lot of effort, but it pays of in long run.
Hope this helps,
DIrk
Great work guys!
Would be nice if Moz would include this info yearly stats (https://moz.com/blog/the-best-of-2015) - activity in the Q&A section is now completely missing in this overview.
Comparing with total Moz points isn't always the best indicator:
As measure for activity in general:
Dirk
For old content which is expired - just let them 404 or redirect to a newer version of the page (if available).
For new content that is going to expire you could use the unavailable after tag - see also this advice from Matt Cutts on content that expires (it's more about products for e-commerce - but the general principle is the same).
Dirk
It would be quite logical. Compare it with real estate. Your primary location is your homepage -which normally will list your most important & interesting content. As you normally cannot put everything on your home, you shift less important content to level 2, and then 3 ..etc. The deeper the content - the less important you find it. So it's quite normal that Google follows this logic as well.
The second part is the number of internal links - because your most important content will receive a lot of internal links. Normally - the more links a piece of content receives, the closer it will be to the homepage (chances are bigger it receives links from the home, level 2 or level 3 content).
Index pages can help to move your content closer to the home - but this will only get you so far (this doesn't change a lot to the number of links these articles receive).
You could try to regroup your content in a cluster per theme - with it's own homepage & a lot on links inside the cluster to create more internal (theme based links) & move content closer to the home. There is an interesting post on this topic from Gianluca Fiorelli: http://moz.com/blog/topical-hubs-whiteboard-friday
Hope this helps,
Dirk
Hi,
If you look at the API pages it puts April 30th as date of next update (http://moz.com/products/api/updates)
rgds,
Dirk
It shouldn't- most people search in small caps anyway and Google doesn't seem to take capitals into account.
Dirk
Donald,
There are some issues with your site which could be causing the problems:
1. The load time of the homepage is quite slow -http://www.webpagetest.org/result/150316_8R_Y5A/1/details/ - apart from the heavy images, you also load a huge number of css & js files. If you analyse the page with Google Pagespeed https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fprimedraftarchitecture.com%2F&tab=desktop you get very low scores - both for mobile & desktop. I would remove some of the fancy stuff on the page & focus on the essentials. Follow the recommendation of both tools to make your site faster. This would be the top priority if it was my site.
2. There are some smaller on-page issues
3; Analytics
You seem to use both Universal & async tags on page (Universal on Contact / Async on the remainder) - on /blog you measure multiple 6 page views when only one should be measured. I would put everything on universal (and implement it in the head-tag
Hope this helps,
Dirk
Hi,
Try to answer your questions point by point:
1. You could add to your terms & conditions that sites created need to follow Google webmasterguidelines - and if they are not followed you can delete the subdomain.
2. Revoke the penalty is only possible by cleaning the site and removing the contested content. It depends on your current terms & conditions if you have the possibility to force the one who is managing this blog to clean the site.
3. Idem as above - if your terms & conditions didn't stipulate that messing with Google guidelines is forbidden, there is not much you can do at this point.
4. Wordpress is hosting the blogs on wordpress.com - the main site is wordpress.org. Weebly has terms & conditions that forbid Spam/SEO sites (probably Wordpress.com has this as well - but it's stated very clearly on the Weebly.com)
Update terms & conditions if necessary - send warning to offending blog users & delete them if necessary.
Hope this helps,
Dirk
Hi,
It seems that they are having technical issues - as mentioned by Rand last week on this question http://moz.com/community/q/when-is-ose-updated
"Our index is taking much longer to run than expected. We think there may be a hardware or software issues in processing that's having problems. We'll be doing maintenance so we can get back to faster indices ASAP."
We'll just have to be patient I guess,
Dirk
There is a similar thread here: http://moz.com/community/q/what-if-my-site-isn-t-ready-for-mobile-armageddon-by-april-21st
If you have a lot of mobile visitors coming in via Google, I think you may expect that this traffic will disappear (unless your competitors aren't very mobile friendly as well).
Nobody really knows what the impact is going to be, most discussions seem to agree that the impact will only be for mobile searches, but again, it's difficult to predict.
It also seems that it's defined on page - not site level, so you could try to provide mobile versions for your most important landing pages (dedicated or responsive). Your lay-out seems pretty straight forward, so I guess it shouldn't be too difficult to adapt it Remember that it doesn't have to perfect - it just needs to pass the "mobile friendly" test - https://www.google.com/webmasters/tools/mobile-friendly/ - you can always improve later on.
Hope this helps
Dirk