Just FYI - the advice to remove query strings from static resources in that WordPress article is the proverbial Very Bad Idea. If you want a full explanation, let me know, but trust me - don't.

There's a world of difference between static files like CSS and Javascript having variables, and having those variables on page URLs.

You should have self-referential canonical tags on every page on your site anyway, which would take care of the duplicate URL issue created by the variables added to each URL, but there are still many other reasons why they're bad for SEO and usability, as Dana points out.

Paul

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

Nicely summarised, EGOL.

My bottom line? If you can't definitively prove you have license for the images, you can't use them.

And a business model based on "hoping' that the real rights owner won't hammer you into the ground for the infringement is the proverbial Very Bad Idea.

Paul

Added to note - you can also use GDC to inform Google which URL parameters should be ignored when indexing - can be a quick shortcut initially, but you'll definitely want to get rel-canonical properly implemented for Google as well as all the other search engines.

This issue is resolved by adding a single self-referential rel-canonical tag to the header of each page of the site, Catherine. Once you've done that, the URLs that contain the parameters will automatically contain the canonical to the primary URL (because the pages' code are actually the same - it's just the URL itself that is changing. By which I mean - there aren't separate pages for each of the currencies. They're are all the same page code, with just the parameter added to the URL and prices dynamically changed.)

This does mean that the search engines would index the page with the default prices, which appears to be Euros.

For example, if your home page had a self-referential canonical tag, it's canonical tag would be

<link rel="<a class="attribute-value">canonical</a>" href="<a class="attribute-value">http://www.marcb.com</a>" />

While this may seem redundant, it also means that this URL https://www.marcb.com/?setCurrencyId=2 would also contain the above canonical tag, since the page is actually built from the same code. So it's canonical would point to the correct URL automatically, without having to do anything specific for all those variations. This is a core function of how CMSs (Content Management Systems) templates work. This time it works in your favour.

You definitely don't want to no-index those parameter-based variations even if you could. Once you get the canonicals properly implemented, you want the search crawlers to keep crawling those pages URLs so they can discover the corrected canonicals and understand that they are intentional dupes of the core page. They'll eventually drop the parameter-based URLs out of the index, which you can monitor in your Google Search Console, for example. There's a major benefit to the site if the search crawlers aren't wasting their time on duplicate/useless pages, as well as reducing potential issues with Panda/Quality algorithms, so well worth getting this corrected right away.

Hope all that makes sense?

Paul

As I mention in my other comment, Sandi, no-following links doesn't preserve "SEO juice" at all. That hasn't been the case in many years.

And what Inbound is doing is completely different. They are No-Indexing entire pages that had so little content on them that they had no value, were wasting the site's crawl budget and looked like thin/duplicate content to the search engines. Nothing to do with the links on them at all. (This is actually a best practice for any site, but especially directory-type sites.)

P.

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

