Welcome to the Q&A Forum

Unfortunately, these types of "pretend" business addresses are specifically against Google's ToS for Google My Business locations. It's pretty easy for them to detect and they'll nuke your location listing as a result.

If you consider this question from the search engine's point of view, you'll be able to answer this for yourself, vtmoz.You're essentially asking "can I manipulate incoming links to send authority where I want it to go, even if that means frustrating/deceiving someone who tries to use that link to find what they're looking for?"

When you think of it that way, the answer's pretty apparent. And in fact, Google has stated that when you try this, they just consider it a "soft 404" ( so a "not found" even though the resulting page might return a 200 found status code) and remove any authority value the link might have had.

So yes, the major risk is that you'll be throwing away the value of those incoming links, both for authority and for the actual visitor traffic that will be misled and likely bounce as a result.

The vastly better solution is to redirect those links to point where they belong, then use internal links from those strong pages to other related pages on the site to transfer the ranking authority around to other related pages. You should also make sure there is a strong call to action on the highly-linked pages so that you can lead new visitors to take other beneficial actions on the site.

Make sense?

Paul

Synonyms are different words that mean the same thing - like sneakers, trainers, running shoes.

Co-occurring words/phrases are words/phrases that typically get used in connection with specific words and help search engines better understand and differentiate between words that are spelled the same but have different meanings (called homonyms).

For example: a page contains the word "apple". Is that a page about a delicious, healthy fruit, or about a massive technology corporation? The search engines will look at additional words that occur around the word in question (co-occurrence) - like pick, sauce, peel, vitamins or phone, operating system, laptop, shares - to better understand which of the two meanings of the word "apple" the page is likely to be about.

In my opinion, the best way to insure both synonyms and co-occurring words are included in your content is to write thoroughly and naturally about the topic of the page. Natural writing seldom uses the exact same phrase over and over again - good writers are always looking for ways to vary the terms they use for the same thing to keep the writing interesting and engaging (hence synonyms). And thoroughly covering a topic means the co-occurring words will naturally be part of the content.

That's why it's so easy to detect content that has been artificially written to target a specific "keyword density" for example. An attempt to artificially use certain words for the search engines harms the enjoyment of the reader, which then harms the website. The furthest I usually go to insure use of synonyms is to use basic keyword research to find the more popular synonyms for a term and keep them in mind to improve the quality/variety of the writing where appropriate.

At a basic level, you can use something like thesaurus.com to look up synonyms of your term, then put those terms into Google Keyword Planner to assess the volume and value of those synonyms and to find more related terms. Many keyword research tools offer this capability too. The challenge is that many of the synonyms may not register in the volume/competition measurements, which might mislead you into thinking they shouldn't be used.

Hope that all makes sense?

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

I suspect your idea for 302ing to the temp new URL is probably the best you can do given the circumstances, Jeff. The alternative would be to leave the domain the same and have all pages return a 503 header with a Retry After header indicating a time span after the return to the normal site. But this is more invasive and probably more prone to errors. If the 302 redirect stays in place for too long, search indexers may start to consider it permanent despite the 302 status, but keeping it to one week likely shouldn't cause this.

My suggestion from a marketing perspective - I would make the temp site be something like www2.sitename.com instead of "new". This way, most visitors are unlikely to even notice. If they see the "new.sitename.com" site for a week, then are put back on what they now consider the "old" site - they may think they're getting shortchanged or something is wrong that they're no longer getting the "right" version of the site.

The other thing to make sure you've checked on - what other 3rd-party integrations/tools/advertising networks/analytics etc will need to be addressed while the redirect is in place? (For example, Adwords and many ad platforms don't look kindly on ads that redirect from their display URL to a new URL.) So make sure you've checked out and adjusted for any of those. Your SSL certificate and SMTP/site notification email sending functionality are other examples.

And yea, communication and setting expectations will be key here. If the devs truly can't accomplish what they need to any other way than such a major upheaval, everyone needs to be clear that all steps will be taken, there is a plan for the move, for the return, and for monitoring and trying to compensate afterwards (like maybe some extra PPC ready to go if a significant traffic drop will require recovery time?). But there are significant unknowns and while every effort will be made to minimise impact, things beyond your control will have possible negative effects and it's impossible to know in advance how severe they might be. You'll want a clear communication plan for all stakeholders of each of these steps in advance. You don't want to be trying to come up with the communications while in the middle of the process.

