Welcome to the Q&A Forum

I would say this has more to do with off-page tactics. Though the on-page could use some work. The site has only been live for a little over a year. A lot of the links the site had appeared to have gone in August, per crawl.

That's actually a good thing. You're going to learn about over-optimized anchor text. In short, don't do what has happened.

The vast majority of the anchor text for the links were 'xyz brass'. These aren't competitive terms, so a few links went a long way. Now the majority of the few links are gone. Thus the rankings are down.

It looks like you can still do pretty well taking a semi-local approach, from a links perspective. The local approach is generally clean. Claim your business listings, include enough relevant information - rinse, lather and repeat. That should help some.

Now, the one thing that appears to be discounted is the fact that shooting/reloading has a wide and passionate audience. There's a lot that can be done there to gain legit links. One just has to be a little creative.

I understand shooting. I like a lot of the military guns, especially curio & relics. I know not to buy combloc ammunition with brass casings from the 50's-60's. Shooting squibs or generally having a receiver or slide blow up in my face is not my idea of fun.

That being said, I think you should definitely start targeting more 'reloading' keyword variants. That's what the site is there for, right? I have to disagree with the '9mm brass casings for sale' example. (Sorry David. I know it was just an example. Still bros? Good.) 'Once fired caliber brass' is definitely a better target. It's what you're selling, it has some volume and it isn't terribly competitive.

David is most definitely correct about the WWW version of the site and HTTPS. You should get that redirect fixed, ASAP.

The images you do have look fine to me, in regard to file names. You have the caliber and the keyword in there. They also have alt attributes that make sense enough. Though some of the images are on the large side, in regard to file size. Having the image dimensions of the image in the file name is actually a recommended practice as well. Folders with the month and year is really a quibbling point, but some could argue that numbers in the URL (within reason) increase the speed of the on-site DB query for a visitor.

There are some of the finer points you can definitely fix, but I think this mainly boils down to:

1. Newer site
2. Lost links
3. Over-optimized Anchor Text (And lost over-optimized anchors text.)

And yes, the site should show me some casings before nearly the bottom of a 1920x1080 display.

Do the pages, inexplicably, get organic traffic? They don't appear to be indexed by Google. But it's a good idea to check your site analytics. Is there any way you can possibly add some content related to the iframes?

It appears that the pages iframe content about market trends and foreclosures. Could you possibly commission or produce some content that's 'evergreen' in regard to those markets and trends. That way, you may not have to update the content frequently.

So far my crawler has picked up 15 pages with iframe tags, out of 16,000 URLs. Granted, this isn't the whole picture - but I'm getting the impression it's not the bulk of your site.

It wouldn't take long to add a meta noindex tag to such a low percentage of pages. They aren't indexed anyway. Though I would noindex follow them. You never know... links and such from humans can flow into the site.

Though if you can add some content to those pages, it would be a very good idea to allow them to be indexed.

Alright. Good for my word like Colt 45. Here goes:

The site is definitely hacked. Viagra, Propecia, Cialis and Levitra  pointing to other hacked sites in the footer.  Pretty much every language in Western Europe was targeted. Nice, huh?

My scan yielded that the Advanced Custom Field plugin is outdated and vulnerable. ACF may not show up in your list of plugins. Some devs prefer to put ACF somewhere else and call it via functions.php. (All other plugins scanned appear to be up to date.) That will take a bit of detective work on your part. Also, they may have previously used a theme called Expose. It is vulnerable as well. If you aren't using it, get rid of it.

I would hazard a guess that they got in through the ACF plugin, however.

My scan, oddly enough, wouldn't render a list of users and administrators. It usually does. So I would double check and make sure everyone is there that needs to be there. They can hide themselves from the WordPress GUI, but I doubt they can hide themselves at the MySQL level. So be careful when checking that out. MySQL is unforgiving.

This is definitely going to be messy business. I hope you have backups, that are free from the XSS attack.

In the future, I like what this guy says about Wordpress Security. It will be your friend. But the cleanup will likely be difficult if you don't have any clean backups.

