Welcome to the Q&A Forum

You missed Casey's most important point, zoomzoom. You say the primary phrase you're targeting on the home page is "3d IC technology". But the only place that phrase exists is once in the meta-title of the page.

There's no way a page is going to rank for an even moderately competitive term by only have it in the meta-title. If that phrase is the focus of the page, it should naturally occur multiple times in the copy of the page, in captions, alt tags, etc. Right now, Google has no solid reason to think the page is actually about that phrase.

Now, whether the home page is the most valuable one to rank for that phrase is another discussion, but if that's the page you want to rank, you've at least got to use those words on the page!

Hope that helps?

Paul

Fully agree with Andy. The trick with these kinds of design updates is to have a clear testing plan to make certain that, even though you don't think URLs, content, titles etc are being changed, they actually haven't changed. There can be many edge cases where, even though the template change should interact the same way with all content, titles, URL rewrites etc, it just might not. You want to confirm any such cases have been found and fixed before going live with the new design.

Paul

Unfortunately, you can't specify browser caching for 3rd party content, Chris. Those cache specs would have to implemented by the site the content is actually hosted on.

The only way around this would be to store the 3rd party scripts on your own site and reference them locally. Then they would fall under the caching directives your site had set. This is usually a bad idea though, as it means you'll have no way of knowing when those scripts might have been updated.

This is one of those areas where site speed best practices simply can't be applied to 3rd party content. And if it's just a few such resources it's not going to have much effect on page speed anyway. Where possible, try to load these scripts asynchronously (like analytics.js) or at least place them in the footer of site if you can.

Hope that helps?

Paul

Your second version is correct, ALBA123 - the robots protocol does require you to include a disallow statement in order to be correctly configured, even if it's blank to indicate crawling the full site.

I really question the wisdom of having a crawl delay in place though. What's the reason for doing so? I never want anything to get in the way of the search crawlers "doing their thing" as effectively as possible.

It's also rather strange to go to a crawl delay, but not be blocking the crawling of any of the non-essential sections of the site. Usually a crawl delay is in place to reduce the resource use by crawlers (vastly better to improve the efficiency of the site or get stronger hosting) but delaying crawl for the whole site instead of saving resources by blocking the non-essential areas first is pretty heavy-handed.

Doers that make sense?

Paul

Just step back and think about this logically, Kimberly. OF COURSE the contact page and consultation page are going to have the most internal links. They are the primary call-to-action pages for the website so SHOULD be mentioned on every page, so visitors can become customers. Pretty much every well-designed website out there will have their primary call-to-action pages as the most-linked.

Remember, pages rank for search terms. Just because a Contact page has lots of internal links pointing to it doesn't mean it will rank for anything other than the term "Contact Us". Because that's all the page is about. And having it rank for Contact Us in no way affects any other pages' ability to rank for their target terms.

Now, if you use that report in reverse - to discover that a critical page has few other internal pages linking to it - then you have an architectural problem with your site. You'd need to figure out to get other, related, influential pages linking to the underserved page if possible. But again, remember: internal links can only pass a bit of the internal value your pages already possess. Only new incoming external links can bring in incremental additional value to a site. It's those external links that bring in new value to move up the SERPS and attract new traffic. On-page optimisation can only take you so far..

Regarding no-follow, we're back to a simple functionality that too many have tried to abuse for a purpose for which it wasn't designed. (or at least something it no longer accomplishes due to a change by Google).

There are essentially only two reasons to add a no-follow to a link:

1. you don't trust the destination of a link (e.g. the link has been created by a user on your site, not by you as site owner - links in comments are a perfect example of this)
2. you have a transactional relationship with the site that is the destination of the link (e.g. they paid you for the link, you traded links with them, they provided you guest-post content in exchange for the link etc.)

Since neither of these should ever apply to links within your own site, it's almost never a good idea to have internal no-follow links. (And as someone else mentions, applying no-follow doesn't "save" any link influence for other links, it just throws it away. This is the change Google made a year or so after no-follow was first introduced.)

Lastly, and to wrap up another long-winded answer Just because an SEO or Analytics tool reports a particular metric doesn't mean it's important. You must filter the information provided through your own experience and expertise to decide if and how it is relevant. That is what makes SEO both Art and Science.

Hope that all makes sense?

Paul

Having the target keyword in the URL is only one of many ranking signals, Reed, and in my experience a fairly small one. In addition, contrary to Ahalliday's claim, 301 redirects DO in fact dilute "link juice" by the same amount as regular links would (some estimate by up to 15%).

