Welcome to the Q&A Forum

Unfortunately, it doesn't work that way, Alex. Unless the server returns an actual 404 response code in the header, search engines will not consider the page to be an error to be removed from their index. Even though the content of the page may look like an error page, the http response in the header is the only thing that determines whether the engines will treat it as a 404 error.

Paul

The base domain URL is a special case, @advertisingcloud. Whether it ends in a slash or not doesn't matter. Both versions are functionally equivalent to each other and will not create duplicate content (in fact, it's not possible to redirect one version to the other - you'll get a redirect loop.)

Consistency is always best, so I always use the full version with the slash (for other technical reasons). But it really does't matter if you mix them, which is why you'll see such varied usage on the web.

Hope that helps?

Paul

Fully agree with Alan - subdomains would be a major waste of effort and SEO value.

Are you thinking you want subdomains perhaps so you can track them differently? There are many ways to do the necessary tracking with pages in subdirectories of the main site, so it's not necessary to use subdomains for this reason either.

Unless there's something missing in what you need here, integrating the landing pages into the main site is the vastly superior solution here.

Can you give us an idea what it is about subdomains that you feel you need?

Paul

Image h x w attributes don't affect the actual speed of your page load much, Dan. They do strongly affect the perceived speed to the user.

If the size attributes are included, the browser can leave a correctly-sized space for each image as the page gets rendered, even if the images haven't started to download yet. Then the rest of the page content flows in around the image "placeholders". (Images are always slower than text.)

If no image size attributes are present, the browser essentially ignores the placing of the images until the image files actually download, then redraws the whole page to add the space back in for the images.

This redrawing for the images means that text and other elements will move around on the page until all the images have downloaded and it has finished rendering. This gives the user an impression of a much slower page, since they can't start to read the content until it has stopped moving around. Done properly, the visitor can start reading the top of the page even while all the images lower on the page are still downloading.

So yes, obviously including height and width attributes for images is standard best practice for designing an effective on-page user experience.

Hope that helps?

Paul

P.S. As proof, Google thinks they're such a standard requirement that they have included a check for them as part of the scoring algorithm of their Google Page Speed tool.

It's not that they don't have the same weight - they have no weight, Stephen. Don't waste your time on them.

(In fact, you'll just be making it even easier for your competition to grab lists of the keywords you're targeting.)

Paul

There is also a Fetch as BingBot tool in Bing's Webmaster Tools which will confirm Bing's crawler can also index your page. Too many people forget about Bing, but it's often the source of 30% of a site's organic visits, so not a good thing to ignore.

Paul

Yup - afraid you've been taken advantage of (or the developer somehow invoiced the wrong project?) Embedding YouTube videos is essentially just like adding photos. A few minutes copy-paste at most.

Paul

There's nothing wrong with it, Cat, but it's actually what's called a sitemap index. Its job is to contain a list of the specific sitemaps for different sections of the website. The search engines crawl that index, which then points them to where each of the individual sitemaps is located, which they then crawl from there.

This is actually a preferred method for handling large sitemaps and ideally for breaking out the site into subsections so you can better monitor how well the crawlers are dealing with the different sections.

You only need to submit the sitemap index to Google Search Console and Bing Webmaster Tools. You'll see once it's been processed that you can click on the sitemap index link and it will load a page showing the status of all the sub-sitemaps automatically.

That make sense?

Paul

The biggest point here to me, Alex, relates to your last sentence. There is absolutely no reason to ever have a 5 MB on a website in the first place unless you are expressly providing high-rez images for printing.

The downsides are so many that they actually dwarf the SEO implications

• most importantly, they make for massive backup files, which become unwieldy and prone to timeout failures when being generated or restored.
• you run the significant risk of unauthorised use of the images, since they are big enough to print from.
• you waste bandwidth and resources uploading such large files, and displaying them should users click on them
• you create a horrible user experience should any user accidentally click on them, especially if they're unfortunate enough to be on mobile.

As far as SEO goes, I honestly don't know the effect of such large images on crawlability. We know Google does process images (to power things like reverse image search) but I strongly suspect they would just skip that for such large images. They are predominant;y using meta-data and any captions/associated text for image indexing purposes.

As far as link equity - yup, those links to the larger image will take link equity with them just like any other link on the page. In addition, depending on the CMS configuration, those links may be going to attachment pages holding the images. (WordPress is famous for this problem by default.) They will look to the search crawlers like additional pages to be indexed, but since they're just images, they can look like thin content, and also are a major waste of crawl budget.