Further, since nothing exists in a vacuum, the site's link profile is less than enviable. Though I would start with the hack cleanup.

Hopefully this is helpful. I have a bleeding heart for small businesses.

PM me and and we can work out a way to send files your way. But I think everything should be apparent at this point.

I would look at your server log file to get a better idea of what's going on. Simply filtering the traffic in GA is basically sticking your head in the sand while what sounds like a DDoS or attempted hack is happening. So definitely have someone look into this deeper, rather than just filtering your data.

Considering IE7 is one of the oldest user agents imaginable, you could selectively block IE 7 user agent string at the server level. Though they could modify their user agent at a later date.

The only reason, that comes to mind, you wouldn't want to do this if your site is meant to target local/state governments. I've heard horror stories where one state required IE 5 Support, but that was some kind of ERP deal. Other than that, I haven't seen legit IE 7 traffic in years.

If your server is running Apache, you can give this a try. Also, it's possible you're using WordPress, so give WP Secure a glance. I would not advise that you do this on your own if you're unfamiliar with .htaccess and you can't push and pull from a test environment. It can knock the site down.

All in all, I'm sure there's a lot of things that can be done on-page. Though the main thing I'm seeing is that the server is pretty slow. I've managed to get response times from five to nine seconds. That's way too long and more than likely the main thing holding back the site.

Then there are a lot of requests on the home page, ~120. When you're dealing with a slow server, a lot of requests makes for a bad situation. It looks like the Facebook widget makes up about half of them. If you could find a lighter weight replacement, that would help. Plus you could enable server side compression.

Take a look at tools.pingdom.com and Google Page Speed Insights for a little more insight.

Basically, it looks like there's a lot of foundation work that needs to be done. Once that's done, you'll probably see some improvement. Then you can fuss over the paint/siding.

Full disclosure: I've been studying hreflang/rel=alternate for the glorious day when someone wants, and will pay for, a solid Spanish translation. That day has not come. But I wanted to be prepared. So here goes:

Your English pages are pointing the canonical at the French pages. No nationalized form of English is mentioned in the hfrelang alternate. If your English speaking audience is Canadian, put en-ca in the empty quotes after hreflang=. Example from /en:

rel="alternate" hreflang="" href="http://www.axialdev.com/en/" />

All of your canonicals point to the fr-ca version of the pages. For the en-ca pages, they should point to the en-ca pages.

I grew up in Michigan. I have quite a few Canadian friends. The only thing that's different about spoken Canadian English is the pronunciation of 'about' and they tend toward en-gb in spelling. But you should use en-ca anyway.

Yep, you have a lot of site-wide links. That is true. That may be part of the problem. But right now, you have a lot of non-google sanctioned duplicate content.

The site also has one of the most involved robots.txt pages I've seen in a month or so. It may not be a good idea to call any old user agent, *, and not give them a directive. Check the end of the file.

A site should not nose dive within the space of a couple weeks without extensive search engine manipulation, or serious on-page issues. Your site has been live for seven years. It's better to doubt on-page first though.

It's definitely an interesting question. I don't know why Screaming Frog doesn't do it yet. It sounds like an interesting feature request.

So, I looked into it a little further. I love Screaming Frog for it's ease of use, but I know it's not the only crawler out there. I came back with two things that should work. First there is Nutch. Second there is Tika. Of the two, it looks like Tika is better suited for your needs, out of the box.

I'll definitely play with Tika in the future.

The problem with figuring out the benefit of these minute changes is that there are thousands of other changes that have occurred. Many of them are out of our control. So while you were experimenting with separators, another webmaster might have made a change that made a competing page or pages decrease. And that's just one example.

It would make for an interesting outlying case if your site/pages were positioned just so that one weird, seemingly innocuous, tweak made the difference.

If you've seen the first film in the Star Trek reboot, you might remember how Scotty figured out his transporter problem. Well, actually Future Spock just gave it to him - since Future Scotty was going to fix the problem anyway. But upon looking at the calculations, Scotty realized that space itself was also moving. Which was why his previous experiments were a disaster.