So in my opinion, you'd be on a fool's errand. Whatever you gained from having the keyword in the URL would be lost by passing through a juice-reducing redirect. I'd say you could find much more productive ways to spend your optimisation time. That's not to say you can't still tune up your other on-page factors for the "better" terms, especially If you're already ranking for the higher-volume term with that page. Even better - invest a little time getting some off-page boosts, like earning a few good links. Maybe add some additional quality content like images, video, comparison charts, etc. That'll have far greater effect.

Does that make sense?

Paul

To note, Kimberly - Webmaster tools keeps a historical record of issues. It may be showing you server error that occurred in the past, but is no longer a problem. Easiest way is to test the URL it is reporting as having problems.

First test by visiting the URL using a regular browser. Then revisit using a regular browser, but with the user-agent set to imitate the Googlebot crawler since it's Googlebot that's reporting the error. (You can do this using the Set User Agent tool built into the Moz Firefox toolbar, or others. It's a critical capability to have for many purposes.) It's possible for the Googlebot to have issues even if a regular visitor sees none, so you want to test for both.

Assuming these tests return the 500 server error, just briefly rename the pertinent htaccess file for a minute, then go back and rerun the tests. If the error goes away with the htaccess disabled, you know the source of the problem lies in the htaccess rules. If the problem persists, you can be pretty certain it's not the htaccess causing it.

Make sense?

Paul

From your description, it appears that when you were tweaking your Yoast SEO settings, you changed the permalink structure in the WP Dashboard's Settings > Permalinks section from www.domain.com/�tegory%/%postname%/ to just www.domain.com/%postname%/

Doing this causes all the URLS for all posts on your site to change, which means all the original URLs are no longer correct and result in 404s.

Your two options are:

• reset your permalinks back to their original structure, and redirect whatever new posts were created since the initial change back to the /category/postname URLs
• leave the new permalink structure in place and add a blanket rewrite rule in the htaccess file to redirect all the old post URLs to the new structure without the category. (Done properly, only one redirect is needed to handle all the post URLs.)

Personally, for improved site architecture and to keep from having all your existing posts run through redirects, I'd opt for the first option above.

Hope that all makes sense?

Paul

P.S. Make certain you have a current backup of the site before making any further changes, just in case.

I had to laugh, Andy. I essentially needed 7 paragraphs to say what you said in 1 sentence: "yup, ignore the WMT report"

I'd been back 'n forth in another question with Kimberly too though, and she'd indicated she was interesting in learning the background "whys & wherefores" to her questions as well, so that's why I went on a bit on your succinct solution.

P.

You have a configuration choice in your WooCommerce settings that is causing this, Bob.

You've got the default customer location in settings set to "Geolocate (with page caching support)". This causes the variable to be added to the URL in order to enable the geo-location for each customer. Turn it off and the variable will no longer be added.

And yea, this is a disaster for SEO, as Dana explains, and it will also badly foul your Analytics and it even borks your site's internal search.

Hope that makes sense?

Paul

Gotcha. Then Dana's suggestions will be good. The challenge you'll probably encounter is one of matching cost for an audit against the business value. The companies recommended by Moz tend to be at the higher end of cost, because they're large companies with plenty of experience and expertise.

Paul

Definitely use option #2. There's no reason to have to maintain a server presence for the old site if it's been replaced. This is best practice - still fully allows ranking authority transfer to new domain.

Yes, it's a lot of work to do the redirects. Watch for cases where large numbers of URLs are the same, with just the domain name changed. Or that all have similar change required (e.g. removing a /category directory) Those can be handled with a single regex rule instead of having to create an individual redirect for each.

To ensure you catch as many of the old URLs as possible you can use the Screaming Frog crawl as the list of URLs needing redirects. Can help to merge that with with the old site's XML sitemap for completeness. Note - you'll have to redo the redirects from the plugin as well, as those will no longer work after the DNS is pointed to the new domain.  Check the old site's htaccess for an legacy redirects as well. It's usually also beneficial to redirect the images and other important media (pdfs and other downloadable files) if you can.

Then set up a process to monitor Google Search Console and Google Analytics on the new site to immediately detect and correct any new 404 errors that show up. (That's another major advantage of doing the redirect on the new site's htaccess - the 404s will actually be detectable with tools.)

Lastly, ensure you've used the Change of Address tool in Google Search Console to notify Google that the old site has moved to the new domain. Keeping the old site verified in GSC will allow for this, and will let you monitor the drop-off in indexing of the old site as Google recognises and indexes the transition.

Hope that all makes sense?

Paul

You can't set clientsite.com as the canonical home page, because it's not, FPD. The very definition of "canonical" means it is the actual URL that displays the page content. A URL cannot be canonical if it redirects, is no-indexed, etc.

In your case, using clientsite.com as the canonical would badly damage your ranking capability, because you'd essentially be telling the search engines to rank a page that has no content and essentially doesn't even exist. Clientsite.com/store is the canonical homepage for your site, and should be set as such.

The only way to change this would be to use a system that doesn't require the redirecting of the domain to the subdirectory. (And if you're sticking with the current system, make certain that the redirect being used is a 301, not a 302.)

