Welcome to the Q&A Forum

What is the best way to manage multiple locations for multiple clients on Foursquare via Moz Local?

If anyone can suggest best practices around whether multiple brand management allowed and if each client should get their own Foursquare account, etc - that would be very helpful.

A few things:

• One way to aid you in ensuring search engines can actually properly index your angular website would be to use a service such as  https://prerender.io/ - like many have before you.
• Another good resource with some examples of the roadblocks you might face: https://builtvisible.com/javascript-framework-seo/ - this will also outline some recommendations of how to tackle these issues.
• Compared to the typical HTML site, it will certainly be far more difficult. It will be doable, as long as one thing is done: test, test......and test.

I would check your robots.txt to ensure the entire site isn't being blocked. This is a common mistake with site redesigns or migrations. If you see the following rule, remove it promptly:

• user-agent:*
• disallow: /

If all your other traffic sources are showing (which would verify there's no problems with the analytics tag), it certainly looks like a case of a rogue sitewide noindex meta tag or general robots.txt issue.

Wendy,

Google likes to have access to all your css and js. Plugins can contain these files, as seen with your blocked resources message.

The way to fix this would be by removing the Disallow: /wp-content/plugins/ line from your robots.txt file, and thus allowing google full access.

Another solution as provided by a useful article on moz: https://moz.com/blog/why-all-seos-should-unblock-js-css 

"How to unblock your JavaScript and CSS

For most users, it's just a case of checking the robots.txt and ensuring you're allowing all JavaScript and CSS files to be crawled. For Yoast SEO users, you can edit your robots.txt file directly in the admin area of Wordpress.

Gary Illyes from Google also shared some detailed robots.txt changes on Stack Overflow. You can add these directives to your robots.txt file in order to allow Googlebot to crawl all Javascript and CSS.

To be doubly sure you're unblocking all JavaScript and CSS, you can add the following to your robots.txt file, provided you don't have any directories being blocked in it already:

User-Agent: Googlebot

Allow: .js

Allow: .css

If you have a more specialized robots.txt file, where you're blocking entire directories, it can be a bit more complicated.

In these cases, you also need to allow the .js and.css for each of the directories you have blocked.

For example:

User-Agent: Googlebot

Disallow: /deep/

Allow: /deep/*.js

Allow: /deep/*.css

Repeat this for each directory you are blocking in robots.txt."

Hope this helps.

The issue is that you still have the meta tag name='robots' content='noindex,follow' /> on your pages.

Now that search engines can crawl your site, they are able to pick up on this tag, and thus will not index your pages. Once you remove that tag, it should be indexed, especially upon requesting indexation through search console.

Implementing a rel canonical for a paginated series to a "view all" is certainly recommended practice from a technical standpoint.

With that said, this should be implemented as the recommended course if it enhances user experience. If it takes too long to load, and users abandon the page all together, it helps no one. I would certainly do speed tests, and check the usability of it.

• If it takes longer than a few seconds, I would certainly recommend checking to see if there are ways to speed it up.
• If this proves to be difficult, there is certainly room to consider implementing a paginated series that is more manageable and contains rel=prev and rel=next tags to ensure search engines are aware these pages are a related series.

Monica,

Sounds like you guys have taken the necessary steps to clean up the website and prevent it from occurring again. 404 spam links are a pain, that can often take some time to be removed from google's index all-together.

• A way to speed up the process is by changing the 404 status of these pages, and having it return a "410" error instead. This tells google it is a permanent non-existent page, and thus it will fall out of the index more quickly than a regular 404.
• In the meantime, if the number of 404 errors aren't overwhelming, you could try the "remove urls" tool within search console for these pages, which will temporarily remove them from the index all together. (emphasis on temporary)
• Marking them as fixed wouldn't be helpful, as the errors still exist, and would return to your search console not long after. (it certainly wouldn't harm your SEO, it just wouldn't be very helpful in this specific instance).

Hope that helps.

I definitely don't think there's any truth to your site possibly being penalized merely for changing a certain percentage of the site.

However:

• In general, it's always good to change your site in slow increments wherever possible.
• This allows search engine's to slowly adjust to your changes in url structure, content, or site design. Your site wouldn't be "penalized" for it, but considering search engine's have to recrawl your site and adjust to your changes, making sure you don't shock the system by making too many changes is certainly never a bad idea.

This is an issue an increasing amount of people are having. To anwer your questions:

• This spam does not hurt your SEO. Most of these are "ghost referrals", meaning they don't actually hit your server, but only show up in analytics. It will not influence how well you will do in search engines, it's merely a pain in the behind when trying to accurately track incoming traffic to your site.
• I'd recommend filtering them out within google analytics via hostname instead.
• Refer to this great moz post regarding this very issue to ensure your issue is taken care of: https://moz.com/blog/stop-ghost-spam-in-google-analytics-with-one-filter

In general, I definitely wouldn't recommend the way the web-provider is handling this.

• Disallowing all while adding exceptions should never be the norm. Allowing all to crawl while adding exceptions for other crawlers aside from google would be best practice generally,
  • It makes a lot more sense to just allow crawlers full access, and then add crawl delays for non google crawlers, in addition to disallowing those specific sub-folders:  Disallow: /new_vehicle_detail.asp Disallow: /new_vehicle_compare.asp Disallow: /news_article.asp Disallow: /new_model_detail_print.asp Disallow: /used_bikes/ Disallow: /default.asp?page=xCompareModels Disallow: /fiche_section_detail.asp.
• Googlebot Disallow: Crawl-delay: 5, does not do you any good, as google does not obey these commands. Only Search Console can control this.
• You can test what is visible to googlebot within search console's "robots" subsection, in order to verify what they can access.

I definitely don't think there's any truth to your site possibly being penalized merely for changing a certain percentage of the site.

However:

• In general, it's always good to change your site in slow increments wherever possible.
• This allows search engine's to slowly adjust to your changes in url structure, content, or site design. Your site wouldn't be "penalized" for it, but considering search engine's have to recrawl your site and adjust to your changes, making sure you don't shock the system by making too many changes is certainly never a bad idea.

The issue is that you still have the meta tag name='robots' content='noindex,follow' /> on your pages.

Now that search engines can crawl your site, they are able to pick up on this tag, and thus will not index your pages. Once you remove that tag, it should be indexed, especially upon requesting indexation through search console.

A couple of things to note:

• As Robert mentioned, I would definitely make sure there is no longer an issue on your wordpress site relating to your previous hack.
• Robots.txt disallow does not stop pages from being indexed. It merely tells search engines to stop crawling that page from here out. The meta noindex tag is more applicable for noindexing pages that are already out there.
• I would check your search console crawl errors to see if there's a hefty spike in 404 errors as well, as it may be old spam pages you removed from the site.
• If these pages that are bloating your index are all still old spam filled pages from when you were hacked, you could start by using the search console's "remove url's" tool, which will remove all these url's from the index temporarily. For a more long term approach, instead of them giving off a 404 if they have been removed, making the server give off a "410" response would tell google they are gone forever, and thus they will be removed from the index as time goes on.

Wendy,

Google likes to have access to all your css and js. Plugins can contain these files, as seen with your blocked resources message.

The way to fix this would be by removing the Disallow: /wp-content/plugins/ line from your robots.txt file, and thus allowing google full access.

Another solution as provided by a useful article on moz: https://moz.com/blog/why-all-seos-should-unblock-js-css 

"How to unblock your JavaScript and CSS

For most users, it's just a case of checking the robots.txt and ensuring you're allowing all JavaScript and CSS files to be crawled. For Yoast SEO users, you can edit your robots.txt file directly in the admin area of Wordpress.

Gary Illyes from Google also shared some detailed robots.txt changes on Stack Overflow. You can add these directives to your robots.txt file in order to allow Googlebot to crawl all Javascript and CSS.

To be doubly sure you're unblocking all JavaScript and CSS, you can add the following to your robots.txt file, provided you don't have any directories being blocked in it already:

User-Agent: Googlebot

Allow: .js

Allow: .css

If you have a more specialized robots.txt file, where you're blocking entire directories, it can be a bit more complicated.

In these cases, you also need to allow the .js and.css for each of the directories you have blocked.

For example:

User-Agent: Googlebot

Disallow: /deep/

Allow: /deep/*.js

Allow: /deep/*.css

Repeat this for each directory you are blocking in robots.txt."

Hope this helps.

Monica,

Sounds like you guys have taken the necessary steps to clean up the website and prevent it from occurring again. 404 spam links are a pain, that can often take some time to be removed from google's index all-together.

• A way to speed up the process is by changing the 404 status of these pages, and having it return a "410" error instead. This tells google it is a permanent non-existent page, and thus it will fall out of the index more quickly than a regular 404.
• In the meantime, if the number of 404 errors aren't overwhelming, you could try the "remove urls" tool within search console for these pages, which will temporarily remove them from the index all together. (emphasis on temporary)
• Marking them as fixed wouldn't be helpful, as the errors still exist, and would return to your search console not long after. (it certainly wouldn't harm your SEO, it just wouldn't be very helpful in this specific instance).

Hope that helps.

This is an issue an increasing amount of people are having. To anwer your questions:

• This spam does not hurt your SEO. Most of these are "ghost referrals", meaning they don't actually hit your server, but only show up in analytics. It will not influence how well you will do in search engines, it's merely a pain in the behind when trying to accurately track incoming traffic to your site.
• I'd recommend filtering them out within google analytics via hostname instead.
• Refer to this great moz post regarding this very issue to ensure your issue is taken care of: https://moz.com/blog/stop-ghost-spam-in-google-analytics-with-one-filter

Implementing a rel canonical for a paginated series to a "view all" is certainly recommended practice from a technical standpoint.

With that said, this should be implemented as the recommended course if it enhances user experience. If it takes too long to load, and users abandon the page all together, it helps no one. I would certainly do speed tests, and check the usability of it.

• If it takes longer than a few seconds, I would certainly recommend checking to see if there are ways to speed it up.
• If this proves to be difficult, there is certainly room to consider implementing a paginated series that is more manageable and contains rel=prev and rel=next tags to ensure search engines are aware these pages are a related series.

A few things:

• One way to aid you in ensuring search engines can actually properly index your angular website would be to use a service such as  https://prerender.io/ - like many have before you.
• Another good resource with some examples of the roadblocks you might face: https://builtvisible.com/javascript-framework-seo/ - this will also outline some recommendations of how to tackle these issues.
• Compared to the typical HTML site, it will certainly be far more difficult. It will be doable, as long as one thing is done: test, test......and test.

In general, you want unique content for your products to be able to give the best experience, and rank well for your desired keywords and products.

You won't be penalized for this duplicate content, but it will likely cause you not to be ranked as well as you could be. If other sites have the exact same product descriptions as you do, why would google choose to rank you above others ?

I'd definitely recommend going with unique content here, or adding elements to the page that are inherently unique to your site, to start out with.

I would check your robots.txt to ensure the entire site isn't being blocked. This is a common mistake with site redesigns or migrations. If you see the following rule, remove it promptly:

• user-agent:*
• disallow: /

If all your other traffic sources are showing (which would verify there's no problems with the analytics tag), it certainly looks like a case of a rogue sitewide noindex meta tag or general robots.txt issue.