Welcome to the Q&A Forum

For Wordpress, it depends if you have it set to filter out script tags from content. So, if you toggle content editing mode to html, and put in a script tag, whether it allows this or not. That is a setting in Wordpress. If it is filtering out your script tags, and if you don't want to (or can't) disable the script tag filtering, then using a plugin to administer the schema markup would be your best bet. There are generic plugins to insert script tags. And there are more specific plugins for schema markup, like Yoast (and others).

If you are inserting the scripts through GTM, then you may not see them when you simply "view source".  With tag managers, you will see their container in the source code, but not the injected scripts. But if you instead use Chrome Developer Tools (right click and choose "inspect"), on the elements tab you will most likely find the injected scripts.

In answer to your questions:

1. You can place the JSON-LD in either location. If you are making use of data which may not be available at the beginning of the page load, then you might prefer to place at the very bottom of your body tag. But both locations work if you are simply inserting static content.

2. If you are using a CMS, you can simply insert the script as static content (as long as your CMS allows you to insert a script). This is assuming your page is a static page, not one which dynamically changes based on some server-side application. So, for example, if you have an article page on your site, and you want to insert schema to mark up that article, then this would be straightforward to do by simply inserting a script. But if your site is an e-commerce site and you are wanting to mark up all of your product details pages with product information, then this might be better done as part of the application. For static markup, if you search for "json ld generator" you will find some handy tools to simplify creating static scripts. Just be careful that you do not use static markup on a dynamic page where the page content might change based on application data, then causing inconsistency between your markup and the actual page content.

3. If you insert through your CMS, then yes you should see your script in the source code. If you use an ansynchronous script to inject your JSON-LD, then you might not see it in your source code, but could still see it by using dev tools inspect, after the page finishes loading. Either way, then use the Google Structured Data Testing Tool on the live URL to confirm that Google is able to parse the markup properly, with no errors. When you do that, look at its results to make sure the hierarchy of the data looks appropriate to you based on the data you know is on the page.

From my own experience, yes. In a previous position, I did exactly that, specifically for a blog, using Akamai as the technical solution for the reverse proxy. I used the reverse proxy only because the e-commerce web site was hosted by a provider who would not also host a Wordpress site on their servers. So, I had to host the Wordpress site on another provider, and used a reverse-proxy to make it accessible as a directory beneath our normal subdomain.

The only difference was that I used the reverse proxy to "move" it from a "blog" subdomain of the root domain, to the "www" subdomain. So, like from blog.example.com to www.example.com/blog/.

And yes, after moving it, I can say that we did see some ranking benefits. As well, from every indication I could observe, it looked the the world (including search engines) like it was actually hosted on www.example.com. IP address lookups, and other efforts to try to see if it was on its own subdomain no longer turned up any indications.

So, I can't say with 100% certainty that the search engines can't somehow detect through the reverse proxy that it is really on another host, but I'm pretty confident.

Bryan,

If I understand your intent, you want your pages indexed. I see that your site has 5 pages indexed (/, /help, /influencers, /wholesale, /co-brand). And that you have some other pages (e.g. /donations), which are not indexed, but these have "noindex" tags explicitly in their HEAD sections.

Not having a robots.txt file is equal to having a robots.txt file with a directive to allow crawling of all pages. This is per http://www.robotstxt.org/orig.html, where they say "The presence of an empty "/robots.txt" file has no explicit associated semantics, it will be treated as if it was not present, i.e. all robots will consider themselves welcome."

So, if you have no robots.txt file, the search engine will feel free to crawl everything it discovers, and then whether or not it indexes those pages will be guided by presence or absence of NOINDEX tags in your HEAD sections. From a quick browse of your site and its indexed pages, this seems to be working properly.

Note that I'm referencing a distinction between "crawling" and "indexing".  The robots.txt file provides directives for crawling (i.e. access discovered pages, and discovering pages linked to those). Whereas the meta robots tags in the head provide directives for indexing (i.e. including the discovered pages in search index and displaying those as results to searchers). And in this context, absence of a robots.txt file simply allows the search engine to crawl all of your content, discover all linked pages, and then rely on meta robots directives in those pages for any guidance on whether or not to index those pages it finds.