Hope that helps?

Paul

The only way an XML sitemap can work is if it's on the web, Sung. And the best place for it is at the root of the website.

You can upload the file using an FTP program like Filezilla, or your hosting control panel like cPanel may well have a simple file manager that will allow you to upload the file.

The root of the website on most shared hosting is in the public_html folder. Once the file is uploaded there, the URL for the sitemap will be www.example.com/sitemap.xml and that's the URL you'll submit to Google Search Console and Bing Webmaster Tools.

Make sense?

Paul

You need to be aware, Jonathan, that there is absolutely nothing about a robots.txt disallow that will help remove a URL from the search engine indexes. Robots is a crawling directive, NOT an indexing directive. In fact, in most cases, blocking URLs in robots.txt will actually cause them to remain in the index even longer.

I'm assuming you have cleaned up the site so the actual spam URLs no longer resolve. Those URLs should now result in a 404 error page. You must confirm they are actually returning the correct 404 code in the headers. As long as this is the case, it is a matter of waiting while the search engines crawl the spam URLs often enough to recognise they are really gone and remove them from the index. The problem with adding them to the robots.txt is that is actually telling the search engines NOT to crawl them, so they are unlikely to discover that they lead to 404s, hence they may remain in the index even longer.

Unfortunately you can't use a no-index tag on the offending pages, because the pages should no longer exist on the site. I don't think even a careful implementation of a X-Robots noindex directive in htaccess would work, because the URLs should be resulting in a 404.

Make certain the problem URLs return a clean 404, use the Google Search Console Remove URLs tool for as many of them as you can (for example you can request removal for entire directories, if the spam happened to be built that way), and then be patient for the rest. But do NOT block them in robots.txt - you'll just prolong the agony and waste your time.

Hope that all makes sense?

Paul

Its' entirely possible that Google doesn't consider the posts newsworthy. Just having the technical markup for News doesn't mean it will be considered such by the search engine.

Paul

No-following links has ABSOLUTELY ZERO EFFECT on preserving "link juice" of a page, Rich. This used to be the case six years ago when no-follow for links was first introduced, but it was being abused so badly that search engines changed this behaviour. (This used to be referred to as PageRank sculpting)

Further to Andy's and Dmytro's comments - Google is clear there are only three circumstances when no-follow should be used:

1. you have a commercial relationship with the page you're linking too (paid links, but also many guest post scenarios for example)
2. you didn't create the link and therefore can't trust it (e.g. user comments or other user generated content)
3. you are linking to an unreliable site (to demonstrate a bad example,for instance)
4. (and a bonus fourth) links to administrative-type pages that wouldn't be of any use to a search visitor like a privacy/terms of service or login page).

There's also been considerable discussion that Google in particular considers no-following of all external links a sign of unnatural manipulation that could damage page authority.

So... conceptually a good idea at one time, but no longer valid and potentially harmful.

Hope that helps?

Paul

Just because other similar sites didn't get hit doesn't mean that's not what happened to yours.

You've noted elsewhere that these sites are all basically duplicates of each other - Google could be starting to recognise and filter against that.

That said, diagnosing these kinds of issues takes much more in-depth information than can be checked quickly from outside the website.

Paul

Yup, that's exactly correct - just the way you first proposed.

And if you want it straight from the horse's mouth, here's Google's own description of implementation best practice for your exact situation:

rel="next" and rel="previous" on the one hand and rel="canonical" on the other constitute independent concepts.Both declarations can be included in the same page.

For example, http://www.example.com/article?story=abc&page=2&sessionid=123 may contain:

Note the canonical for the page is self referential to the version of the page including the basic variable that defines the actual page, leaving out the more dynamic variable of sessionID - the same way you'd want to leave out the dynamic size or colour variables, for example, which are specific to only that visit.

From https://webmasters.googleblog.com/2011/09/pagination-with-relnext-and-relprev.html
With a big whack of followup confirmation in this discussion with Google Engineer Maile Ohye https://productforums.google.com/forum/#!msg/webmasters/YbXqwoyooGM/0XTh-gIxS7YJ

Don't forget you can also use the tools in GSC to help GoogleBot understand which of your URL variables are indexable and which should be ignored. Only helps Google itself, but hey, every little bit counts

Good luck!

Paul

As long as the correct 301-redirect is in place, there's no SEO benefit to keeping the original page, as it can never be reached. That's the whole point of a 301-redirect.

For content management purposes, you might find it useful to keep the old posts around in draft form in case you want to use them as a basis for writing a new post/faq, but there's no reason to keep them available otherwise.

Hope that makes sense?

Paul