What I'm saying is, aside from 'I'm a dork', is nothing exists in a vacuum. It's very hard to determine if a tiny change had a positive benefit. There are so many external factors/moving parts. Though it would help reduce uncertainty if you didn't change anything else.

So if the brand name is Super Cobblers and one of the locations is in Poughkeepsie, the anchor text would be 'Super Cobblers Poughkeepsie'? Seems pretty legit to me, without a concrete frame of reference.

When The Googles started busting down on site-wide footer links, I heard of quite a few 'City Website Design' took a beating. Though I don't know what else they were doing. It's pretty common for some webmasters to whine after a decisive action.

But you have to be careful about what you think is and isn't spammy. Until a few years ago a lot of people thought mass article and PR syndication, with a dose of free for all directories, was just fine. Their justification was; 'Because it works.' That's dangerous territory.

So, you could find yourself on the wrong side of an algorithm change - even though your intentions seemed good to you. Nothing is 100% safe or certain forever, especially in this line. But if everything else you're doing is definitely legit/above board, then you may well be okay for some time.

If you hear of some fairly definitive rumblings about your current practices, keep a nofollow version of your template(s) at the ready.

That would be Google Keyword Planner. You can bulk upload a bit more than what you need at the moment. You can also export the information. I haven't messed with a paid ad campaign recently, so something may have changed. But this article looks fairly accurate.

If that isn't floating your boat, you can also look into the SEM Rush API.

I would say more links and new/refreshed content would definitely have more to do with it than the presence or absence of a pipe.

With a pipe the title will be slightly longer. The example titles you gave seem on the long side, but nothing longer than most in that industry.

The Matt Cutts says The Googles treat 404 and 410 codes nearly the same. (Getting to the 301 candidates in a bit.)

If the pages are going to be gone for a long time, if not permanently, I would go ahead and serve 410 codes for those pages. 'A few' 404 results are okay. Though serving up thousands of 404 results doesn't sound like it's going to do the site any favors.

If a page has some 'good links', 'enough traffic'/'enough conversions' and a relevant/related 'good page' you're going to keep - 301 redirect to the 'good page'.

If you serve up thousands of 301 results, you're likely wasting crawl budget. The major bots only have so much bandwidth they're going to use crawling the site. So rather than having the 'good pages' and new pages frequently and thoroughly crawled, you could be inhibiting discovery/indexation. Considering we're talking thousands of redirects, and the site in question probably isn't Zappos, it's probably best to 410 the chaff/thin pages. Google bot will still come back to see if the pages are really gone, but at least you won't be wasting everyone's (Your time and Google bot's time) time in the near future.

There isn't really any hard and fast percentage for what's thin and what isn't. But I can say if you're looking at a page, and it just feels 'thin', you can supplement with other types of content. You can add videos, images, real original reviews - just to name a few possibilities.

At the end of the day, if it's not worth your time to do a page justice, why should search engines - or people for that matter - bother with the site? If five out of 10 people in your target market wouldn't find the page useful, or easily fulfill a need, it's probably best not to make the page at all.

I'm not really sure exactly what type of functionality they need, though Wrike could be adapted to a lot of use cases. Though for all of those project management goodies, there's kind of a steep learning curve in comparison to Basecamp. I've used Smartsheet, Basecamp and Wrike.

I didn't care for Smartsheet - something just seemed to be missing. Anyone can pick up Basecamp in about 10 minutes and run with it, but things can get lost in the simplicity. Wrike, again, has a steep learning curve in comparison and it's easy to get lost in the features. But Wrike is a PMs dream.

Wish I could help out with The In, but I don't know anyone in that business.

You may be better off just doing a pattern match if your CMS generates a lot of junk URLs. You could save yourself a lot of time and heartache with the following:

User-agent: *
Disallow: /*?

That will block everything with with a ? in the string. So yeah, use with caution - as always.

If you're quite certain you want to block access to the image sizes subdirectory you may use:

User-agent: *

Disallow: /sizes*/