As for a sitemap, while they are helpful for monitoring indexation, and also provide help to search engines to discover all desired pages, in your case it doesn't look especially necessary. Again, I only took a quick look, but it seems you have your key pages all linked from your home page, and you have meta directives in pages you wish to keep out of the index. And you have a very small number of pages. So, it looks like you are meeting your crawl and indexation desires.

Yes, your understanding of x-default is correct. The purpose of including it everywhere you have alternate HREFLANG links, is to handle any locales you don't explicitly include (to tell the search engine which is the default version of the page for other non-specified locales). And it should be included on each version of the page, along with the other specified alternate links for each locale. Alternatively, you could collect all of these centrally into the sitemap file, rather than inserting into each page. Both types of implementation are valid (but anecdotally I've had better luck with on-page tags instead of sitemap implementation).

In Search Console (new version) go to Coverage > All Known Pages. Then click "Valid" above the chart, Then click on "Submitted and Indexed" and download to a spreadsheet. Do the same for "Indexed, not Submitted in Sitemap". Combine these two downloaded lists into one list in a tab in excel, and in another tab you can put the URLs of all the pages you think should be getting indexed (unless you think all of them are in your sitemap anyway). And then use vlookup formulas to find whether each of the pages you know are on your site are actually indexed (by looking up in the tab containing the downloaded lists).

Use the internet archive (wayback machine) which effectdigital mentioned above, to find the /robots.txt file from the desired date. In that file you should find the referenced sitemap file (assuming the site properly included its sitemap reference in its robot.txt file). Then you can use the same process to request the sitemap file which was referenced in the robots.txt file.

Right, that's what I'm suggesting to change. Although I am not 100% sure. But I would try removing the hreflang which is inside the canonical, like you have copy and pasted above. Just keep the canonical normal. There's also a slight inconsistency between your use of EN and EN-US, but if you remove the hreflang from the canonical tags, that will take care of that too. Again, I'm not 100% sure, but that's what I'd try next anyway.

I have not personally seen the use of hreflang inside of the canonical link annotation, as you've done it on the English pages outside of your homepage. I see this on one of those pages:

rel="canonical" href="https://www.eginnovations.com/cloud-monitoring" hreflang="en"/>

That might be the culprit. I don't know for sure that this is wrong, or hurting anything, But it's not something I have ever used (embedding the hreflang inside the canonical tag). You might try removing that fragment. HREFLANG is only on a page-to-page (not site-to-site) level, so I would only include it on pages which have an alternate page available.

The alternate links with hreflang tags should be present on all the alternate pages. In the example you gave above, there is a self-referencing tag on the English page, and there are a bunch of alternate tags on the French page. But the English page is missing the alternate links to point to the French (and other) alternate pages for those various languages.

To simplify, if you only had English and French pages, then the English page should include a self-referencing tag for English, and an alternate tag for French. And the French page would include a self-referencing tag for French, and an alternate link for English. You might also include an "x-default" on the English page, if it's intended as the primary version for any unspecified other users.

Ah. So, then I might try one of the following:

• My preferred approach would be to set up a redirect for that URL to a valid new URL. That way, you would make the best use of the traffic coming from the Sitelink, for whatever time it might remain there. After a while, I suspect Google will either update the sitelink title and description with those from the new redirected page, or perhaps drop that sitelink eventually in favor of another page.
• If you can't do the above (maybe you are not able to set up redirects from the old URL), then I might go the route of using the Search console (old version) to request removal of the old URL (Google Index > Remove URLs). If it really does give a proper 404 response code, then this should work. It doesn't do the job on its own if the URL still gives a valid response code. But a 404 plus a removal should get rid of it. That said, then you are rolling the dice with whatever Google decides to promote as a replacement sitelink. So, I would prefer the first approach, if I thought I could make the best of the traffic coming from that link.

For an html page, you would include the following line in the HEAD section of the page:

But in your question, I am unclear if you are maybe trying to noindex the sitemap itself? If that is the case, if you are wanting to direct Google to not index an XML file (rather than an html page), in theory you could inject a X-Robots-Tag: noindex into the header for the sitemap file (google how to do that). But probably no need to do that.

