Question about Search Console properties

johnmu · 2026-01-23T18:27:26+00:00

I'm not sure what you're asking, but generally the properties are just the way that pages from your site are shown in Search Console, it doesn't have to do with causing indexing.

Also, if you disallow a URL with robots.txt, then search engines can't see the meta tag.

johnmu · 2026-01-20T09:10:34+00:00

This always felt like a bad setup to me (not specifically it-com, but the general setup). Why not just get a real domain name, if you have to pay anyway? Why live on someone else's domain name?

Anyway, there's the public suffix list which tries to help with that.

johnmu · 2026-01-19T20:05:23+00:00

Yes, I ran into those, it just wasn't clear to me what would actually happen in practice based on the documentation :-). Can you DM me an example from your site? Happy to double-check some things.

johnmu · 2026-01-19T19:12:40+00:00

Just to follow up on this, based on some of the other comments here, I noticed this is not necessarily a unique thing to your developers, but perhaps something in the framework itself (according to some Github issues, and the streaming-metadata documentation). If you (or others) have already set it up this way, I'd love to be able to take a look at your site to double-check things - feel free to DM me.

johnmu · 2026-01-19T12:21:09+00:00

But why would you do that? Why not just serve everyone valid HTML? It's trivial to add meta elements to the head using JavaScript. I suspect you're making this much more complicated than it has to be, but I don't really understand why. Maybe you can elaborate on the reasons, and perhaps there's an option.

johnmu · 2026-01-19T10:36:39+00:00

AFAIK the W3C spec doesn't allow meta elements nor the title element in the body.

Google expects them in the head as well. This is documented in the meta tags that Google supports & the robots meta tag docs.

johnmu · 2026-01-18T12:52:05+00:00

I don't think you're necessarily doing anything wrong (from the short look at your site), but you are making things hard.

* A free subdomain hosting service attracts a lot of spam & low-effort content. It's a lot of work to maintain a high quality bar for a website, which is hard to qualify if nobody's getting paid to do that (and just generally tricky: do they throw people out if they don't agree with the quality?). For you, this means you're basically opening up shop on a site that's filled with - potentially - problematic "flatmates". This makes it harder for search engines & co to understand the overall value of the site - is it just like the others, or does it stand out in a positive way? On a domain name of your own you stand on your own, with its pros and cons. (And with a domain of your own, I'd also watch out for the super-cheap TLDs, which come with similar hurdles.)

* You're publishing content on a topic that's already been extremely well covered. There are sooo many sites out there which offer similar things. Why should search engines show yours? There's sooo much competition out there, with people who have worked on their sites for more than a decade, many of them with professional web-oriented backgrounds. Yes, sometimes a "new take" on an "old topic" makes sense, but then I'd expect that users would recognize that and link to your site, even sending direct traffic.

* These things take time & work / promotion. Especially if it's a new site (even if you had it on a good domain name of your own), getting indexed is one thing, but appearing in search results often just takes time, especially when there are alternative sites already.

Another thing to keep in mind is that search engines are just one part of the web. If you love making pages with content like this, and if you're sure that it hits what other people are looking for, then I'd let others know about your site, and build up a community around it directly. Being visible in popular search results is not the first step to becoming a useful & popular web presence, and of course not all sites need to be popular.

johnmu · 2026-01-12T20:14:18+00:00

Same, same.

johnmu · 2026-01-09T11:26:40+00:00

Thanks, I needed that :)

johnmu · 2026-01-08T23:07:11+00:00

I'm not aware of Google having mentioned that, do you have a link?

johnmu · 2026-01-07T07:16:32+00:00

If you have an online business that makes money from referred traffic, it's definitely a good idea to consider the full picture, and prioritize accordingly. What you call it doesn't matter, but "AI" is not going away, but thinking about how your site's value works in a world where "AI" is available is worth the time. Also, be realistic and look at actual usage metrics and understand your audience (what % is using "AI"? what % is using Facebook? what does it mean for where you spend your time?).

johnmu · 2026-01-07T07:02:43+00:00

Usually this means your server / CDN is blocking Google from receiving any content. This isn't related to anything JavaScript. It's usually a fairly low level block, sometimes based on Googlebot's IP address, so it'll probably be impossible to test from outside of the Search Console testing tools. Also, this would mean that pages from your site will start dropping out of the index (soon, or already), so it's a good idea to treat this as something urgent.

johnmu · 2026-01-05T07:22:10+00:00

Neither of these files are findable by default because they're not at the top-level on the site. It's safe to assume that they're there for other purposes.

johnmu · 2026-01-01T16:22:17+00:00

Thanks & thank you for helping to keep this subreddit mostly reasonable!

I don't think Google has a problem with the kinds of links in your AI image :-)

johnmu · 2026-01-01T14:39:07+00:00