Sounds like an opportunity for an interesting case study - be sure to let us know how it goes. Good luck!

Paul

[Edited to add - verifying a new GSC property for the new subdomain(but not submitting any sitemap or fetch) would be a good idea. That would let you monitor whether any of the site was getting indexed. Then as soon as the site goes back to normal and the temp site is 301-redirected back, you could use it to declare a change of address back to the main site to help get any of the temp URLs out of the index faster, (assuming any get indexed) ]

Just to be clear here - you don't need access to the Apache webserver to manage proper redirects. As long as you have folder access to the website (FTP, command line etc) you can generate an htaccess file that will take care of it. (And not having this access means you basically have no real control of the website.)

P.

Doing redirects in JavaScript is definitely a "better than nothing" solution, rather than anything that should be recommended. It means placing your trust in something in that is supposed to work work, as opposed to something that definitely will.

I'd make sure there really was no way to do the redirects properly first, before falling back to the last-ditch solution.

Here's a test from a year ago that showed ranking authority was passing through JS redirects, but note all the caveats they include (especially that Bing didn't handle this at all at the time).
https://www.branded3.com/blog/seo-javascript-redirects-evidence-pass-pagerank/

Hope that helps?

Paul

I agree with Gaston's approach right up to step 4. If you add the no-indexed pages back into a block in the robots.txt file, you'll end up back where you started from. Because Google will still discover the no-indexed URLs elsewhere and the robots,txt block will stop them from discovering the no-index, and the URLs will likely start to get added to the index again.

No-indexed URLs must not be blocked in robots.txt. Those two processes are mutually exclusive.

How big is your store? By far the easiest way to manage this is to use  Shopify's WordPress plugin for inserting a Shopify store into a WordPress site. Here's a decent rundown of the pros/cons and process. Once in pace, you could use 301-redirects for any URL changes to shop URLs to transfer authority of old shop pages to new ones.

Would that method work for you?

Paul

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.

As long as the correct 301-redirect is in place, there's no SEO benefit to keeping the original page, as it can never be reached. That's the whole point of a 301-redirect.

For content management purposes, you might find it useful to keep the old posts around in draft form in case you want to use them as a basis for writing a new post/faq, but there's no reason to keep them available otherwise.

Hope that makes sense?

Paul

You've got some work to do, @ Dogara. It's essential to realise that just installing SEO plugins doesn't finish the job - they must also be carefully configured. And then the pages themselves must be optimised using the information the SEO plugin provides. Think of the plugin as a tool to make the optimisations easier, not one that will do all the work for you. Here's the task list I would tackle if I were you:

First things first - make certain you have a solid current backup of your website that you know how to recover if things should go sideways.

You currently have two competing SEO plugins active - definitely not recommended. You have both Squirrly and Yoast Premium. Since Squirrly doesn't appear to be configured at all, it should be removed. (This is assuming you haven't' done any customisation work with Squirrly - as it appears to me from a quick scan through your pages, But I didn't' do an exhaustive check, so if you've done customisations in this plugin, they may need to be exported, then imported into Yoast.)

Your Yoast Premium hasn't been updated in a full year - get it updated both for security and functionality. (And get all themes and other plugins updated too if they're behind - this is the biggest thing you can do for your website's security. Did I mention you need to have a solid backup first? )

Fix your page layout templates - they are duplicating the page title and featured image.

Set up configuration of Yoast settings, configure the defaults for page:

• Turn off the meta keywords functionality (no longer used)

• Decide what you wish to do with all your redundant archive types that are creating a huge amount of duplicate content and bloat. My recommendations:

• Since your site only appears to have one author, disable author archives.

• turn off date-based archives. You're not using them anywhere that I can see, and few people are likely to search by date on the site

• no-index the tag archives. These are straight-up massive duplicate content on your site as they are just lists of posts that are also listed elsewhere, like your categories.

• add a couple of paragraphs of quality introductory text on each of your category pages (needs WordPress customisation to do this depending on your theme - may be doable with a plugin.) The alternative to this is to no-index your categories as well, but for a site like yours, this probably isn't recommended, since those categories are used as your primary header navigation.

• NOTE! These recommendations are based on assumptions about how visitors use the site. If you have business reasons for keeping some of these archives, the decisions may be different!

