Interface organization in Go project

I don't understand so clear this Go wiki statement: “Go interfaces generally belong in the package that uses values of the interface type, not the package that implements those values”, is it correct that interfaces are declared where the are used?

if for example i have this test.go file

package test

type Tester struct {...}

func NewTester(){
     return Tester{...}
}

func(t * Tester) GetCache(key string) (value string, error){...}
func(t * Tester) GetDB(key string) (value string, error){...}

And now, let's say I have 20 packages where I use the GetCache method. Do I need to define the interface in each of the 20 packages, like this:

type TestCache interface {
   GetCache(key string) (value string, error)
}

Is it really maintainable? What if GetCache changes the interface contract? I would need to update all 20 declarations in the packages. Wouldn't it be better to declare each interface within the package where the methods are defined?

Yes, your statement is correct - you may want to store your interfaces close to the objects that actually depend on them and it is possible to implement it due to the implicit nature of the Golang interfaces. Engineers coming from typical OOP language backgrounds (like myself coming from C#) usually have a hard time grasping what is the purpose of this language feature.
I can elaborate on why the structure you describe makes sense.
Imagine you have an entity like this in your library:

type Lib struct {
  Foo(){}
  Foo2(){}
  Foo3(){}
  Foo4(){}
}

type LibInterface interface {
  Foo()
  Foo2()
  Foo3()
  Foo4()
}

If you define an interface in the same package, all users will be injecting all 4 methods Lib exposes, even if some of the users need only 1 or 2. So you explicitly telling: "Hey I need these 4 methods from that library", which is not true because you only use 1. Now write unit tests for it:

type LibUser struct{
   lib LibInterface
}
func New(lib LibInterface) *LibUser {
   lib = lib
}

You would need to define a mock for your dependency:

type LibMock struct{}
func (LibMock) Foo(){}
func (LibMock) Foo1(){}
func (LibMock) Foo2(){}
func (LibMock) Foo3(){}
func (LibMock) Foo4(){}

So you define a mock for all 4 methods interface exposes even though you use only 1. What comes next? Lib introduces a new method - you go to ALL your lib consumers and update mocks even though you still do not use them! Isn't it annoying?
Of course, you can use tools like Mockery and keep mocks together with the interface and implementation and pull that entire blob in all your tests. But... is it clean? Go gives you the ability to implement it in a cleaner way. When LibUser defines its own interfaces for its dependencies it is very explicit what it uses. Also, if you are coming from Java or C# background you remember how annoying it is when a library does not have abstractions so you cannot mock them and you simply need to live without tests or create your own wrappers! So this problem does not exist in Go. Declaring interfaces by consumers to me sounds like a clean approach. But again - it is not a rule, you can decide on your own how you want to structure your projects.

Those are my personal reflections after building plenty of services and libraries written in Go and coming from OOP background where interfaces are explicit

You can use something like

var _ TestCache = &Tester{}

in other packages. Program will not compile any more, if you change Tester implementation

See https://go.dev/play/p/L4bQYBcr4jv

Package not depends on concrete implementation, but on interace defined by same package. Thanks to interface duck typing.

Yes, you can define another one package for interface, define interface there, and depends on it. But coupling will be higher in this case.

*Also, interface naming conventions says Tester should be an interface name, not struct https://go.dev/doc/effective_go#interface-names