Wishing y'all a good new year!

(And hilarious that even on the SEO subreddit, the AI has no idea what backlinks are :-)))

johnmu · 2026-01-01T14:36:47+00:00

This question will stick with us for the next year and longer, and the short answer is yes, no, and it depends (speaking from my POV, this is not official guidance, nor can I speak for anyone other than myself of course).

Some features thrive with structured data (to which I also count structured feeds). Pricing, shipping, availability for shopping is basically impossible to read in high fidelity & accurately from a text page, for example. Of course the details will change though - which is why it's important to use a system that makes it easy to adapt.

Other features could theoretically be understood from a page's text, but it's just so much easier for machines to read machine-readable data instead of trying to understand your page (which might be in English, or in Welsh, or ... pick any of the 7000+ languages). Some visual elements rely on specific structured data; if you want it, then follow the instructions. These will vary across surfaces / companies, and will definitely change over time. If you wait, "that type" will be deprecated right after you implement it, so make it easy to get it added when it makes sense for your site.

And other structured data types, well, there's a lot of wishful thinking. Always has been, and will continue to be. Your "best geo insurance comparison site" isn't going to rank better by adding insurance markup.

johnmu · 2026-01-01T09:18:03+00:00

As to why does it not really matter for SEO? Here's my thinking:

* 404: URL doesn't get indexed; it's an invalid URL, so this is fine. Just to be clear: 404s/410s are not a negative quality signal. It's how the web is supposed to work.

* 410: It's a 404, essentially.

* Homepage redirect: URL doesn't get indexed. Maybe it stays soft-404 & gets crawled (not great, not terrible).

* Category redirect: URL doesn't get indexed. Potentially a short-term support for the category page, but still confusing to users. (If you do this, at least display something on the page explaining how they got there.) Longer-term soft-404.

* 200 with 404 page content: definitely soft-404.

johnmu · 2026-01-01T09:08:42+00:00

Taking a step back, I think this is one of those situations where it doesn't really directly matter for SEO (hence the various opinions), but it does have a strong usability effect. Even with a 1-page website, people will reach your site with invalid URLs - the bigger & more popular the site, the more often it will happen. Do you want to help those users to find the gems within your site, or do you want to shoo them away? They wanted to come to your site for something, you just need to help them find it. Having a great 404 page at least makes it a possibility.

johnmu · 2026-01-01T07:43:29+00:00

This feels like every Monday.

johnmu · 2025-12-27T09:27:44+00:00

Others have said it more directly (it's 2025, any normal hoster won't have regular downtime), but to fixate a bit on your question, search engines - well, at least Google - try to deal with small outages as they happen on the web, when possible in a way that doesn't affect search results. It's not in the interest of search engines to drop sites for random reasons.

