You absolutely do NOT want to redirect these links to the home page, Ian! These are spam links, coming from completely unrelated sites. They are Google's very definition of unnatural links and 301-redirecting them to your home page also redirects their potential damage to your home page.

You want them to return 404 status as quickly as possible. I'd also be tempted to use the Webmaster Tools remove tool to try to speed up the process, especially if these junk links currently form a large percentage of your overall link profile. (You'll need to find & remove the redirect that currently re-points them to the home page too, for the 404 header to do it's job of telling the search engines to drop the page from their indexes.)

As far as rankings issues, this isn't a potential dupe content issue, it's a damaging unnatural links issue, which is even more significant. These are the kinds of links that could lead to at least algorithmic penalty, or worst case, manual penalty. Either way, these penalties are vastly harder to fix after the fact than to avoid them in the first place.

In addition to the steps above designed to make it clear those links don't belong to your site, I'd keep a good record of the links, their originating domains, and when & how they were originally created due to the malware attack and your fix. That way you have essential documentation should you receive a penalty and need to submit a reinclusion request.

Hope that answers your questions?

Paul

The reason the site "looks" to tools like it takes a long time to load is because the Google+ API call and the Facebook Connect call are taking an obscenely long time to negotiate their SSL connections - over 11 seconds.

Fortunately the essential user-visible parts of the page (up to document complete) load quickly so the user experience is fine. Might be worth trying to figure out why the SSL negotiation on those 2 files is getting killed so badly though.

Here's a link to the page load Waterfall View that clearly shows the long purple lines indicating SSL delay for those 2 scripts.

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

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

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.

ASs joe says - set up a separate GSC profile for the mdot subdomain. The use that to submit the mdot sitemap directly if you wish. You'll get vastly better data about the performance of the mdot site by having it split out, instead of mixed into and obfuscated by the desktop data.

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

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

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

Good Choice. The XML Sitemap spec has specific maximum sizes for individual sitemaps, but they are specified sizes before compression, so compression doesn't get you around the size limitations anyway 

P.

Yup - you have to use the actual URL of the sitemap for submission. The search engines will handle it fine - as you can confirm by watching in GSC and Bing Webmaster Tools that it's getting processed.

Paul

P.S. There's really no particular benefit to using a compressed sitemap anymore.

Not really correct, unfortunately. As long as the 301 redirect has been written properly (it should be at the system level, not written into individual page code like a JavaScript redirect) then any request to the server for the page will be redirected before the old page can be reached. That's the express purpose of a 301-redirect.

So anyone clicking on an external link to the old URL (or a search crawler following it) will immediately be redirected to the new page as soon as they hit the server, whether the old page still exists or not.

This is the kind of question that cause a lot of wasted tail-chasing if we can't inspect the affected URL, Nadav. Can you give us a link to the site in question?

Paul