In the "old days" (yup, I go back that far), Google's search index crawler wasn't all that powerful. So it would ration itself on each page and simply quit trying to process all the content on the page after a certain number of links and certain character count. (That's also why it used to be VERY important that your content was close to the top of your page code, not buried at the bottom of the code).

The crawler has been beefed up to the point where this hasn't been a limiting factor per page for a long time, so the crawler will traverse pretty well any links you feed it. But I +1 both Andy and Mike's advice about considering the usability and link power dilution of having extensive numbers of links on a page. (This is especially important to consider for your site's primary pages, since one of their main jobs is to help flow their ranking authority down to important/valuable second-level pages.)

Paul

Really sorry to hear the new site is still struggling, Nicolas. In some quick indexing tests, it certainly appears that your blog posts are being indexed, and I'm seeing them in the search results for the specific post titles. [See screenshot attached] It's possible this may have picked up in the 10 days since you posted this.

I'm assuming you submitted your site's xml sitemap to the correct www version of your Google Search Console? What does the sitemaps report indicate as far as the number of pages indexed compared the number submitted?

Certainly one of the tradeoffs of a site tool like Squarespace is that you have far less control of the code to implement technical SEO, but it shouldn't be so problematic that you lose rankings completely.

If you're interested, I'd be happy to share a short Skype chat to try to narrow down the issues. You can send me a private message through my account here at Moz.

Paul

Why thank you! Did some of that info help you out as well?

p.

Yup, there are many ways to do it, but it's vastly superior (I'd say critical) in terms of ongoing ranking and traffic generation to keep the primary content on a consistent URL the main domain. It's also vastly better for user experience as well.

Ad EGOL recommends, definitely keep the URL on your own site consistent from year to year. Create the archives of each year's highlights as children of the primary page, and make sure you are linking to the current year's page from each of the year-archive pages. This give Search Engines a clear understanding of the relative hierarchy and currency of the pages.

Do NOT 302 this page to the registration page. Simply add a call-to-action on the primary page to the registration page. You must have lots of good conference-related content on the primary page, not just a thin paragraph and a link to the reg page. You'll then want - if at all possible - to have the reg page (especially after successful registration) to redirect the visitor back to the primary page to give the followup info after registration.

Ideally, you'll want to be able to insert your Analytics tracking code on the reg site as well, and then configure cross-domain tracking for it. That way you can easily track conversions. At the very least, if you can't set up your own Analytics on the reg page, add a referral exclusion for it so the visitor coming back from the reg page doesn't show as a new visit on the primary page. You can then add conversion tracking to that return page.

These recommendations come from a background managing sites running up to 425 events per year, often with ticketing handled on a third-party site.

Hope that all makes sense?

Paul

Most welcome - happy to see another Canuck hereabouts My mom's just down the road from you in Arnprior.

If you were able to get the initial broken links review corrected within two weeks, that's great - not much of the authority should have dissipated.

However to note - the 404s in Search Console aren't the only ones that need to be fixed - they're just the ones Google has noticed and alerted you to so far. The problem with relying on GSC to tell you what to fix is that, by the time it has shown up in the Console, Google has already hit a 404 and been told it's a missing page. It's totally reactive, instead of proactive.

I'd strongly recommend you also use the other methods I mentioned to get more of the old URLs found & redirected as well before Google notices they're borked. It's also ideal if you can try to get the owners of the most valuable sites that linked to you in the past to update their links to point directly to the new pages. It's a bit of a battle, but even just a few updated can make a difference.

As far as how long until "link juice starts flowing" by which I assume you mean "rankings and traffic start to return" - the only real answer is "it depends", I'm afraid. You'll want to submit your new sitemap to GSC so that you can track the progress of the indexing of your new site's pages (on Squarespace, the URL to submit is www.kanataskinclinic.ca/sitemap.xml). You should also do this for Bing's Webmaster Tools.

Since URLs and content have changed, it's going to take some time for your site to fully re-index and for Google to understand the value of the new content. Could be from a few weeks to a month. It would also help to submit a few of the main section pages using the Fetch as Google tool in GSC and to get some new, strong incoming links to the site's pages. Good social links, and at least one or two new ones from relevant sites.

Lemme know if you have further ??s

Paul

And just to add - there is a shelf life on recovering all that page and link equity. The longer those old URLs 404, the more of the power of the old pages will erode away.

Two month is a long time - don't dally on getting those redirects started immediately.

P.

Regardless of the possible issues with the new design, yes, if you changed to new URLs on the new site and didn't implement correct 301-redirects from all the old URLs, you have essentially thrown away all the ranking authority and inbound links contributed by all of your old pages except the home page.

Since most homepages only rank for a small portion of the total number of terms for an established website, that's the primary cause of your immediate problem.

To fix it, you have some hard work ahead of you to capture as many of the old URLs as possible and write redirects to the new URLs. These old pages can be captured in a number of ways. The easiest initial method is to look up all the 404 errors in you Google Search Console, sort them by date, then start fixing all the ones after the date of the site change.

You can also use your Analytics data - create a report of all the page URLs of your site that received traffic in the year before the change, then sort them by highest traffic to prioritise where to start creating rewrites. You can also capture the current 404 errors in your Analytics data for high-priority pages to get redirected.

For a final more high tech solution, you can use Screaming Frog SEO Crawler to crawl the archive.org WayBack Machine version of your site to capture as many old URLs as possible.

Hope all that makes sense?

Paul

Removing them from the Console will have no effect on your  site, Ruben - its' purely for your own housekeeping purposes.

Mark them fixed to get them out of the lists so that real ones will be easier to spot as they come up. As long as the spam links are landing on a real hard 404, they will eventually drop out. But it will take a considerably long time because those spam pages are such low value that Google isn't likely to recrawl them to discover the 404 very often. (Not that that will do you any harm, just annoying to look at.)

Also - don't be alarmed if some of those you mark "fixed" show up back in the list in a couple of months - that's not indicative of any problem.

Hope that helps?

Paul

In order to accomplish your goal, setup Yoast SEO to:

1. redirect attachment URLs to parent post
2. exclude attachment URLs from sitemap (it's a checkbox under the Post Types tab in the XML Sitemaps section of Yoast SEO Settings)
3. leave all media indexed and followed.
4. When adding media, make certain the Link to box does NOT point to the attachment page.

What this accomplished is to allow the actual image file to still be indexed and hence show up in Image search. It also ensures that the pointless image attachment pages don't waste crawl budget and don't show up to the search crawlers as thin/dupe content. Win!

Hope that helps?

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.

Regarding the speed issue, a single rewrite rule using regex with a wildcard could handle redirecting all of those old event URLs to the new event calendar directory, as it appears you wish to do. Saves a huge amount of work and cuts way down on the 301 redirects that have be parsed on each page load.

Paul