Welcome to the Q&A Forum

Actually, by far the best place to start in order to answer this question is with a Google Webmaster Tools account for your website. It's a free tool and is just as critical for running a website as Google Analytics is.

Once you have your Webmaster Tools set up, there is a section in it that will show you the keywords your site currently ranks for, and what their average ranking position is. The reason this average ranking position is so useful is that it takes into account all the search personalisation that your visitors experience. Also, this tool will tell you what keywords are already driving traffic, not just the ones you might know to ask about, as would be required with Moz or SEMRush rank-tracking tools. (And it doesn't suffer from the (not provided) issue which obscures quite a bit of the keyword info in Google Analytics.)

Does that get you started?

Paul

P.S. You can get the same info for Bing through their Bing Webmaster Tools. You should have both these Tools accounts set up right away anyway, as they are the only way the search engines can inform you if they detect problems with your site, or have imposed a manual penalty.

What you actually want to do is get rid of that index.htm address for your home page altogether, Oscar. You want your visitors to only be able to reach your homepage at one URL. This means you need to use 301 rewrites to make your /index.htm page redirect to your primary domain name. (E.g. the website name with no filename after it.)

You also want to make sure that you have chosen between www.youdomain.com and yourdomain.com (without the www) as the primary address, and rewritten the other one to point to the primary. This is called canonicalisation of the home page. The search engines see each of those addresses as completely different pages because they have different URLs - even though they display the same page. As a result, they'll be considered duplicate content and will effectively be competing against each other.

There are many questions here in Q&A that explain how to do these kind of redirects. Let us know if you can't find one that works for you.

Hope that helps?

Paul

If you were thinking of buying the videos from this year's MozCon conference, you'll want to jump on this. Today only, the collection is $249 (That's $50 off the member price, $150 off the non-member!)

The specific info and special offer code is available on Moz's Twitter post. You are following them on Twitter, right?

Happy Cyber Monday.

Paul

Writing a blog post and mentioning another site as a useful resource is the very definition of when you should leave a link as do-follow. Makes no difference what the DA of the other site may be.

There are really only two main reasons to no-follow a link:

1. You are linking to untrusted content/you didn't create the link yourself - user-generated comments in a blog are a good example of this, or if you're linking to a questionable website to use it as an example of a bad practice.
2. Links to websites with which you have a commercial relationship - e.g. links that have been paid for, or are part of a business arrangement with the other site.

The third reason is if you are linking to pages that aren't useful for a general reader, like registration pages, though this aspect often gets overused.

Hope that helps?

Paul

To add to what Daniel has said...

DoS and DDoS attacks are not malware or viruses trying to infect your website. The are Denial of Service or Distributed Denial of Service attacks, which are essentially attempts to crash your website by flooding it with so many requests for pages that the webserver overloads and crashes, or at least slows down so much that the site becomes unusable.

Sometimes these are maliciously aimed at a particular website to do the business harm, sometimes they are aimed at a host or server in general.

There's not much you can about them except protect against them with smart firewalls as you are doing. It's in your host's best interest to help you with this, as the attack can hurt other users on the server if it's a shared server.

Trying to track the source of the attacks is pretty much pointless because the computers doing the attacking usually belong to unsuspecting users who's machines have been infected with malware that is doing the attacking unbeknownst to them. (That's the kind of infection you want antivurus/antimalware on your own computer for - to make sure your computer hasn't been corrupted to be used as one of the "bots" attacking other people's websites.)

There are a number of additional steps you can take to protect your WordPress install from hacking (a solid, tested, consistent backup strategy is critical), but this issue isn't a hack attempt, as I've stated,. It's an attempt to flood your site with so many worthless visits that it can't keep up. So no amount of customizing WordPress will protect from this kind of attack. It has to be done at the server and network level.

Hope that makes sense?

Paul

You worded your question just fine, Ali.

You have to have separate URLs for each recipe. For usability, for social sharability as you mentioned, and for SEO. (Otherwise that poor single page is going to have to try to rank for all the different terms of all the different recipes. Hopeless.)

Also. make certain that schema markup for recipes has been properly applied to each recipe. That way if/when the recipes start to rank, they will show the recipe snippets in the SERPS, attracting more attention and clicks.

[edited to add - you'll also want to be sure you have a search and categorisation method (called a taxonomy) so that your visitors can quickly find the types of recipes they're looking for, instead of having to randomly scroll through a bunch of pages to find something they like. Something else that would be impossible with the current one-huge-bucket approach]

Hope that helps?

Paul

You're exactly right on what I meant when I referred to relevancy, Bob. Doesn't need to be exactly the same niche, but a reader would immediately understand why these two sites might be talking about each other.

So yea, I'd say trying to replace the sitewide with an editorial link to a relevant page on your site (same criteria) is probably the best/safest way to try to hold onto some of that ranking juice.

Glad you found it helpful - appreciate you letting me know.

Paul

In general, shoving a press release up onto a press release directory doesn't give you any backlinks of any value. Search Engines are fully aware that these kinds of links are self-generated and don't give them much, if any authority. In addition, most such services no-follow those links. And even if the release does get distributed beyond the PR directory, it will still have those no-follow links, and will clearly be duplicated content so unlikely to have any authority of its own to pass on.

The only way press releases provide real value is if there is something truly newsworthy for you to "release" and you put in the effort to pitch the information to real relevant news sources so that they actually write about it instead of just copying the release and slapping it up on a page.

The fact others are doing it doesn't mean it's a worthwhile thing to pursue. It's an approach from the old-school manipulative SEO days that hasn't worked for a long time, but so many sites are still looking for easy things to checkmark off their to-do list ("get 10 new links") instead of putting in the hard work to do things that will actually have an impact.

Hope that helps?

Paul

You need to get rid of the robots.txt block on those URLs you want to redirect, Alec.

As it is now with the robots block in place, you've told the search engines NOT to crawl those URLs So it's going to be very difficult for them to discover the 301 redirects and learn that they should be dropping the old URLs form the index. After that, it is just a matter of time. (It can also help to leave those old URLs in the xml sitemap for a while to make it easier for the engines to crawl them and discover the 301s)

If none of those URLs were generating any substantial amount of traffic or incoming links, you could also use Google and Bing Webmaster Tools to request that the pages be removed from the index. This will only really work if the pages are organised in a specific directory, as it would likely take far too long to annotate each URL for removal otherwise.

Hope that helps?

Paul

I'm afraid we're in a bit of a state of limbo on this issue, Nickington.

Currently, Google's ranking is based on the desktop version of the site for both desktop and mobile results.

Google has clearly stated, and many tests have confirmed, that content which is not visible unless a user interacts with the page (such as having to click the drop-down for the FAQ result) is deemphasized in search results.

BUT! Google has also stated that they are in the midst of changing to a mobile-first index which will mean that the mobile version of websites will be used for ranking assessment. In addition, they've been quite clear that at that point, since things like accordion drop-downs are so much better UX for mobile users, that kind of hidden content will no longer be "penalised".

Unfortunately, there's been no declared date for when the switch to the mobile Index will occur. Instead, they've said that it will be rolled out gradually to individual sites as they detect that the mobile version of a site is ready for it. This means it's entirely impossible to assess when the changeover might apply to your site.

So for absolute best SEO, the solution is unfortunately a bunch of extra work for a hybrid solution My best recommendation would be to build out the FAQ content using headers and sub-headers so the content is fully visible on the page and gets full indexing authority from the search engine. Then keep an eye on the mobile indexing of your site to detect when it appears that it has moved fully into the mobile-first Index stage, and at that point redo the FAQ page to utilize the accordion drop downs instead.

The alternative would be to build out the page using the accordion drop downs to start with, and accept the fact that it will be some time before that hidden content has a chance to rank effectively. this would definitely be a second-best option in my opinion.

Does that all make sense?

Paul

The successful way to accomplish this can depend a bit on your server configuration, esiow, but the most likely workable and reliable solution is to "escape" the non-standard URL characters. (Actually, the best solution would be to get rid of the unsafe URL characters altogether, but that's not what you asked )

.htaccess rewritedirect rules are essentially regular expressions or regexp. In regexp, many non-URL characters are used to format different commands. So having them as an actual URL character causes the redirect rule to try to process them as regexp instead of as just a URL character. Whew - hope that makes sense.

To tell the redirect rule to treat the non-standard character as an actual character instead of a command - you "escape" it by adding a "****" (without the quotes) in front of each character that could be a problem.

So:

RedirectMatch 301 http://www.olddomain.com/buy/nike-shoes/kobe(7)/red http://www.newdomain.com/buy/nike-shoes/kobe(7)/red

becomes:

RedirectMatch 301 http://www.olddomain.com/buy/nike-shoes/kobe**\**(7**\**)/red http://www.newdomain.com/buy/nike-shoes/kobe**\**(7**\**)/red

Give that a try in your .htaccess file and let us know if it works. if not, there may be a couple other options to try.

Hope that helps?

Paul

Nope - not for submitting for indexing. If there have been considerable page changes though, traffic could fluctuate as search engines take their time figuring out and understanding the changes.

Paul

Very. Bad. Idea. This  is exactly the kind of manipulative linking process that Google punishes with the Penguin part of their algorithm. At best, use a nofollowed link, but I'd be very reluctant to do this at all if these will be sitewide links and will be a really large proportion of your total backlink profile.

If you stop and think about this for a moment, you'll see why this is so risky. Certainly many who might use your plugin have quality sites. But many more of the sites that will be linking to you are likely to be questionable or downright spammy. Plus, almost none of them are likely to be related to what your site is about.

All these things combine to create the very definition of unnatural linking in Google's eyes.

Hope that helps?

Paul

Yea, you need to believe those tools, Nikki. In particular, if you click on the Page Loading Issues View Details in the mobile-friendly test, you'll see that there are errors with pretty well all the scripts on the page. And GSC's Fetch and Render is literally what the search crawler can see and process, so if it's not happy...

When I first visited the page, all I saw was the header and the footer as well.

Here's what I think is happening. Pretty well all the content on the page is being loaded with animations, which are JavaScript-based. You have RocketLoader enabled in CloudFlare which is known to cause havoc with JavaScript. (It takes over how JavaScripts get loaded on the page, but often doesn't handle it well). So I suspect that RocketLoader is interfering with the scripts that the page is depending on to display the animated content blocks.

Try turning off RocketLoader from within your Cloudflare settings, clear ALL caches for the site (CloudFlare's cache and any site/server-level caches), and check again.

Good luck! And let me know if that resolves it.

Paul

P.S. I'd recommend seriously reconsidering all that content animation on the page. All that "dancing macaroni" really interferes with the efficient reading of the page. Animation is supposed to be used to draw extra attention to one specific important thing on a page. When everything is wiggling and moving, nothing gets emphasised, and it's all just a major distraction and makes scanning the content nearly impossible.

If I were re-writing this URL, I'd do www.nlpca.com/DCweb/modeling-with-nlp.html in order to help the SEs understand the word boundaries in the keyword phrase.

But this is good example of getting lost in the weeds of SEO. Changing the URL is going to have only very slight effect. On the other hand, put bluntly, the article itself is very poorly optimised. You'd have vastly greater effect by spending your time improving the article itself instead of fussing with the URL. Prioritise the biggest effects first.

• I assume the target phrase is "modeling with NLP" and yet that phrase only appears in the meta title and title - nowhere else on the page. Obviously you don't want to spam the page with keywords, but only a single mention of the target phrase means you'll have a very hard time ranking the phrase. I realise it's a reposting of an existing article, but since it's your own article, there's no reason you can't update the content a little for web purposes. (If in fact you're targeting the term "NLP article" you're targeting far too broad (and essentially unrelated) a term with that page)
• The meta-description is essentially worthless as a call-to-action to encourage a searcher to want to read the page. It's awkwardly phrased and shows no value proposition to the searcher for reading.
• Page is visually a mass of text. I'm not a fan of decoration for the sake of decoration ("dancing macaroni" as my old designer friend calls it) but breaking this up with pull quotes, an appropriate related image, a flow chart etc would make it much more readable and less visually intimidating.
• The biggie: Page has only 1 incoming link and only 1 social share. Spending time getting social exposure and conversation going about the article would go a lot further than fussing with the URL. (Although the site also has no basic Open Graph schema, so that's a bit of a hindrance, but if you don't control the site, that point is probably moot).

So there's my perspective. Focus your time on the things that could seriously move the needle for the page, before fussing with a minor detail like changing the URL wording.

Dos that make sense?

Paul

Just to be clear - when you say both sites are identical, do you mean that there is actually just one site that will have both the .com and .ca pointing to it?

If so, and as long as you correctly use a 301 redirect to point your .ca to the .com, you won't have any problem with duplicate content.

That's exactly the sort of issue 301 redirects are specifically designed to solve.

Just a tip for useability...

As a Canadian, when I get redirected to a US .com site, I'm often left to wonder whether the US company can actually serve me well in Canada.

You might want to consider pointing the .ca domain to a landing page on the .com site that functions as a "Canadian home page" and includes explanations to potential CDN customers about all the great ways you can take care of them.

• assurance that you ship inexpensively and efficiently to Canada
• whether pricing is listed in US or CDN dollars
• how service is provided to Canadian users if needed
• that your product meets Canadian safety standards, licensing etc if applicable

The landing page can graphically mimic the regular home page, but with enough Canadian-market-specific content to keep it from being a dupe of the regular home page.

Paul

It's likely the other site is trying to use the redirects to mask their manipulative link building. (Which doesn't work, by the way.)

Short answer - no this isn't a good idea.

Hope that helps?

Paul

NameCheap.com is another that will definitely let you 301-redirect one domain to another in the DNS admin (ie no hosting needed)

If you need multiple levels of redirecting, you could just set up the old site as an additional site on the server account that's hosting the new site, and install the htaccess file at its root, with no actual site installed. Then use the old domain's DNS to point to the new location containing the htaccess.

Paul

Just to add a couple quick points to the good answers above:

It's not possible to use the underscore "_" in domain names - not a legal character.

As far as using the .co because the .com and .co.uk are already in use - bad idea for another reason. The reality is most people are still not familiar the.co TLD (probably a bit more so in UK where they're already used to hearing .co.uk)

This means a huge number of your potential customers will accidentally type in (when going direct in the browser's URL bar and when linking from their own sites) the more common TLD, resulting in your hard promotional work sending your business to your competitors.

Not to mention the massive headaches when email addresses are accidentally written with the wrong domain ending.

The .co is an interesting addition, but it's still way too far out of the mainstream to risk as your primary domain at this stage, IMO.

Paul

Dana, if "all" you need from the old install is a .sql export, that can be done from the hosting control panel (eg cPanel) or directly from phpMyAdmin even if there's no hosting control panel in use. That eliminates the need to access the Drupal install altogether

I would find out who they're hosting with and if they have the hosting control panel credentials, log in there and retrieve the sql dump. If they don't have the credentials, it's usually only a few minutes with the hosting company proving you have all the payment info necessary to prove that you (ie the arts org) own the hosting account. Then the host will provide new credentials and you can go ahead with the sql dump.

Paul