If this is a WordPress site, there are a number of plugins that can deal with the over-sized images in an automated way. Otherwise you can pull them down into Photoshop and use its automated batch processing to deal with them, then re-upload them.

Hope that helps?

Paul

Yup - agree with Jesse - no functional difference.

Stylistically I always write my anchor tags with the URL first, then any attributes afterward. Just much easy to read and check when reviewing code. But browsers don't care.

Paul

Answered a similar question a couple of weeks ago, Tom.
https://moz.com/community/q/can-we-add-header-tags-followed-by-header-tags-without-text-in-between-best-practice

Bottom line is that header tags are semantically designed to introduce the following section of content. If the following content is more headers, it breaks this semantic paradigm. Not a critical disaster, but not best practice either.

That help?

Paul

Essentially, you are buying an ad for your site. If it makes sense to buy that "ad" in order to drive qualified traffic to your site, then it's perfectly fine and worthwhile. (And you should add tracking parameters to the links so you can track the actual value in Google Analytics of the visitors the "ad" is driving to your site to decide if you're getting your money's worth.)

But! If you do buy such an "ad", you MUST require the site selling it to you to include the rel=nofollow attribute on all the links that point to your site. This is the clear requirement from Google to keep you from being penalised for manipulative linking practices. (i.e. There is a commercial relationship between the two sites so the link MUST be no-followed). And yes, Google will pick up on it.

Hope that helps?

Paul

Any chance there's been a custom crawl setting accidentally added to your Google Webmaster Tools, Robert? Some devs do this during development or it can happen accidentally.

Also, your sitmemap takes a ridiculously long time to load - well over 15 seconds for me and over 18 seconds using webpagetest.org. It could be that Google simply isn't waiting for the page to load when it tries to visit. If the sitemap's being generated dynamically, you may have a rendering problem. Otherwise there's something borked when a 50kb file takes that long.

Might also want to try submitting it through Bing Webmaster Tools and see if they are better able to index it consistently for comparison?

Bit of a head-scratcher. Hope that gives you a starting point.

Paul

You'll probably find Xenu Link Sleuth will work for this, Red. Not quite as elegant as using an extraction in Screaming Frog, but it is free.

Lemme know if that works?

Paul

The one thing you haven't mentioned, which is likely to be most critical for this issue, is your XML sitemap. I couldn't find it at any of the standard URLs (/sitemap.xml and /sitemap_index.xml both lead to generic 404 pages). Also, there's no directive to the sitemap in your robots.txt.

Given that the sitemap.xml is the clearest and fastest way for you to help Google to discover new content, I'd strongly recommend you get a clean, dynamically updated sitemap.xml implemented for the site, submit it through both Google and Bing webmaster tools, and place the proper pointer to it in your robots.txt file.

Once it's been submitted to the webmaster tools, you'll be able to see exactly how frequently its being discovered/crawled.

Hope that helps?

Paul

I've confirmed with my senior source at SiteGround that you absolutely can upgrade directly to a Pro account with a dedicated IP all at the same time. Just order your IP address at the same time as you order your account upgrade.

If you have any further issue with this, just message me the contact you're dealing with at SiteGround and I'll have "my guy" help straighten it out.

Good luck!

Paul

Agree with Stephan - the dupe H1s, while not ideal, are not going to be a significant SEO issue.

But what will be the issue is the extra page bloat and therefore load speed of all those pages. Not necessarily for SEO, but most certainly for usability. There are much more efficient ways to get your pages to scale for different devices than to run three sets of headers.

Paul

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

The presence or absence of a new/old Analytics account associated with a site will have no effect on its indexing, one way or the other, Johann.

What do you mean when you say the old site was "blacklisted"? Do you mean it had a manual penalty applied? (As would be specified in Google Webmaster Tools). Or do you mean the domain had been marked as unsafe due to malware? Or that the domain's email servers were blacklisted?

To me, (without knowing the details of the "blacklisting") if the site is being crawled but not indexed, it sounds like there may be a noindex metarobots tag or header, or some other blocking issue. Hard to give much more info unless you can give us the site's URL.

Can you fill us in on what you mean by "blacklisted"?

Paul

Absolutely do NOT change from the www just for the sake of saving four characters in the URL. It would mean that every single page on your site would now have to go through a 301-redirect.

You should only change URLs when absolutely necessary, and the reasoning for this change certainly doesn't qualify!

Also worth noting - a www URL has more technical flexibility. Those reasons may not apply to you now but could in the future.

Paul