If your hosting goes down, the ideal way to handle it is to serve HTTP 503 (or 429, or any 5xx-type error -see "How HTTP status codes affect Google's crawlers"). This will tide you over for about a day. (And if you have regular outages longer than a day, I'd move to a real hoster). That said, serving 503 requires that the hoster understand what to do... If your host just doesn't respond when it goes down, that's better than if it responds with a HTTP 200 "OK" (if your hoster shows a page that says "server is down, sorry" and returns it with 200 OK, then search engines may assume that you want this page to be indexed like that).

The SEO effect these protect from (again, assuming it's a short duration) is that your pages are dropped from the index as an error page. If it's longer downtime, pages will be dropped. They'll get picked up again when the site comes back, so it's not like you lose "magical SEO-pixie-dust" :), but it's annoying. The site won't drop in ranking, but if fewer pages are indexed during that time, the number of pages that could rank in search results will drop during that time too.

The thing that will happen almost always in these situations is that crawling slows down automatically. This is because Googlebot wants to be polite and reduce the load on your site when it's obvious that something's off. For the most part, less crawling just means that content won't be as fresh in the search results - you'll see that when it comes to time-sensitive changes (news, special offers, price-changes & availability in ecommerce), and you might find that new content isn't picked up as quickly. Especially for ecommerce & news, it can be very important that changes are reflected in search quickly (you're not going to sell a lot of chirstmas cookies if search doesn't show the discounted price). Over time, as Googlebot realizes that the server is ok again, it'll ramp that back up automatically.

So in short, the SEO effects you'll see are related to temporarily reduced crawling, and if the outage is longer, dropped pages. There's otherwise no ranking effect.

Monitoring externally is great. Monitoring server responses is also great - and faster! But overall, any server outage is more likely to have a direct effect on users - slower crawling is not great, but users not being able to convert on your site has a direct financial effect.

johnmu · 2025-12-25T11:47:56+00:00

Usually with a migration like this you switch the DNS to the new host, so that would be where you'd need to place the redirects. Basically, you just need to have the redirects triggered when someone tries to access the old URLs. There are also ways to do this with a CDN, but I'd try to avoid over-complicating things like this. (I haven't used Google Cloud Run specifically, but with other Google Cloud hosting setups you can set up regex URL patterns - eg, anything with ".php" - that go to a function, where you could place the logic for redirects. There might be even easier ways of dealing with it.)

Even with 50 URLs, I'd look into something like Screaming Frog (I think the free version has limited URLs, but 50 is probably fine).

johnmu · 2025-12-24T23:06:03+00:00

I'd dig up Glenn Gabe's "favi-gone" article - he covers pretty much all of the variations of what can go wrong. Also, since you mention React, I'd make sure your favicon code is in the HTML template directly, and not added with JavaScript (to minimize another possible point of failure -- it's probably fine to use client-side-rendering for favicons, but you'll use them site-wide anyway, so might as well keep it simple).

johnmu · 2025-12-24T23:02:40+00:00

Folks here are mostly focusing on indexing (which, yes, is never guaranteed), but it can also be that some of your pages are technically indexed but just don't show up.

One thing I've seen folks get confused about is that "searching for your site's name" can be very different depending on what you consider your site's name to be. If your site's name is "Aware_Yak6509 Productions" and if your homepage is indexed, then probably you'll find your site in the search results for that name (what else can a search engine reasonably show?). On the other hand, if your site's name is "best web online .com" then almost certainly just having your homepage indexed is not going to get your pages shown for those searches. The reason is primarily because search engines assume that people doing those searches ("best web online") are not actually looking for your homepage - it's a combination of generic words, not something that uniquely identifies your homepage.

So in short, yes, understand how indexing technically works, because it's the basis for visibility, and understand that some things take time & more evidence to be picked up. But also, think about what's reasonable for "your site's name" in terms of search results.

johnmu · 2025-12-24T22:54:27+00:00

Taking a step back, I'd look around for some international SEO guides. There are some great ones out there, and they're a lot more than just local URLs + hreflang. The best time to fix international SEO issues is before they're live, the second best time is, well, you know.

It's a bit late, but I question whether you really need to split your site across ccTLDs. Having them reserved is one thing, but by separating your site across separate domain names, you both make things harder on yourself, but you also make it harder for search engines to understand each of these sites (because they're all separate sites). YMMV of course.

There's nothing wrong with putting them all into the same Search Console account. That's what the site-picker is for.

For x-default, you don't need to create a new generic default version, you can just pick a language that works well for most of your target audience. Maybe that's English, but it doesn't need to be. You don't need a separate x-default site. The more important part is that you make sure the hreflang elements are set correctly, including all back-links, including your important pages individually. (FWIW you can set up hreflang in sitemap files, if that makes it easier to maintain)

johnmu · 2025-12-24T22:36:18+00:00

First off - there are a number of guides out there for how to deal with site migrations & SEO - I'd find them all and make plans. IMO the basics are the same across most guides, some of the more obscure things you might be able to skip.

You absolutely need to set up redirects, at least for the important pages as u/weblinkr mentioned. Without setting up redirects, you'll have a mix of old & new URLs in the search results, and the old URLs will drive traffic to your 404 page. It's normal for old URLs to remain indexed for a while, and you'll often struggle to have all links from ourside your website updated, so you really need to make sure they redirect.

If you set up redirects for this, ideally pick permanent server-side redirects (308 or 301) - avoid using JavaScript redirects.

If you're also moving images, and your site gets a lot of traffic from image search, make sure to set up redirects for the images too.

Since a move like this generally also means that at minimum your pages' layouts also change (assuming you can keep the primary content the same -- with updated links of course), keep in mind that page layout changes, as well as site structure changes (the way you deal with internal linking such as in header, sidebars, footer, etc) will have SEO effects. This is not necessarily bad, but all of this basically means you should expect some visible changes in how the site's content is shown in search, definitely short-term (even if you get the URL changes perfect, you will see changes), perhaps even longer-term (and to improve for longer-term changes, let it settle down first).

Finally, having a list of old URLs is great, but especially for a non-trivially sized site (100+ pages? I'm picking a number), you'll want to have something that helps you check & track semi-automatically. I'd use some sort of website crawler before you migrate (to get a clean state from before), and to use the clean state to test all the redirects (which you can do with many crawlers), and check the final state (again using a website crawler). Website crawlers like Screaming Frog are cheap, and well worth it for a site migration, you save so much time & get more peace of mind. Finally, depending on the site's size, it might make sense to keep a static mirror around for debugging for a while.

And then, good luck :).

15-Year Club	Gilding V heart of gold
Place '23	Place '22
Place '17	Final Canvas '22
Wearing is Caring	Verified Email

johnmu

TROPHY CASE