My newly relocated (and slimmed down) site provides links with index.html (rather than the folder name followed simply by \) where they are required.
Google Analytics has not picked up on this and still reports 403 and 404 errors, which no longer apply.
Do I have to anything else or should I just wait for Google Analytics to refresh? If so, how long would this typically take?
I should mention that I have checked the site with a dead links checker and all seems OK.
Google Analytics doesn't crawl your site and will never pickup on that. Older reports will contain the older urls forever.
Newer reports will show the new urls as you start to track them.
Related
When I load pages via
https://graph.microsoft.com/v1.0/me/onenote/sections/{ID}/pages?$top=100&$orderby=createdDateTime%20desc
the results are not up-to-date, even though changes have been synced across other devices.
There should be 4 pages in the section. This is what is in the response:
two existing pages (two are missing)
several other pages that were previously deleted, but when I try to fetch the HTML contents, I get a 404. The pages were deleted via DELETE https://graph.microsoft.com/v1.0/me/onenote/pages/{ID} per the docs
Does it work via the OneNote API?
Per #codeye's suggestion (see comments), I'm trying to access the pages via the one note API. It seems unclear whether this is still possible:
The API is deprecated and scheduled to sunset November 2022.
The docs refer to registering the application in the Microsoft account Developer Center, which appears to be obsolete and points back to the Azure portal
Later in the same doc, they refer to permissions like office.onenote_update that no longer seem to exist i.e. I can't find them in the Azure Portal. I do see permissions with the same name from two places: Microsoft Graph and OneNote - perhaps the permissions have been renamed?
However, after adding One Note ->
Notes.ReadWrite, logging out and reauthenticating, I'm still getting HTTP errors on onenote.com URLs like:
401 from https://www.onenote.com/api/v1.0/me/notes/sections/{ID}/pages?$top=100&$orderby=createdDateTime%20desc (as #codeye suggested below, tried with and without query parameters)
401 from https://www.onenote.com/api/v1.0/notebooks (URL from the docs
404 from https://www.onenote.com/api/v1.0/me/notebooks (same URL as previous, but with me/ segment added
I assume it has something to do with this:
For me Google one Tap stopped working on all my sites that previously worked. I added API HTTP refer to restriction in console.developer.com, but I still get a warning message "The client origin is not permitted to use this API." any thoughts? If you go to the page https://www.wego.com/ you can see that Google one tap still works...
https://news.ycombinator.com/item?id=17044518#17045809
but Google YOLO stop working for everyone. I use it like many people for login and it just stop work.
My domain are obviously added on console.developers.google.com
Any ETA for fix this? Some information would be great for people who rely on it.
Google YOLO is not disabled. It is open to a small list of Google Partners.
The reason you were able to access it earlier was because it was open for a short period of time but the whitelist is now readded/enabled.
Reference:
https://twitter.com/sirdarckcat/status/994867137704587264
Google YOLO was put on whitelist after a client-side exploit became clear to google.
People could cover the login button of the prompt with something like a cookie consent (which we all know people automatically accept).
Therefor people could easily steal their gmail or other details due to this google decided to put it on whitelist and review the sites that are using this technology in order to ensure that they are using it as they should.
Google retroactively labeled One-Tap as a "closed beta".
https://developers.google.com/identity/one-tap/web
The beta test program for this API is currently closed. We are improving the API's cross-browser functionality and will provide updates here in the coming months.
The link for the entire project is currently 404, but the beta statement is visible on the wayback machine.
We recently changed protocol to HTTPS and our google search impressions has plummeted. The old site, with the URL beginning with HTTP is still appearing in google search results even though we have set up our redirects correctly.
Do we go ahead and request URL Removal in Google Webmaster Tools or leave google to do its thing. We are worried that Google might be seeing our old site and penalising our new site for duplicate content.
No. If you do that the http version will be removed too. Ensure you have set up 301 redirects and be patient.
I'm having some issues with Google Analytics URL parameters. Prviously I've built URLs with the Google Analytics URL Builder. these have enabled me to track where visitors to my site have been coming from, how successful various marketing campaigns have been etc.
Recently, I've started using another tag in the URL, one which has nothing to do with Google Analytics, but acts to alter the telephone number on my site when the visitor arrives on it. For example, I'll add &ctcc=adwords onto the end of my tracking URL, and a specified phone number will appear on my site when the user comes through so I can track how many calls my adwords spend has generated.
However, when I've been using this ctcc code, Google Analytics no longer seems to be tracking the traffic numbers to my site :(
Any idea how I can incorporate the two parameters into the URl, and ensure that they both work as expected?
Thanks in advance
It looks like this is a problem with how your server is redirecting traffic with a ctcc query parameter. Look at the following request and its response headers:
So the ctcc parameter is used in some server side tracking (as best as I can tell), and the server is set up to redirect & strip ctcc whenever it gets a request with ctcc. Not being familiar with the system in use, I can't provide details, but you need to reconfigure the redirects to stop changing & into ;. It's the replacement of ampersands with semicolons that is messing up your GA data.
I have a little problem with google bot, I have a server working on windows server 2009, the system called Workcube and it works on coldfusion, there is an error reporter built-in, thus i recieve every message of error, especially it concerned with google bot, that trying to go to a false link, which doesn't exist! the links looks like this:
http://www.bilgiteknolojileri.net/index.cfm?fuseaction=objects2.view_product_list&product_catid=282&HIERARCHY=215.005&brand_id=hoyrrolmwdgldah
http://www.bilgiteknolojileri.net/index.cfm?fuseaction=objects2.view_product_list&product_catid=145&HIERARCHY=200.003&brand_id=hoyrrolmwdgldah
http://www.bilgiteknolojileri.net/index.cfm?fuseaction=objects2.view_product_list&product_catid=123&HIERARCHY=110.006&brand_id=xxblpflyevlitojg
http://www.bilgiteknolojileri.net/index.cfm?fuseaction=objects2.view_product_list&product_catid=1&HIERARCHY=100&brand_id=xxblpflyevlitojg
of course with definition like brand_id=hoyrrolmwdgldah or brand_id=xxblpflyevlitojg is false, i don't have any idea what can be the problem?! need advice! thank you all for help! ;)
You might want to verify your site with Google Webmaster Tools which will provide URLs that it finds that error out.
Your logs are also valid, but you need to verify that it really is Googlebot hitting your site and not someone spoofing their User Agent.
Here are instructions to do just that: http://googlewebmastercentral.blogspot.com/2006/09/how-to-verify-googlebot.html
Essentially you need to do a reverse DNS lookup and then a forward DNS lookup after you receive the host from the reverse lookup.
Once you've verified it's the real Googlebot you can start troubleshooting. You see Googlebot won't request URLs that it hasn't naturally seen before, meaning Googlebot shouldn't be making direct object reference requests. I suspect it's a rogue bot with a User Agent of Googlebot, but if it's not you might want to look through your site to see if you're accidentally linking to those pages.
Unfortunately you posted the full URLs, so even if you clean up your site, Googelbot will see the links from Stack Overflow and continue to crawl them because it'll be in their crawl queue.
I'd suggest 301 redirecting these URLs to someplace that make sense to your users. Otherwise I would 404 or 410 these pages so Google know to remove these pages from their index.
In addition, if these are pages you don't want indexed, I would suggest adding the path to your robots.txt file so Googlebot can't continue to request more of these pages.
Unfortunately there's no real good way of telling Googlebot to never ever crawl these URLs again. You can always go into Google Webmaster Tools and request the URLs to be removed from their index which may stop Googlebot from crawling them again, but that doesn't guarantee it.