I've added the required meta tags (as per http://developers.facebook.com/docs/insights/) on a test environment, but when I use the dashboard to claim the domain, it gives an error indicating that no admin data could be found at the root.
Any idea what I've done wrong / why it isn't working?
See test site here: http://www.test.bbc.co.uk
Thanks very much,
Aodh.
You don't have an fb:admins meta tag there, there's an fb:page_id tag but that's deprecated and if it worked for you before, it will stop doing so very soon - it was scheduled for removal on May 2nd 2012
BTW, you really should have included your meta tags in the question, it's quite difficult to see the issue from the question you've asked, it could easily have been closed as off-topic
Related
full disclaimer, I am not a programer, I am an SEO trying to learn how to not rely on my developer for every little question I have.
Currently my issue is this. I use Screaming Frog to crawl my sites to layout the page titles, meta descriptions, h1, h2, etc so I can more easily plan out my changes.
The other day I wanted to run a report for my client and my own company website and got the following back.
So I know robots.txt is a way to make pages on your site but not have google crawl them. What I don't know is why an entire site would have this message as opposed to just some pages.
Can anyone give advice on how to fix this or links to how to's? I get this issue a lot and would like to educate myself so I don't have to wait for someone else. I get these as well when I try indexing websites on Google Search Console.
Many Thanks
What I don't know is why an entire site would have this message as
apposed to just some pages.
The robots.txt for your website has not been written properly if the intention is to index its content.
Or Screaming Frog might have a but if indeed the robots.txt file is written properly.
Or some webmaster decided the content was not worth indexing on Google or that bots would eat too much bandwidth (as in not being selective to restrict access).
Checking the current robots.txt file on that website, I see this content:
User-Agent: *
Disallow:
Which means the any page of that website is allowed to be crawled by any crawler (here the explanation of that file's syntax: https://moz.com/learn/seo/robotstxt)
So the current file should not cause that error OP mentions. Seeing that this question is from June 30/2017 and the robots.txt file was last modified on Jul 11/2017, it seems since this question was opened the OP may have already fixed whatever problem they had.
I received the message in Search Console about spammy structured data regarding one of my websites. Mind you - It's an older website that has not been up to the standards.
So I had all the error and warnings fixed and I submitted website for reconsideration. Reconsideration has been refused. Problem is I do not know why? Website pass the structured data testing tool test. There is no errors or warnings. At the moment markup is done within HTML ( not json-ld). Could someone take a look and advise me what I can do to have it fixed according to google guidelines and manual action removed.
I', not so sure if this is important or not, but index page is not the only one to contain markup for LocalBusiness. There are more pages similar to the index one, based on different location.
Website in question is http://www.man-van.biz
Thank you for your help in advance.
Problem has been solved. Problem was with duplicated schema markup on aggregate ratings (the same feedback's on all pages). Once I removed it from other pages and kept it only on index page and fix some other issues with markup reconsideration request has been approved and manual action removed.
I've got a staging and live site I'm working on (not my code base). I've accidentally replaced the live server with some staging code (no backup (slap me)) and I'm getting weird urls for articles on the sites 'blog' page.
Basically everything's being called into the page correctly but the page header link is being screwed.
Rather than being
http://www.example.com/a-nice-url
it's giving me
http://www.example.com/news,recent,pr,etc
which appears to be the list of categories of the article.
Where/How can I easily fix this?
I'm only calling [[*content]] and can't find where that is.
Linking to an article I know is there with the correct url works still.
any ideas would be greatly appreciated.
I assume your blog page has some sort of listing somewhere, maybe a getResources call? If you can't find it in your blog list template (as you're saying you only see a *content), it means the list is probably "hardcoded" in the blog list resource content field.
You'll want to find the chunks being used to output each blog entry on the lists and check which page parameter is used to construct the link. It should probably be *alias, and if it is and your aliases are correct you have some deeper trouble going on.
I created my app's namespace using the wrong FB profile, so I deleted the app. And now I'm trying to recreate the namespace and it won't let me - it says it already exists. It doesn't exist! I deleted it! Help! Another user posted a similar question and got an answer suggesting he pick a different name. I'm hoping you will consider that I can guarantee it doesn't exist because I deleted it. Is it hopeless? This is not a name that can be easily changed with punctuation - this is a trademarked product name. And yes, I own the trademark. Please help! Thanks!
It may be temporarily cached and you can wait a couple of days and it'll free up.
But, the more important point is that the app namespace means very little. Practically the only time a user will see it is in their address bar when they go to your app. Most users will not find your app by directly typing in it's URL, instead they'll discover it through App Center or they'll click on a bookmark on Facebook, on a search result on Facebook or elsewhere, they'll see a link or request in news feed or they'll see an add for it.
App Namespace is used a lot in Open Graph code and such, but none of this is ever exposed to the user, only the developer. Therefore, having to use a difference namespace than your original one will make little difference.
As an example of how little app namespace matters, what do you suppose Farmville's app namespace is? farmville? Nope, it's onthefarm
Once you delete an app you created on FB, you can't re-create it with same namespace. It is a bug in FB. Once I had same issue and when I tried to get hep from FB community help center, I found many people having same issue. But the issue still not solved.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm just looking through some of the webmaster stats that Google provides, and noticed that the most common links to our website are to some research articles that we've put up in PDF format. The articles are also available on the site in HTML.
I was looking at the sites (mostly forums and blogs) which link to these articles and was thinking that none of the people clicking the links would actually get to see our website, and that we're giving something away for free and not even getting some page views in return.
I thought that maybe I could change my server settings to redirect external requests to these files to the HTML version. This way, the users still get the same content (albeit in an unexpected format), and we'd get these people to see our website and hopefully explore it some more. Requests coming from my site should be let through to the PDF. Though I don't know how to set this up just yet (keep an eye out for a follow-up question here), I'm sure this is technically possible. The only question is: is that a good idea?
What would you consider the downsides of redirecting traffic from external sources such that they see our site, not just get our content? Do they outweigh the benefits?
The only other alternate option I can see is to make our branding and URL much more visible in the PDF files themselves. Any thoughts?
Hopefully your PDFs are equally branded so that visitors will feel compelled to search further in your website. That might be just as important as having visitors briefly stop-over at your website.
I'm usually opposed to all such redirects as harmful to usability. However, in this case a basic content-type negotiation takes place and this might be acceptable. However, make sure that this doesn't break downloads of the PDF documents for users who might have disabled their referers in the browser (I do this, for one).
Sure you could cut them off, but there is a bigger issue at play: Why aren't these people finding you before they are finding these moocher sites?
Possible reasons are:
a) they did find your site, but not the content they were looking for, even though its obviously there, or
b) your site never appeared in their search results.
You may want to consider a site redesign in order to address those concerns before cutting off what appears to be a reliable source of information about your target audience (for you and the people who get your PDFs from elsewhere).
In the meantime, I would suggest you allow the traffic, add a cover page to all of your PDFs that are basically a full-page ad for your site and then enlarge the font on the copyright section of each page so the authorship is very prominent. You have a built in audience now, they just don't know it yet. Show them where the source is.
Eventually, the traffic will come to you and know you as a reliable source for that information.
I would do it. It's your site and your data.
The hot-linkers are essentially 'guests' and you can make the rules for your guests.
If they don't like it, they don't have to link.
I would add a page at the beginning of each article with info about the website, the current article and links to other articles on your website.
I find it more convenient than redirecting the user to a page on your website(that's annoying). Most people right click and download PDF files, what would that do when your redirect ;)
I think the proper thing to do in this situation is to leave the redirects. Here's why:
There's nothing worse than expecting to go somewhere/get something and not getting it (the negative impact would outweigh the positive.)
Modify your content to add a footer such as: "like what you saw, we've got more, check us out at www.url.com"
If your content is good, users will check out your website. These are the visitors you want, they're more likely to stick around and provide your site with value (whatever that may be.) Those that you've coerced may provide you with an extra click or two, but you will likely not see any value given back to your site.
Look at other successful sites that give something away for free: Joel on Software, Seth Godin, Tim Ferriss, 37Signals. The long term will provide better, more consistent value than the short term.
If you go for this solution, see if redirecting to the HTML version also changes the file name displayed by the browser if somebody used 'save as' on the link, else an HTML page would be saved with a pdf extension. Apart from that, I can see no reason why you shouldn't do it.
As an alternative, see if you can add a link to your site to the top of the pdf file. This way they are reminded where it comes from even if someone else sent it to them by email.