More on all of that fun from Google and SEO Book.

Robots.txt is almost as unforgiving as .htaccess, especially once you start pattern matching. Make sure to test everything thoroughly before you push to a live environment. For serious. You have been warned.

Google WMT and Bing WMT also provide parameter handling tools. Once you tell Bing and/or Google that you want their bots to ignore urls with certain parameter(s) you select. So if you wanted to handle it that way, it looks like ignoring the app= parameter should do the trick for most of your expressed concerns.

Good luck! explosions in the distance XD

Hi David,

This isn't really the forum for hiring consultants. As stated, you can go with the recommended list from Moz. I would much rather discuss some of the issues in the forum, out in the open. It's more fun that way.

Just from looking at a couple of the 19 or so domain names registered throughout the years, the situation looks like a bit of a hot mess. Best of luck.

For starters, the robots.txt file is blocking all search engine bots. Secondly, I was just taking a look at the live site and I received a message that stated something like; "This IP has been blocked for today due to activity similar to bots." I had only visited two or three pages and the cached home page.

Suffice to say, you need to remove the User-agent: * Disallow: / directive from robots.txt and find a better way to handle potentially malicious bots. Otherwise, you're going to have a bad time.

My guess is the robots.txt file was pushed from dev to production and no one edited it. As for the IP blocking script, I'm Paul and that's between y'all. But either fix or remove it. You also don't necessarily want blank/useless robots.txt directives either. Only block those files and directories you need to block.

Best of luck.

Here's your current robots.txt entries:

User-agent: googlebot
Disallow:

User-agent: bingbot
Disallow:

User-agent: rogerbot
Disallow:

User-agent: sitelock
Disallow:

User-agent: Yahoo!
Disallow:

User-agent: msnbot
Disallow:

User-agent: Facebook
Disallow:

User-agent: hubspot
Disallow:

User-agent: metatagrobot
Disallow:

User-agent: *
Disallow: /

No worries, I'm not frustrated at all.

I usually take my first couple passes at a site in Chrome Incognito. I had sent a request via Screaming Frog. I didn't spoof the user agent, or set it to allow cookies. So that may have been 'suspicious' enough from one IP in a short amount of time. You can easily find the screaming frog user agent in your logs.

Every once in a while I'll manage to be incorrect about something I should have known. The robots.txt file isn't necessarily improperly configured. It's just not how I would have handled it. The googlebot, at least, would ignore the directive since there isn't any path specified. A bad bot doesn't necessarily obey robots.txt directives, so I would only disallow all user agents from the few files and directories I don't want crawled by legit bots. I would then block any bad bots at the server level.

But for some reason I had it in my head that robots.txt worked something like a filter, where the scary wildcard and slash trump previous instructions. So, I was wrong about that - and now I finally deserve my ice cream. How I went this long without knowing otherwise is beyond me. At least a couple productive things came out of it... which is why I'm here.

So while I'm totally screwing up, I figured I would ask when the page was first published/submitted to search engines. So, when did that happen?

Since I'm glutton for punishment, I also grabbed another IP and proceeded to spoof googlebot. Even though my crawler managed to scrape meta data from 60+ pages before the IP was blocked, it never managed to crawl the CSS or JavaScript. That's a little odd to me.

I also noticed some noindex meta tags, which isn't terrible, but could a noarchive directive have made it into the head of one or more pages? Just thought about that after the fact. Anyway, I think it's time to go back to sleep.

As Ryan touched on, it's always been a usability/accessibility concern. Since sites can get a little boost from other UI/UX concerns, it would stand to reason that alt text is still something to consider. As far as I know, it's never been the holy grail - but a nod to usability and/or accessibility can't hurt.

Alt text should be somewhat terse, though descriptive of the content. Otherwise, how can one justify the bandwidth alone?

Yes, the domain is propped up by pure spam. Have you reported it to The Googles? Venting on the forums may feel nice, but it doesn't get anything done.

Are you sure about that?