• write solid custom meta descriptions for your categories (assuming you are going to keep them indexed.) Currently, it is these category pages having no meta descriptions that is giving you that high error total in the Moz crawl. Do note that when you fix the meta descriptions, you may start seeing a large number of "duplicate meta description" errors listed in a new Moz crawl. This is because you have a large number of paginated pages for each category, and each will have the same meta description as the main page. This is not an issue, even though Moz may flag it, since the pages have proper pagination code in place already (re-next and rel-prev in headers). Note that Google has just this week changed the number of characters allowed in meta descriptions to be much longer - tools may not have caught up to this change yet.)

• while you're editing the category meta description, take the opportunity to write better SEO page titles for each of them as well. They're edited in the same place as the meta descriptions in Yoast, so easy to do at the same time.

• get the template for your homepage adjusted to include proper rel-next and rel=prev meta tags in the header so that its pagination is handled properly.

• turn off JetPack's XML sitemap functionality and turn on the built-in sitemap tool in Yoast. You'll want to make certain only the appropriate sections of the site are in the sitemap (e.g. Any post types/taxonomies you've no-indexed, should be marked to exclude from the sitemap - like tags, author archives etc etc. You'll also need to resubmit a new sitemap address to your Google Search Console - make sure it's set up for the HTTPS address and submit the sitemap address https://hipmack.co/sitemap_index.xml

• the "URLs too long" warning is somewhat arbitrary, but make certain you are rewriting the URLs of your new posts when you create them if they are too long (more than 4 or 5 words) I wouldn't' bother going back to change the old ones at this stage.

• you are currently using an HTTPS Redirection plugin to manage the internal files of the site after your HTTPS migration. Would strongly recommend using a Search & Replace plugin for your database to properly rewrite these so you don't have a large number of internal redirects. Better for speed and more reliable.

• Moz will tell you which page titles are too long and you can go into Yoast for each related page/post and rewrite them. Note that Google will still index a "too long" title, it'll just lose the end of the title when displaying it on search results pages. (So, for example, if it's just the website name getting cut off at the end, it'snot a big deal. This is also a good time to optimise the meta description for those posts as that's done in the same spot as the title are edited.

Whew! And that's just the start, but if you get those things cleaned up, you'll be well on your way to cleaning up the technical SEO of your site.

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.

Most likely when someone wrote an internal link within the website. E.g. Linking to another page from within a page or blog post.

Nope - as long as the DNS resolves to the website properly, doesn't matter whether it's via A Record or Cname.

Many hosts are doing this now so that the DNS isn't dependent on the IP address in case the host needs to change that for emergency, security, or server change reasons.

Paul

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.

Something to consider regarding how you're measuring the traffic to the page...

Do you have tracking of actual interaction with the video in place? (e.g. Play click, length of video viewed, where they stop?) I ask because we need to remember - Google Analytics by default counts a bounce visit as zero seconds, regardless of how long the visitor actually stayed on the page. This is especially important for landing pages.

And what is the call to action on the page? Unless the CTA entails a second interactive hit to Google Analytics (like a second pageview), even successful page visits will be tracked as zero-second bounces.

All this is to mean - the time on page being so low doesn't necessarily mean the video isn't being watched. It might, but you need other tracking to know for sure. And you do need to know in case it's not a problem that the video isn't being watched, but instead the video is being watched but isn't persuasive enough.

Yea, this is a stupid screwup by Facebook because they won't fix their system to simply recognise the HTTP and HTTPS URLs are the same. (Others like Google+ got this figured out ages ago.)

Mentioning the HTTP URL for your OG data won't do any harm. It's the same as all the other websites out there with previous links still pointing to your old HTTP address. The 301-redirect and the hew HTTPS sitemap will give crawlers overwhelming directive of the correct URLs to index. (And in fact, the OG URL isn't even technically a link, so crawlers likely aren't even following it.)

As Martijn says though - you're kind of in limbo. The pages will show the old counts, but won't be aggregating the new counts. There are some plugins for WordPress that purport to be able to combine both, but I haven't used one yet.

Paul

If there are only a few of them, it's likely they were created by someone accidentally typo-ing a URL when writing a link.

If the changed page URL hasn't been up for very long, it would be well worth switching it back (as long as you also handle pointing the new URL back to the old one as well). Its always better to have incoming links land directly on a page instead of going through a redirect. While Google has said that 301-redirects no longer entail authority loss, I'm not entirely confident this is true in all cases. Much better to reduce the complexity. Even just for the fact that redirects add a small additional connecti0on to the load time.

Hope that helps?

Paul