I am new to Google Analytics and need to make a change, we are adding site search. I can't save the site search change because GA has some incorrect info in it and will not let me save any changes. Specifically, the default page can't have slashes. So, when I try to save my other change, I get this error.
It seems to me that the info that we have now is incorrect and isn't being used by Google.
I am pretty confident that if I remove the "avcat/ctl1642/index.cfm" from the default page I will be able to save it. I am not sure of what effect this will have on reporting, but I will never be able to re-enter that value if it isn't correct.
What are the effects of removing this bit of info? Should I just leave it blank? Shoud I just use index.cfm
Here is the current information that is saved.
The default page is the page that is displayed when a directory name is entered without a filename. For example: A user types mydomain.com/mydirectory/ into the browsers adress bar and the server serves the page mydomain.com/mydirectory/index.html. The exact name of the default page depends on the server configuration (usually it's along the lines of index.html, index.php, index.aspx, default.aspx or similar).
However Google will count mydomain.com/mydirectory/ and mydomain.com/mydirectory/index.html as two different pages, even though they display the same content. So you can enter the name of the default page in Google Analytics to make sure the page count for both urls is aggregated into one value. The value for default page is applied to every url that ends with a trailing slash (and without a filename) since Google assumes that this is a directory name that displays the default page.
"vcat/ctl1642/index.cfm" does not make any sense as setting for a default page since it includes a directory path; a path is not a page. I'm amazed that it was ever possible to enter that value. If Google Analytics actually applied that value then all urls that ended with slash will be mangled (i.e. will have vcat/ctl1642/index.cfm added to them). Removing the value will mean that this does not happen anymore.
Related
Is there way to force Symfony throw 404 if there is some extra params ?
For example, I have route /news/ and I want to allow only date parameter. So link could exist in this form: /news/?date=243242, but I want 404 if user enters following link: /news/?param=2 ?
Thanks.
(I don't want to check query params in controller, I know I can)
Do you really need these to be get params? You meet your objective buy having them as values in the URL itself e.g.
#Route("/news/date/{date}")
Slightly different I know - but you can enforce it
Why do you care about the extra params anyway? If some nasty user decides to play with the URL directly, your app is not supposed to behave correctly.
Don't bother with all these checks — unless those params somehow affect security.
Based on your comment, you want to respond with 404 to get rid of duplicate content in Google. There are several steps you need to take to solve that problem.
If a user enter an extra parameter manually, in no way that would add a page to the Google index. So, if you're having duplicate pages based on different params in the Google index, it means that you have links with those extra params on your site. That's how they end up being indexed.
First thing you could do would be to get rid of those links. Then you could go to the Google Webmaster Tools and manually remove the indexed pages with those extra parameters from the index. If you don't have the problematic links anymore, they won't get to the index again.
If for some reason you can't get rid of those link, go to the Webmaster Tools and consult the URL Parameters section to understand how to add parameters that Google should ignore.
When looking at Google Analytics, all reports show URLs that begin with a slash and www: "/www.url.com/page.html."
I've never seen Google report like this. Webmaster Tools is set up correctly. Not sure what else can be set up in Analytics. Any idea?
Current: /www.url.com/page.html
Typical: /page.html
by default GA only reports the relative path and query string of the URL (it strips the protocol and domain. So one of two things must be happening:
1) you have code that is passing a custom page name to the _trackPageview call, adding that "/[domain]".
2) you have a custom filter within the interface setup that is prefixing the page name with "/[domain]"
Adding the domain to the page name is a fairly common thing to do when you have GA code spanning multiple domains, most especially when they are going to a rollup profile, so that you can see which pages are coming from which domain.
So if I had to guess (and this is only a guess, seeing as how I don't have access to your
code or GA interface), someone must have attempted to rebuild the full url to use as the page name instead of just the path+querystring - and then messed up (probably a messup in some regex with the protocol, if I wanted to throw even more guesses at it).
But the 64 thousand dollar question is.. where is it being changed? Like I said.. GA by default does not do this, so someone has added code to do it on your site, or else a filter within the interface.
I would start by looking to see if there are any filters in your interface, since that is the easier thing to determine. If you see no filters relevant to this, then you will have to look on your page code (including any script includes or other javascript code being output). It would be a value passed with _trackPageview so ctrl+f for that.
I just replaced a tumblr website for a client with a brand new Wordpress site. And when running it through the Facebook debugger, I get this error:
The object at 'http://example.com/' previously had type 'tumblr-feed:tumblelog' and cannot be changed to an object of type 'website' to avoid data corruption of existing actions.
I Googled "Cannot change og_type" (in quotes) and got literally zero results (well now it seems there are results stemming from this question). Am I really doomed to Facebook data mismatch?
Per the error message
... cannot be changed to an object of type 'website' to avoid data corruption of existing actions.
If the og:type were changed for a URL, any existing user posts linking to it or sharing it, any Open Graph actions referencing it, as well as any likes of the URL would become broken and the user's profiles would be missing content they'd posted before.
I don't believe there's any way around this, as it's an intentional restriction to avoid breaking existing posts, likes, actions, etc referencing a URL. If the posts were broken, content would be removed from or mangled on the user's timeline.
A possible workaround if you want to have a 'new' object at that URL is to use my instructions in this answer about moving URLs to put a Like button on the URL you're trying to change (let's call it A), but pointing to a slightly different, new URL (let's call it B) , and then use the redirect mechanism in my answer to bounce users landing at URL B back to A, but serve the metdata describing 'A' on URL B if the Facebook crawler accesses it
Does the client's site have more than 10,000 likes? If so, Facebook doesn't allow og:type to be changed.
You can update the attributes of your page by updating your page's tags. Note that og:title and og:type are only editable initially - after your page receives 50 likes the title becomes fixed, and after your page receives 10,000 likes the type becomes fixed. These properties are fixed to avoid surprising users who have liked the page already. Changing the title or type tags after these limits are reached does nothing, your page retains the original title and type.
Here's the link to the Open Graph documentation. :)
I would reccomend using the Open Graph Debugger to check what facebook really sees and if facebook eventually has a cached version of your site. (you find hte debugger here: https://developers.facebook.com/tools/debug)
NOte that it doesnt say og:type - it says og_type
This is hitting me too since my og:type is set to "shamrockirishbar:shamrockirishbar" BUT the linter is saying og_type (of which there is none in my meta data) is set to "website".
enter link description here
I am developing an online application in which I need to take a printout of the data entered in the form,but on that printed page,at right corner I am getting my page url (e.g. http://www.growmoney.com/print.aspx) printed.
I don't want it to be printed on the printout.
Is there any solution for this?
The address, date, time etc is typically added by the browser itself and can be configured by the user. How this is configured differs from browser to browser, instructions can easily be found. However, to my knowledge there is no way for an html page to influence those settings. Instead you could generate e.g. a PDF file of the form and let the user print that. This should give a more predictable print out. Alternatively you could explain to the user how to change the settings to not print the header and footer.
See also Disabling browser print options (headers, footers, margins) from page?
I need to be able to determine which page the user just came from to determine which links to display, such as breadcrumbs or links to the previous next item. This is basically the HTTP_REFERER functionality in PHP, but I need a way of tracking it across multiple pages. I also need to "support" the back button.
I have noticed that Facebook uses a query/get parameter of "ref" to track the referring page. (They also avoid reloading the entire page, using AJAX instead but I'm don't have the budget to do that right now.) Also, the site I'm working on needs to be indexed by Google, so this method will also require that I add the canonical link tag.
I'm wondering if the ref/referrer query parameter is the best method or what other options there are?
If you want breadcrumbs, you shouldn't be using HTTP_REFERER at all. It should be a logical path to get to where they are, no matter where they came from, like User > Albums > AlbumName > Photo, even if they came from a direct link their friend gave them. That said, if you do want to go back a few pages, just store them as a an array in a SESSION variable.
I'm pretty sure Facebook just uses the ref GET variable to collect some statistics on which buttons users are using, since there are multiple ways to get to the same page.
None of this should break the back button, or intefere with your canonical tag.
From comments: You could use a ?ref=blah tag, or session variables, ($_SESSION['history'][0] = $_SERVER['HTTP_REFERER'] or REQUEST_URI). Use whatever you find easiest. Session variables rely on cookies or passing an ID through the URL, GETs just clutter the URL and might get passed around to friends.