Each of your options has pros/cons. But in general, I've found that it is detrimental to have to change/redirect product URLs over time, which tends to happen with URLs containing category names and structure. Your second option, where you use a product "type" might be stable enough to avoid this issue though. If it is stable (or if your product pages are short-lived anyway, such as fast fashion merchandise), then I like this second option because it is helpful in analytics as well as SEO.

That said, the 2 main downsides of having the product type in the path for analytics are products which don't fall cleanly in only one "type" or if the types ever change. Then you have issues in analytics trying to compare to prior periods.

A compromise option (not one of your 3) which is often employed is to embed the relevant "type" and "category" keywords into the product name itself. So, in your book example, instead of /product/books/by-author/john-doe/my-life.html, you might instead just have /product/books-biographies-john-doe-my-life.html.

This 4th option isn't as easily parsed by either search engines or analytics, but it performs pretty well in SEO, and if you are consistent in your naming, it can be usable for analytics (you might have to rely on "contains" filters and things like that). Many e-commerce platforms allow you to put these keywords in as a "slug", so that if the product ID has to be at the end of the file path, then it would be like /product/books-biographies-john-doe-my-life/p-1234.html.

A few thoughts:

• Install the browser extension Ayima, which will let you see if this is actually the result of multiple redirects. There are other ways to see this same info, but the Ayima extension makes it really simple to see the multiple hops, when there are.
• You might try to sequence the existing redirect that is in your htaccess file (A to B) all the way up, or all the way down. There is a sequence followed (most specific to most general).

Seconding what Peter has already answered here. I have completed a domain name migration, and kept the same GA account, property, and view throughout. As Peter wrote, all sites with the tracking code will send data to your GA property, unless you have a hostname filter applied (if you do, just edit it to allow both values through). The setting within GA mostly just allows you to click on page paths to open the live pages, by prefixing with the hostname and protocol.

I currently manage a site which is localized per region, as opposed to country. For some regions, like US and Australia, it is 1:1 with country, so we do not have issues there. But for Europe, that is where we do have some issues currently. We took the following approach (below), but I have to first say that it is quite problematic and has not performed very well so far (implemented about 1 year ago).

The approach we took was to implement HREFLANG within our sitemap, and for Europe, we generate specific alternate locations for each of the countries where we do business in that region, all with the same URL. Here (below) is a redacted version of one page's LOC node in our sitemap (I've only included a partial list, and only showing English, as the full list of alternate URLs for this one LOC has 150 alternate links to cover every EU country x 5 languages we support). But, the general approach is that for Europe, we create one alternate link for each EU country, in each of our supported languages (we support 5 languages). So, we don't assume, for example, that German speakers are only in Germany, or that English speakers are only in the UK. We cover every country/language combination and point many of these to the exact same alternate link.

Again, as I mentioned, this hasn't achieved all we had hoped. But sharing the approach for a reference point here, as an option, and open to any other ideas from the community. We also struggle with EU in terms of Google Search Console geographic targeting. Unfortunately, Google does not allow a property to be targeted to "Europe". And they only allow one single country per property. In our case, we really need to target a single domain to "Europe", not to a specific country. But we can't, and that is a problem currently.

Here is the example from our Sitemap (partial cut-and-past of the first few entries from one URL node):

<loc>https://www.example.com/example-page-path</loc>

<priority>1</priority>

... remainder of alternate links removed to shorten list here

|   |

We currently use geoip detection to present a dialog when customers access one of our country-specific sites other than the one matching their location, asking them to select whether to continue to that requested site, or else click a link to the site matching their IP location's country.The purpose is to diminish the likelihood of users having a bad experience if they accidentally shop a region's site only to discover when they get to checkout that they cannot complete the purchase and need to switch sites.

We are considering adding some logic to prevent this dialog from appearing if the user agent is a known search engine bot. The dialog serves no purpose to bots, and we are worried about its impact on crawling of our sites from servers outside the country-site's location.

That said, we don't want to incur any negative impact of perceived cloaking.

Is user agent-specific logic acceptable practice in this scenario?